From root@core3.amsl.com Wed Feb 4 20:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 65DA03A6858; Wed, 4 Feb 2009 20:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090205040001.65DA03A6858@core3.amsl.com> Date: Wed, 4 Feb 2009 20:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 04:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-02.txt Pages : 26 Date : 2009-02-04 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of scalability, reliability, and flexibility that IPFIX Mediation may help resolve. IPFIX Mediation covers two classes of mediation: context mediation for traffic data and transport mediation for transport protocols. This document describes the problems that network administrators have been facing and the applicability of IPFIX Mediation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-problem-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-04195139.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Thu Feb 5 00:50:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880A03A6A41 for ; Thu, 5 Feb 2009 00:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt8I0GoI0LYB for ; Thu, 5 Feb 2009 00:50:28 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7BFF33A6870 for ; Thu, 5 Feb 2009 00:50:27 -0800 (PST) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:589f:6508:e4d:bfe]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n158mavm050531; Thu, 5 Feb 2009 17:48:41 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 05 Feb 2009 17:47:34 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <49269B8B.7000500@net.in.tum.de> References: <4926321C.9030403@cisco.com> <49269B8B.7000500@net.in.tum.de> Message-Id: <20090205172405.D332.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 05 Feb 2009 17:48:42 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 08:50:29 -0000 Gerhard and Benoit, I submitted new version problem statement draft just now. It took more long time than I have expected. I tried to merge Benoit's idea and Gerhard's idea regarding terminology section. I propose that IPFIX Mediation indicates the generic term of some capabilities, and IPFIX Concentrator, Proxy and Masquerading Proxy indicate specific capability of IPFIX Mediation. Please see section 2, and let me know your comments. http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-2 Thanks, Atsushi Kobayashi On Fri, 21 Nov 2008 12:29:15 +0100 Gerhard Muenz wrote: > > Benoit, > > Benoit Claise wrote: > > Christoph, All, > > > > I agree there is some confusion with regards to the terminology. > > Here is a proposal > > > > IPFIX Mediation > > > > IPFIX Mediation is a function that offers one or multiple of the > > following capabilities: > > * rerouting input Flow Records/Packet Reports to a appropriate > > Collecting Process > > * replicating input Flow Records/Packet Reports > > * filtering and selecting Flow Records/Packet Report > > * aggregating input Flow Records/Packet Reports based on a new > > set of Flow Key field > > * correlating a set of Flow Records/Packet Reports for > > creating new Flow Records/Packet Reports with new metrics > > * changing the transport protocol which carries IPFIX Message > > * modifying Flow Records/Packet Reports > > The modification of Flow Records/Packet Reports includes > > these functions > > * changing the value of specified Information Elements > > * adding new Information Elements by deriving > > further Flow or > > packet properties from existing fields or > > calculating new metrics > > * deleting specified Information Elements. > > IPFIX Mediation can be included in any IPFIX Devices, such as routers, > > switches, NMS(Network Management Systems),. In an IPFIX Device, > > the IPFIX Mediation is located between Exporting Processes and > > Collecting Processes. > > "IPFIX Mediation is a function that offers one or multiple capabilities" > sounds a bit strange to me. > > Instead, we could define: > > IPFIX Mediation Function = Any functions that can be applied to entire > messages or individual records of IPFIX and related protocols. Examples > are: ... > > Intermediate Process (or: Mediation Process) = Process that implements > one or more IPFIX Mediation Functions. > > > IPFIX Mediator > > > > The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX > > Mediations capabilities. > > As far as I understood, IPFIX Mediator was previously defined as a > device that contains at least one Collecting Process and one Exporting > Process: > > CP --> some mediation function --> EP > > So, if a Mediation Function is applied at an Exporter that does not have > any Collecting Process, it is _not_ an IPFIX Mediator: > > CP --> MP --> some mediation function --> EP > > Of course, we can remove the restriction and say any device capable of > doing any mediation is an IPFIX Mediator. > > Yet, I would prefer to say: An IPFIX Mediator is an IPFIX Device that > contains one or more Mediation/Intermediate Processes. > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediation that receives IPFIX Messages > > from Original Exporter(s), and sends new IPFIX Messages to one or > > more Collector(s). For example, it may change the transport > > protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of > > IPFIX Proxy is a IPFIX Mediation that converts legacy protocol > > messages into an IPFIX Message. > > This definition does not work because "that receives IPFIX Messages from > Original Exporter(s)" prevents the reception of legacy protocols. > See also my proposed definition in another mail. > > Regards, > Gerhard > > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediation that ... > > > > Regards, Benoit. > > > >> Dear all, > >> > >> Atsushi Kobayashi wrote: > >> > >>> Gerhard Muenz wrote: > >>> > >>>> IPFIX Mediator Problem statement wrote: > >>>> > >>>>> IPFIX Mediation is an additional function to suit the needs of some > >>>>> measurement system. > >>>>> > >>>> Isn't IPFIX Mediation supposed to be an umbrella term which includes > >>>> IPFIX concentrators and IPFIX proxies? > >>>> > >>> I mean that IPFIX Mediator is umbrella term which includes IPFIX > >>> concentrators and IPFIX proxies. But, IPFIX Mediation is not. > >>> > >> I think there is still some confusion on what a number of terms that > >> came up during IPFIX Mediator discussions mean. Some of them are not > >> clearly defined and some are used interchangeably. From the top of my > >> head, these are: > >> > >> * IPFIX Mediator > >> * IPFIX Mediation > >> * IPFIX Mediation device > >> * Mediation Function > >> * Intermediate Function > >> * Intermediate Process > >> * Exporter with Mediation Function > >> * Exporter with Mediation > >> > >> How about we settle on a subset and give a clear(er) definition of these > >> terms? > >> > >> > >> I propose the following two definitions: > >> > >> * Intermediate Process: > >> a black box that processes Flow Records, i.e. that takes > >> Flow Records as its input and has Flow Records as its output. > >> > >> * IPFIX Mediator: > >> a device that can host zero or more Intermediate Processes > >> along with other Processes defined in IPFIX. > >> > >> > >> I think these two definitions can be used to describe all > >> currently-thought-of IPFIX Mediators by using zero or more Intermediate > >> Processes (IMPs), like so: > >> > >> * IPFIX Proxy: > >> Collector---Exporter > >> > >> * IPFIX Concentrator: > >> Collector---"IMP Aggregator"---Exporter > >> > >> * IPFIX Distributor: > >> Collector---"IMP Distributor"---Exporter(s) > >> > >> * IPFIX Masquerading Proxy: > >> Collector---"IMP Masquerade"---Exporter > >> > >> > >> I would like to hear as many comments/suggestions as possible, so we can > >> arrive at a clear definition of what an IPFIX Mediator is and what an > >> Intermediate Process can do! > >> > >> > >> Regards, > >> > >> Christoph > >> > >> > > From akoba@nttv6.net Thu Feb 5 01:10:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17F73A6B60 for ; Thu, 5 Feb 2009 01:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnH5aMG5DC0q for ; Thu, 5 Feb 2009 01:10:17 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 868603A687D for ; Thu, 5 Feb 2009 01:10:16 -0800 (PST) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:589f:6508:e4d:bfe]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n1599thO050654; Thu, 5 Feb 2009 18:09:55 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 05 Feb 2009 18:08:48 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492468F1.8050606@net.in.tum.de> References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> Message-Id: <20090205174830.D335.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 05 Feb 2009 18:09:55 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:10:17 -0000 Gerhard and all, I improve the problem statement draft according to following your suggestion. I added new section "Problem Statement" showing the problems that network operators have been facing. http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-4 And I added "implementation analysis" in each applicable examples. It includes several implementation examples other than IPFIX Mediation. I think the next version meets your suggestion. I would appreciate it if you put your comments in mail list. Thanks, Atsushi Kobayashi On Wed, 19 Nov 2008 20:28:49 +0100 Gerhard Muenz wrote: > I think it is ok to discuss what is possible without Mediation and to > show the limits of "state-of-the-art" IPFIX. > So, you could > - present a problem, > - show how the problem could be solved without mediation (if possible), > - argue why this solution is not optimal, and > - present how mediation enables a better solution. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From root@core3.amsl.com Tue Feb 10 08:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D587B3A69C3; Tue, 10 Feb 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210160001.D587B3A69C3@core3.amsl.com> Date: Tue, 10 Feb 2009 08:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 16:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-02.txt Pages : 24 Date : 2009-02-10 This document describes a framework for IPFIX Mediation. This framework details the IPFIX Mediation reference model and the components of an IPFIX Mediator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-10075907.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Wed Feb 11 07:40:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B6428C113 for ; Wed, 11 Feb 2009 07:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKcCyEeyBGTp for ; Wed, 11 Feb 2009 07:40:08 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4806E3A6D0D for ; Wed, 11 Feb 2009 07:40:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1BFe6M05838; Wed, 11 Feb 2009 16:40:06 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1BFe6t04352; Wed, 11 Feb 2009 16:40:06 +0100 (CET) Message-ID: <4992F155.2000307@cisco.com> Date: Wed, 11 Feb 2009 16:40:05 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------030600030103040401080602" Cc: Sven Anderson Subject: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:40:09 -0000 This is a multi-part message in MIME format. --------------030600030103040401080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt > 8.1. Transport Protocol Choice > > The proposed method is most effective using a reliable transport > protocol for the transfer of the Common Properties. Therefore the > use of PR-SCTP with the reliable mode or TCP is recommended. > However, if the path from the Exporting Process to the Collecting > Process is not fully reliable, the SCTP or TCP retransmission might > reduce the benefits of this specification. If the path from the > Exporting Process to the Collecting Process is full reliable, > the use > of UDP is less effective because the Common Properties have to > be re- > sent regularly. Do I understand that section correctly: If the path is reliable, you should use a reliable transport, and if the path is unreliable you should use unreliable UDP? Isn't that upside down? If the path is reliable, you can use UDP _without_ retransmission, no need for a reliable transport protocol then. We proposed the following text, removing the confusing sentence. NEW: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of PR-SCTP with the reliable mode or TCP is recommended. If the path from the Exporting Process to the Collecting Process is full reliable, the use of UDP is less effective because the Common Properties have to be re-sent regularly. Any objections? Pending on nobody objecting in a couple of work days, this editorial disambiguation will be applied*//*. Regards, Benoit. --------------030600030103040401080602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt
8.1.  Transport Protocol Choice

  The proposed method is most effective using a reliable transport
  protocol for the transfer of the Common Properties.  Therefore the
  use of PR-SCTP with the reliable mode or TCP is recommended.
  However, if the path from the Exporting Process to the Collecting
  Process is not fully reliable, the SCTP or TCP retransmission might
  reduce the benefits of this specification.  If the path from the
  Exporting Process to the Collecting Process is full reliable, the use
  of UDP is less effective because the Common Properties have to be re-
  sent regularly.

Do I understand that section correctly: If the path is reliable, you should use a reliable transport, and if the path is unreliable you should use unreliable UDP? Isn't that upside down? If the path is reliable, you can use UDP _without_ retransmission, no need for a reliable transport protocol then.
We proposed the following text, removing the confusing sentence.
NEW:

   The proposed method is most effective using a reliable transport
   protocol for the transfer of the Common Properties.  Therefore the
   use of PR-SCTP with the reliable mode or TCP is recommended.
   If the path from the Exporting Process to the Collecting Process is
   full reliable, the use of UDP is less effective because the Common
   Properties have to be re-sent regularly.
Any objections?
Pending on nobody objecting in a couple of work days,  this editorial disambiguation will be applied.

Regards, Benoit.
--------------030600030103040401080602-- From trammell@tik.ee.ethz.ch Wed Feb 11 07:50:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92C13A6D08 for ; Wed, 11 Feb 2009 07:50:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKLmh-zBYDvE for ; Wed, 11 Feb 2009 07:50:08 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id BC0023A6BFC for ; Wed, 11 Feb 2009 07:50:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 737E5D932D; Wed, 11 Feb 2009 16:50:10 +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 tk1fIYZsjH23; Wed, 11 Feb 2009 16:50:10 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 140A0D9313; Wed, 11 Feb 2009 16:50:10 +0100 (MET) Message-Id: <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> From: Brian Trammell To: Benoit Claise In-Reply-To: <4992F155.2000307@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 16:50:09 +0100 References: <4992F155.2000307@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Sven Anderson , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:50:12 -0000 Hi Benoit, all, Hm, that's still kind of confusing. First off, there's no "reliable mode" in PR-SCTP. SCTP is modeless, reliability is per-message. PR- SCTP can provide "fully reliable" transport. But this terminology seems to be overloaded: "If the path from the Exporting Process to the Collecting Process is full reliable" What does this mean, precisely? My assumption is that it means "if the link between the Exporting Process and the Collecting Process has low loss and reordering characteristics..." However, the guidance doesn't actually change depending on the loss characteristics of the lower layer: RR prefers reliable transport for Common Properties, full stop. I'd suggest (as usual...) removing any mention of UDP as recommended: NEW: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of PR-SCTP with the full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. Cheers, Brian On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: > Dear all, > > We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >> 8.1. Transport Protocol Choice >> >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the >> use of PR-SCTP with the reliable mode or TCP is recommended. >> However, if the path from the Exporting Process to the Collecting >> Process is not fully reliable, the SCTP or TCP retransmission might >> reduce the benefits of this specification. If the path from the >> Exporting Process to the Collecting Process is full reliable, the >> use >> of UDP is less effective because the Common Properties have to be >> re- >> sent regularly. > > Do I understand that section correctly: If the path is reliable, you > should use a reliable transport, and if the path is unreliable you > should use unreliable UDP? Isn't that upside down? If the path is > reliable, you can use UDP _without_ retransmission, no need for a > reliable transport protocol then. > We proposed the following text, removing the confusing sentence. > NEW: > > The proposed method is most effective using a reliable transport > protocol for the transfer of the Common Properties. Therefore the > use of PR-SCTP with the reliable mode or TCP is recommended. > If the path from the Exporting Process to the Collecting Process is > full reliable, the use of UDP is less effective because the Common > Properties have to be re-sent regularly. > > Any objections? > Pending on nobody objecting in a couple of work days, this > editorial disambiguation will be applied. > > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Feb 12 00:38:15 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AED3A6AA4 for ; Thu, 12 Feb 2009 00:38:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeEsnxTbhxgF for ; Thu, 12 Feb 2009 00:38:14 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 0B2AD3A6930 for ; Thu, 12 Feb 2009 00:38:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1C8cCh19380; Thu, 12 Feb 2009 09:38:12 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1C8cBt09945; Thu, 12 Feb 2009 09:38:11 +0100 (CET) Message-ID: <4993DFF3.9090508@cisco.com> Date: Thu, 12 Feb 2009 09:38:11 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <4992F155.2000307@cisco.com> <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> In-Reply-To: <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sven Anderson , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:38:15 -0000 Brian, First of all, I would like to have Sven's feedback, as he was the one asking for this change. Then, see inline. > Hi Benoit, all, > > Hm, that's still kind of confusing. First off, there's no "reliable > mode" in PR-SCTP. SCTP is modeless, reliability is per-message. > PR-SCTP can provide "fully reliable" transport. But this terminology > seems to be overloaded: > > "If the path from the Exporting Process to the Collecting Process is > full reliable" > > What does this mean, precisely? My assumption is that it means "if the > link between the Exporting Process and the Collecting Process has low > loss and reordering characteristics..." However, the guidance doesn't > actually change depending on the loss characteristics of the lower > layer: RR prefers reliable transport for Common Properties, full stop. > I'd suggest (as usual...) removing any mention of UDP as recommended: The recommendation doesn't change, agreed. But the sentence is a warning/clarification against the use of UDP, even if the path is fully reliable. So my preference is to keep this sentence (slightly modified, see below)... however, this is a minor point IMHO. What are the others thinking? > > NEW: > The proposed method is most effective using a reliable transport > protocol for the transfer of the Common Properties. Therefore the use > of PR-SCTP with the full reliability or TCP is recommended for the > transmission of IPFIX Messages containing Common Properties. NEW: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of PR-SCTP with the full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. If the path from the Exporting Process to the Collecting Process is fully reliable (i.e., no loss), the use of UDP is less effective because the Common Properties have to be re-sent regularly. Regards, Benoit. > > Cheers, > > Brian > > On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: > >> Dear all, >> >> We received the following remark from Sven regarding >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >> >>> 8.1. Transport Protocol Choice >>> >>> The proposed method is most effective using a reliable transport >>> protocol for the transfer of the Common Properties. Therefore the >>> use of PR-SCTP with the reliable mode or TCP is recommended. >>> However, if the path from the Exporting Process to the Collecting >>> Process is not fully reliable, the SCTP or TCP retransmission might >>> reduce the benefits of this specification. If the path from the >>> Exporting Process to the Collecting Process is full reliable, the use >>> of UDP is less effective because the Common Properties have to be re- >>> sent regularly. >> >> Do I understand that section correctly: If the path is reliable, you >> should use a reliable transport, and if the path is unreliable you >> should use unreliable UDP? Isn't that upside down? If the path is >> reliable, you can use UDP _without_ retransmission, no need for a >> reliable transport protocol then. >> We proposed the following text, removing the confusing sentence. >> NEW: >> >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the >> use of PR-SCTP with the reliable mode or TCP is recommended. >> If the path from the Exporting Process to the Collecting Process is >> full reliable, the use of UDP is less effective because the Common >> Properties have to be re-sent regularly. >> >> Any objections? >> Pending on nobody objecting in a couple of work days, this editorial >> disambiguation will be applied. >> >> Regards, Benoit. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Thu Feb 12 01:14:07 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92DC28C0E7 for ; Thu, 12 Feb 2009 01:14:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXr9BW0Am4-q for ; Thu, 12 Feb 2009 01:14:06 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 921AE28C0FC for ; Thu, 12 Feb 2009 01:14:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 33519D932E; Thu, 12 Feb 2009 10:14:09 +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 eA1gUhHIVW3r; Thu, 12 Feb 2009 10:14:08 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id AF1E8D9398; Thu, 12 Feb 2009 10:14:08 +0100 (MET) Message-Id: <4D4BAAC7-3865-4D51-BD54-BC01D0E51854@tik.ee.ethz.ch> From: Brian Trammell To: Benoit Claise In-Reply-To: <4993DFF3.9090508@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 10:14:08 +0100 References: <4992F155.2000307@cisco.com> <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> <4993DFF3.9090508@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Sven Anderson , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:14:07 -0000 Hi, Benoit, Two minor points: 1. Change "...the use of PR-SCTP with the full reliability..." to "...the use of PR-SCTP with full reliability..." (no need for the article). Oops, sorry about that. 2. This proposed change is much, much clearer. However, I'm still not convinced that (a) the recommendation against UDP is _really_ dependent on the loss characteristics of the lower layer; or that (b) on a second reading, this should really be a recommendation against UDP, but rather a caveat given that UDP has already been chosen (after all, if you're using UDP, you're doing NetFlow replacement, you've presumably already read Section 6.2 of RFC5153 and know all the caveats, and you're going to use UDP anyway). So I think the recommendation here would be clearer and more internally consistent if it restated the caveats in Section 4.2, instead: So, I'd suggest: NEW: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of PR-SCTP with full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. Note that this method loses some of its effectiveness if UDP is used for the transmission of IPFIX Messages containing Common Properties, since the Common Properties MUST then, like Templates, be re-sent at regular intervals as in Section 4.2. Cheers, Brian On Feb 12, 2009, at 9:38 AM, Benoit Claise wrote: > Brian, > > First of all, I would like to have Sven's feedback, as he was the > one asking for this change. > Then, see inline. >> Hi Benoit, all, >> >> Hm, that's still kind of confusing. First off, there's no "reliable >> mode" in PR-SCTP. SCTP is modeless, reliability is per-message. PR- >> SCTP can provide "fully reliable" transport. But this terminology >> seems to be overloaded: >> >> "If the path from the Exporting Process to the Collecting Process >> is full reliable" >> >> What does this mean, precisely? My assumption is that it means "if >> the link between the Exporting Process and the Collecting Process >> has low loss and reordering characteristics..." However, the >> guidance doesn't actually change depending on the loss >> characteristics of the lower layer: RR prefers reliable transport >> for Common Properties, full stop. I'd suggest (as usual...) >> removing any mention of UDP as recommended: > The recommendation doesn't change, agreed. > But the sentence is a warning/clarification against the use of UDP, > even if the path is fully reliable. > So my preference is to keep this sentence (slightly modified, see > below)... however, this is a minor point IMHO. > What are the others thinking? > > >> >> NEW: >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the >> use of PR-SCTP with the full reliability or TCP is recommended for >> the transmission of IPFIX Messages containing Common Properties. > NEW: > The proposed method is most effective using a reliable transport > protocol for the transfer > of the Common Properties. Therefore the use of PR-SCTP with the > full reliability or TCP > is recommended for the transmission of IPFIX Messages containing > Common Properties. > If the path from the Exporting Process to the Collecting Process > is fully reliable (i.e., no loss), > the use of UDP is less effective because the Common Properties > have to be re-sent regularly. > > > Regards, Benoit. >> >> Cheers, >> >> Brian >> >> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: >> >>> Dear all, >>> >>> We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >>>> 8.1. Transport Protocol Choice >>>> >>>> The proposed method is most effective using a reliable transport >>>> protocol for the transfer of the Common Properties. Therefore the >>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>> However, if the path from the Exporting Process to the Collecting >>>> Process is not fully reliable, the SCTP or TCP retransmission >>>> might >>>> reduce the benefits of this specification. If the path from the >>>> Exporting Process to the Collecting Process is full reliable, >>>> the use >>>> of UDP is less effective because the Common Properties have to >>>> be re- >>>> sent regularly. >>> >>> Do I understand that section correctly: If the path is reliable, >>> you should use a reliable transport, and if the path is unreliable >>> you should use unreliable UDP? Isn't that upside down? If the path >>> is reliable, you can use UDP _without_ retransmission, no need for >>> a reliable transport protocol then. >>> We proposed the following text, removing the confusing sentence. >>> NEW: >>> >>> The proposed method is most effective using a reliable transport >>> protocol for the transfer of the Common Properties. Therefore the >>> use of PR-SCTP with the reliable mode or TCP is recommended. >>> If the path from the Exporting Process to the Collecting Process >>> is >>> full reliable, the use of UDP is less effective because the Common >>> Properties have to be re-sent regularly. >>> >>> Any objections? >>> Pending on nobody objecting in a couple of work days, this >>> editorial disambiguation will be applied. >>> >>> Regards, Benoit. >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From salcock@cs.waikato.ac.nz Sun Feb 15 18:31:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF883A67DF for ; Sun, 15 Feb 2009 18:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52jEqYgrLdNB for ; Sun, 15 Feb 2009 18:31:29 -0800 (PST) Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by core3.amsl.com (Postfix) with ESMTP id 9D78E3A672F for ; Sun, 15 Feb 2009 18:31:29 -0800 (PST) Received: from voodoo.cs.waikato.ac.nz ([130.217.250.13]) by zombie.scms.waikato.ac.nz with esmtp (Exim 4.69) (envelope-from ) id 1LYtGi-0004kY-5W for ipfix@ietf.org; Mon, 16 Feb 2009 15:31:36 +1300 Message-ID: <4998D006.1030106@cs.waikato.ac.nz> Date: Mon, 16 Feb 2009 15:31:34 +1300 From: Shane Alcock User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 02:31:30 -0000 Hi all, I'm pleased to announce that maji, an open source implementation of an IPFIX meter developed at the University of Waikato, has finally been released. Some of the major features include: * Read packets from a variety of sources including PCAP interfaces, trace files and DAG capture cards * Support for over 50 different standard information elements defined in RFC 5101 * Define your own data and option templates, rather than being limited to fixed templates * Export IPFIX messages via SCTP, TCP or UDP, or export IPFIX flow records directly to an SQLite database One of the design goals for maji was to create a framework that could be utilised by researchers to test new concepts and ideas for IPFIX without having to implement the entire protocol themselves. To this end, maji can be easily extended to include new information elements, export formats or special templates. A series of developer notes are included as part of the documentation that should aid anyone looking to build upon our code. Further details and a link to download maji can be found at http://research.wand.net.nz/software/maji.php We appreciate any feedback you might have about maji. Please direct any questions, comments or bug reports to myself or feel free to file a ticket in our bug tracker at http://www.wand.net.nz/trac/traceflow_ipfix Shane Alcock Research Assistant WAND Network Research Group University of Waikato Hamilton, New Zealand Email: salcock@cs.waikato.ac.nz From dromasca@avaya.com Tue Feb 17 08:28:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B840528C140; Tue, 17 Feb 2009 08:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYIso4nYAiFJ; Tue, 17 Feb 2009 08:28:15 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8291A28C13D; Tue, 17 Feb 2009 08:28:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,224,1233550800"; d="scan'208";a="137730537" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Feb 2009 11:28:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Feb 2009 11:28:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 17:27:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-mib-05.txt Thread-Index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQ== From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:28:16 -0000 Please find below the AD (and MIB doctor) review of draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for IETF Last Call. Please address the issues below and issue a new I-D.=20 Part of the comments were contributed by Bert Wijnen.=20 I have divided the comments into Technical and Editorial.=20 Thanks and Regards, Dan T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291 T2. There is no real justification for defining a new TC for IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead.=20 T3. The top level structure of the MIB does not follow the recommendation in Appendix D of RFC 4181 concerning the OID layout:=20 xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) T4. The object iffixTransportSessionProtocol uses only 3 out of the 255 possible values in the range (6, 17, 132). A better SYNTAX would be just INTEGER and then enumerate the three values in the MODULE-COMPLIANCE clause. This would allow future changes by just another MODULE-COMPLIANCE if there is a need to add a new protocol. If you believe that another transport will be never added the appropriate SYNTAX would be INTEGER (6|17|132). Also provide http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml as REFERENCE. T5. There is only one InetAddressType object for both source and destination addresses. Does this mean that an IPFIX session is only IPv4 to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a layman one. In any case, it would be good to write an explanation, as users of the RFC 4001 addresses TCs are used to always encounter pairs of type-address objects.=20 T6. Why are the address type and addresses objects only valid for UDP and TCP, and not for SCTP? Are not STCP session also conducted between IP hosts that can be described by IP addresses?=20 T7. What does 'this object is only valid' mean for the address type and addresses objects? What is returned by the agent in this case on a Get operation on these objects?=20 T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more appropriate SYNTAX for the ipfixTransportSessionSourcePort and ipfixTransportSessionDestinationPort objects T9. I cannot figure out what is the role of all the DEFVAL clauses in this MIB module. All the MIB is read-only and there is no dynamic row creation. Why are they needed?=20 T10. Many of the objects in the MIB modules - especially counters and gauges - would benefit from defining UNITS clauses. In some places they are mentioned in the DESCRIPTION clauses, but using explicit UNITS clauses wherever possible is better.=20 T11. Some object names in table do not respect the naming conventions that recommends that table names and objects have an identical suffix - ipfixObservationDomainId, ipfixObservationPointGroupReference, ipfixPhysicalEntity, ipfixPhysicalEntityDirection T12. Some objects are completely missing REFERENCE clauses - especially in the first tables o the MIB. Some other clauses could benefit from more exact referencing, saying just [RFC5101] without mentioning the exact section is not very useful.=20 T13. Why is the range of ipfixTemplateDefinitionLength 1..2147483547)? According to RFC 5101, section 7, page 31 it looks like it should be (0..65535) T14. Give http://www.iana.org/assignments/enterprise-numbers/ as REFERENCE for ipfixTemplateDefinitionEnterprise T15. Use hex notations for describing values in the DESCRIPTION clause of ipfixTemplateDefintionFlags - the decimal values do not correspond to the bits positions T16. ipfixExportEntry leads to a warning in the smicng compilation=20 W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables T17. A couple of enumerated objects start to value 0 which is not recommended unless special cases. Are there special cases here for ipfixExportMemberType and ipfixPhysicalEntityDirection T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC 4181) for the following objects: ipfixMeteringProcessId, ipfixObservationPointGroupReference, ipfixObservationPointIndex, ipfixTransportSessionRate T19. I cannot understand what useful information carries ipfixmeteringProcessId - it is not an index and its value is implementation dependent.=20 T20. Does it make sense for the ipfixSelectorFunction to point to a function that is not available?=20 T21. I assume that selection functions will be added in the future. If I am wrong please delete all mention of extensibility and take out the ipfixSelectorFunctions group. If I am right, I suggest to put ipfixSelectorFunctions in a separate MIB module that will be IANA maintained, so that new functions can be added in the future without the need to revise the MIB module and the RFC. The separate MIB module will become the initial version of the IANA maintained module, and new selector functions will be added using for example Expert Review policy. T22. it looks like Gauge32 would be a better SYNTAX for the following objects: ipfixTransportSessionRate, ipfixMeteringProcessCacheActiveFlows, ipfixMetering ProcessCacheInactiveFlows T23. How is ipfixTransportSessionRate computed? Every second? Every T seconds? T=3D? T24. I am wondering whether more counters in this MIB module need to be Counter64 rather than Counter32 - especially the bytes and packets counters T25. There is no definition of the discontinuity behavior of all the counter objects or definition of discontinuity objects. =20 T26. It looks like Counter32 (or Counter64) with the appropriate discontinuity objects are better SYNTAX for ipfixSelectorStatsPacketsObserved and ipfixSelectorStatspacketsDropped.=20 T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain statements about the mandatory or optional characteristics of the objects. This is inappropriate, such statements must be made in MODULE-COMPLIANCE definitions, not in OBJECT-GROUP.=20 T.28. Security Consideration sections - The description of the vulnerability of objects in the tables should be more precise than 'contains configuration data that might be sensitive'.=20 E1. Section 5.1 s/is defined in the MIB/is defined in the MIB module/ E2. The language in the sub-section of section 5 may be polished - for example in section 5.3 and 5.4 s/may want to export/is configured to export/ E3. Section 5.6 s/consists of a set of function/consists of a set of functions/ E4. Section 5.6 - 'the Metering Process table (ipfixMetering ProcessTable) is grouped by maintained by ...' - this phrase needs to be fixed.=20 E5. Section 6.1 - s/they should also implement the ENTITY MIB/they SHOULD also implement the ENTITY MIB/ E6. Section 6.1 s/all entries in the Observation Point Table contain an ipfixPhysicalEntity of zero(0)/all values of the ipfixPhysicalEntity columns in the ipfixObservationPointTable are 0 and the values of the ipfixPhysicalEntityDirection columns are none(0).=20 E7. The DESCRIPTION clause and the name of the object ipfixTransportSessionMode seem mis-leading. I think that this object describes the device role in a session, not the mode of the session in other words it's an attribute of the device that runs the agent and not of the session.=20 E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is confusing. The second and third paragraph seem to duplicate the content of the first paragraph. The last phrase of the clause seems to belong rather in the DESCRIPTION clause of the table than here.=20 E9. DESCRIPTION clause of ipfixObservationPointIndex - is this 'management system' or rather 'management agent'?=20 E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object contains 0/the value of the object is 0/ E11. What does 'a direction is not applicable' mean in the DESCRIPTION clause of ipfixPhysicalEntityDirection?=20 From n.brownlee@auckland.ac.nz Thu Feb 19 21:10:43 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FF83A6AEA for ; Thu, 19 Feb 2009 21:10:43 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfcVZXyP+R8d for ; Thu, 19 Feb 2009 21:10:42 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 737183A6903 for ; Thu, 19 Feb 2009 21:10:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C228919CDB for ; Fri, 20 Feb 2009 18:10:52 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4bcaXB3qWcM for ; Fri, 20 Feb 2009 18:10:52 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 907B519C39 for ; Fri, 20 Feb 2009 18:10:52 +1300 (NZDT) Message-ID: <499E3B56.1050207@auckland.ac.nz> Date: Fri, 20 Feb 2009 18:10:46 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT Agenda for San Francisco IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 05:10:43 -0000 Hi all: A first draft agenda for our IPFIX session in San Francisco is appended below. Please send any additional agenda items, or suggestions for improvements to me. Cheers, Nevil -- --------------------------------------------------------------------- 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 ====================================================== Ip Flow Information Export WG (ipfix) IETF #74, San Francisco Monday, 23 Mar 09 at 1300-1500 ====================================================== Chairs: Juergen Quittek Nevil Brownlee >>> DRAFT <<< AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status = 5 min [In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt - draft-ietf-ipfix-testing-04.txt - draft-ietf-psamp-framework-13.txt - draft-ietf-psamp-sample-tech-10.txt - draft-ietf-psamp-protocol-09.txt - draft-ietf-psamp-info-11.txt] 3. Information Element Registry status = 10 min IANA's XML page for this are now at http://www.iana.org/assignments/ipfix/ipfix.xhtml We are now handling errata found in RFC 5102, IANA should change the registry for such changes; We need to establish a procedure for handling changes in other IEs 4. Drafts submitted to IESG = 20 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-05.txt 3 Nov 08 MIB Doctors have requested a revised draft (10 min) b) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-03.txt 24 Oct 08 c) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt 14 Jul 08 ( 5 min) 5. Current WG drafts = 40 min a) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 b) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-01.txt 3 Nov 08 c) IPFIX Mediation: (Kobayashi Atsushi) (25 min) - draft-ietf-ipfix-mediators-problem-statement-02.txt 4 Feb 09 - draft-ietf-ipfix-mediators-framework-02.txt (35 min) 10 Feb 09 6. Other drafts = 20 min a) Flow Selection (Tanja Zseby) (10 min) b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) - draft-boschi-ipfix-anon-02 12 Jan 09 (10 min) 7. Any Other Drafts ??? = 20 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=74 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org From muenz@net.in.tum.de Mon Feb 23 08:03:21 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFC628C142 for ; Mon, 23 Feb 2009 08:03:21 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDkqsjBYHP-a for ; Mon, 23 Feb 2009 08:03:20 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id B32443A68C2 for ; Mon, 23 Feb 2009 08:03:19 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 2A5BE48371; Mon, 23 Feb 2009 17:03:35 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 169524FB4; Mon, 23 Feb 2009 17:03:35 +0100 (CET) Message-ID: <49A2C8D8.3000402@net.in.tum.de> Date: Mon, 23 Feb 2009 17:03:36 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Shane Alcock References: <4998D006.1030106@cs.waikato.ac.nz> In-Reply-To: <4998D006.1030106@cs.waikato.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040000000109000000090605" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:03:21 -0000 This is a cryptographically signed message in MIME format. --------------ms040000000109000000090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shane, all, I had a quick lood at the code of Maji because I was interested how you configure your templates. Please tell me if the following is correct: It seems that you configure the templates exactly as they will be exported. The definition of the templates implicitly configures the metering process. Packets that contain all fields of a given template are aggregated into a corresponding flow record. On the other hand, if any field of the template is missing, the packet is not accounted. Hence, the configuration of the template implicitly defines a packet filt= er. This is a feasible approach. BTW, we did the same in our monitoring probe implementation Vermont. However, in the course of standardizing the IPFIX configuration model, we got to a different solution where we configure packet filters and "cache layouts" of the metering process. The cache layout defines a superset of all fields that are contained in the resulting records if they are available in the incoming packets. Hence, we do not drop a packet or flow if a field is missing. Instead, it is accounted in a record that does not include this field. As a consequence, one cache layout definition may result in multiple templates that have to be generated on demand by the exporting process. The idea is to clearly separate metering and export functions in the configuration model. Also, the configuration of cache layouts instead of templates is closer to Cisco's current version of Flexible Netflow. As a downside, the exporting process must support dynamic template generation, which can be quite complex to implement. After long discussions with Paul, I was convinced that configuring the metering process through the template is putting the cart before the hors= e. However, I also think that the configuration of a fixed set of fields per record (as in Maji and Vermont) has its merits because it easy to implement. If there is support from your side (and maybe others), we can extend the configuration model such that the configuration of such IPFIX implementations is supported as well. Regards, Gerhard Shane Alcock wrote: > Hi all, >=20 > I'm pleased to announce that maji, an open source implementation of an > IPFIX meter developed at the University of Waikato, has finally been > released. >=20 > Some of the major features include: > * Read packets from a variety of sources including PCAP interfaces, > trace files and DAG capture cards > * Support for over 50 different standard information elements define= d > in RFC 5101 > * Define your own data and option templates, rather than being > limited to fixed templates > * Export IPFIX messages via SCTP, TCP or UDP, or export IPFIX flow > records directly to an SQLite database >=20 > One of the design goals for maji was to create a framework that could b= e > utilised by researchers to test new concepts and ideas for IPFIX withou= t > having to implement the entire protocol themselves. To this end, maji > can be easily extended to include new information elements, export > formats or special templates. A series of developer notes are included > as part of the documentation that should aid anyone looking to build > upon our code. >=20 > Further details and a link to download maji can be found at > http://research.wand.net.nz/software/maji.php >=20 > We appreciate any feedback you might have about maji. Please direct any= > questions, comments or bug reports to myself or feel free to file a > ticket in our bug tracker at http://www.wand.net.nz/trac/traceflow_ipfi= x >=20 > Shane Alcock > Research Assistant > WAND Network Research Group > University of Waikato > Hamilton, New Zealand > Email: salcock@cs.waikato.ac.nz >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040000000109000000090605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjIzMTYwMzM2WjAjBgkqhkiG9w0BCQQxFgQU D+2CNPYxZFVlQpHv4BAi13cmXMowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAKYxlh7W7xZBHUOsVH5XNaxqsSWn6pbbEOzz07Y/4fFmixge 11/5qu9A++utgSlQGsRHs2hKUqQMqjXmrzahkWR1bYDvquUdq+LkHm5c8ugv5HOJMjWq+eVf 9N26yOZHWoTJucMN28nEpSwzHSgUbWaQ3foqY2BYeKnuaVzeIegvye4/vd/NXGVGGMvHggcA SWAAycv5cGsHo9ZO1QKFXuWA4VVRXxqCNwi2pvAxGAlUDC0+hRffR3j+paBbTDhy+yrfqE3H W+UavdNphVo+0SKjGwDW9u38GjFZzBW6lZlZVACxpoZu9SUZtCC4gy8D0q2TE7Dgon+kXEs2 Mj4ZODgAAAAAAAA= --------------ms040000000109000000090605-- From paitken@cisco.com Mon Feb 23 13:55:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C6528C203 for ; Mon, 23 Feb 2009 13:55:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6QsKnrCl71o for ; Mon, 23 Feb 2009 13:55:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F90328C18B for ; Mon, 23 Feb 2009 13:55:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,256,1233532800"; d="scan'208";a="34603988" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2009 21:55:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1NLtDb3001730; Mon, 23 Feb 2009 22:55:13 +0100 Received: from [10.61.108.129] (dhcp-10-61-108-129.cisco.com [10.61.108.129]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1NLt8eo023611; Mon, 23 Feb 2009 21:55:08 GMT Message-ID: <49A31B3C.8070004@cisco.com> Date: Mon, 23 Feb 2009 21:55:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> In-Reply-To: <49A2C8D8.3000402@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1079; t=1235426113; x=1236290113; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20Maji=20-=20an=20open=0A=20source=20I PFIX=20meter=20implementation |Sender:=20; bh=aEmqZf4Qhf5TjRHTfG/1EtqUbvQcsmXvxGGoeVGm/dE=; b=LBgF4ValP8oqzp4ew26oqhxE080SKxCv3bDXzFMm8sW89eaF1YV5F9tWus UDMyzvqn8hU2H5IQ/dRegtCVJL/nGopBRDLirsjx5wwl+kFnMAcQ8wxbYp9F pJXrTy4C7T; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:55:11 -0000 Gerhard, Shane, > After long discussions with Paul, I was convinced that configuring the > metering process through the template is putting the cart before the horse. A support question I received some years ago asked how to reconfigure our NFv9 templates - because they thought this would change what was being monitored. It wouldn't; that's never been our model. Export has always followed from monitoring and not the other way around. > However, I also think that the configuration of a fixed set of fields > per record (as in Maji and Vermont) has its merits because it easy to > implement. > > If there is support from your side (and maybe others), we can extend the > configuration model such that the configuration of such IPFIX > implementations is supported as well. The existing IPFIX-CONFIG design already allows for this, if you consider that the cache is being configured (rather than the exporter, as in Maji and Vermont) and that the exporter matches with it 1:1. P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From salcock@cs.waikato.ac.nz Mon Feb 23 14:53:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED82B3A6835 for ; Mon, 23 Feb 2009 14:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCBeMoqcEuLQ for ; Mon, 23 Feb 2009 14:53:10 -0800 (PST) Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by core3.amsl.com (Postfix) with ESMTP id A4C193A69AB for ; Mon, 23 Feb 2009 14:52:42 -0800 (PST) Received: from voodoo.cs.waikato.ac.nz ([130.217.250.13]) by zombie.scms.waikato.ac.nz with esmtp (Exim 4.69) (envelope-from ) id 1LbjfV-000329-CE; Tue, 24 Feb 2009 11:52:57 +1300 Message-ID: <49A328C6.4040301@cs.waikato.ac.nz> Date: Tue, 24 Feb 2009 11:52:54 +1300 From: Shane Alcock User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> In-Reply-To: <49A2C8D8.3000402@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:53:11 -0000 Gerhard, all. Thanks for taking the time to look over our efforts! Further responses in-line. Gerhard Muenz wrote: > Hi Shane, all, > > I had a quick lood at the code of Maji because I was interested how you > configure your templates. > > Please tell me if the following is correct: > It seems that you configure the templates exactly as they will be > exported. The definition of the templates implicitly configures the > metering process. Packets that contain all fields of a given template > are aggregated into a corresponding flow record. On the other hand, if > any field of the template is missing, the packet is not accounted. > Hence, the configuration of the template implicitly defines a packet filter. > This is true to an extent. If any field that is part of the flow key for a template is missing, then the packet will be essentially ignored. If the field is not part of the flow key, a "default" value is provided for that field, usually either 0 or MAXINT (depending on whether zero is a valid value for the field or not). This is far from an ideal approach, as it would be very easy for a collector or analysis program to misinterpret the defaults as genuine measurements. > This is a feasible approach. BTW, we did the same in our monitoring > probe implementation Vermont. > > However, in the course of standardizing the IPFIX configuration model, > we got to a different solution where we configure packet filters and > "cache layouts" of the metering process. The cache layout defines a > superset of all fields that are contained in the resulting records if > they are available in the incoming packets. Hence, we do not drop a > packet or flow if a field is missing. Instead, it is accounted in a > record that does not include this field. As a consequence, one cache > layout definition may result in multiple templates that have to be > generated on demand by the exporting process. > > The idea is to clearly separate metering and export functions in the > configuration model. Also, the configuration of cache layouts instead of > templates is closer to Cisco's current version of Flexible Netflow. > As a downside, the exporting process must support dynamic template > generation, which can be quite complex to implement. > This would alleviate the problems with the "default" values and an implementation of this approach may make it into a subsequent version of maji (at least for non-key elements) :) > After long discussions with Paul, I was convinced that configuring the > metering process through the template is putting the cart before the horse. > However, I also think that the configuration of a fixed set of fields > per record (as in Maji and Vermont) has its merits because it easy to > implement. > > If there is support from your side (and maybe others), we can extend the > configuration model such that the configuration of such IPFIX > implementations is supported as well. > > Maji has always been developed primarily as a tool to enable and aid network measurement research. The design has been based around the idea of placing control over what gets metered entirely into the hands of the user. The template-driven configuration approach works really well in this regard and I think it is important for it to at least be acknowledged as valid within the configuration model, possibly depending on the circumstances in which the meter is operating. Shane From muenz@net.in.tum.de Tue Feb 24 01:32:18 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE37D3A6A84 for ; Tue, 24 Feb 2009 01:32:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm5dgisWTWTq for ; Tue, 24 Feb 2009 01:32:17 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 86EB03A6942 for ; Tue, 24 Feb 2009 01:32:17 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id C14AC483A4; Tue, 24 Feb 2009 10:32:04 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B719D2BB3; Tue, 24 Feb 2009 10:32:04 +0100 (CET) Message-ID: <49A3BE96.3020304@net.in.tum.de> Date: Tue, 24 Feb 2009 10:32:06 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Shane Alcock References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A328C6.4040301@cs.waikato.ac.nz> In-Reply-To: <49A328C6.4040301@cs.waikato.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040500090500080009090607" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 09:32:18 -0000 This is a cryptographically signed message in MIME format. --------------ms040500090500080009090607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shane, Please find replies inline. Shane Alcock wrote: > Gerhard Muenz wrote: >> Please tell me if the following is correct: >> It seems that you configure the templates exactly as they will be >> exported. The definition of the templates implicitly configures the >> metering process. Packets that contain all fields of a given template >> are aggregated into a corresponding flow record. On the other hand, if= >> any field of the template is missing, the packet is not accounted. >> Hence, the configuration of the template implicitly defines a packet >> filter. >> =20 > This is true to an extent. If any field that is part of the flow key fo= r > a template is missing, then the packet will be essentially ignored. If > the field is not part of the flow key, a "default" value is provided fo= r > that field, usually either 0 or MAXINT (depending on whether zero is a > valid value for the field or not). This is far from an ideal approach, > as it would be very easy for a collector or analysis program to > misinterpret the defaults as genuine measurements. Ok, so you distinguish between missing flow key fields and non-key fields= =2E What do you mean by "depending on whether zero is valid or not"? Do you use zero if it is a valid value? Or is the default value chosen to be invalid so that the collector can recognize it as such? Anyway, records are generated that contain fields that contain wrong or invalid values. Netflow used to do similar things. Often, the collector can recognize such invalid fields, for example if a TCP flags field appears in a UDP flow. However, I do not think that the export of invalid field values is conform to the IPFIX standard. If we wanted to do so, we would need to define which values to be considered as invalid for every Information Element. This is not done in RFC5102. >> This is a feasible approach. BTW, we did the same in our monitoring >> probe implementation Vermont. >> >> However, in the course of standardizing the IPFIX configuration model,= >> we got to a different solution where we configure packet filters and >> "cache layouts" of the metering process. The cache layout defines a >> superset of all fields that are contained in the resulting records if >> they are available in the incoming packets. Hence, we do not drop a >> packet or flow if a field is missing. Instead, it is accounted in a >> record that does not include this field. As a consequence, one cache >> layout definition may result in multiple templates that have to be >> generated on demand by the exporting process. >> >> The idea is to clearly separate metering and export functions in the >> configuration model. Also, the configuration of cache layouts instead = of >> templates is closer to Cisco's current version of Flexible Netflow. >> As a downside, the exporting process must support dynamic template >> generation, which can be quite complex to implement. >> =20 > This would alleviate the problems with the "default" values and an > implementation of this approach may make it into a subsequent version o= f > maji (at least for non-key elements) :) Ok :) but if restricted to non-key elements, you still implicitly drop packets that do not have all flow key fields. >> After long discussions with Paul, I was convinced that configuring the= >> metering process through the template is putting the cart before the >> horse. >> However, I also think that the configuration of a fixed set of fields >> per record (as in Maji and Vermont) has its merits because it easy to >> implement. >> >> If there is support from your side (and maybe others), we can extend t= he >> configuration model such that the configuration of such IPFIX >> implementations is supported as well. >> >> =20 > Maji has always been developed primarily as a tool to enable and aid > network measurement research. The design has been based around the idea= > of placing control over what gets metered entirely into the hands of th= e > user. The template-driven configuration approach works really well in > this regard and I think it is important for it to at least be > acknowledged as valid within the configuration model, possibly dependin= g > on the circumstances in which the meter is operating. Thanks for your feedback. I'll propose a solution in an answer to Paul's reply in the parallel thread. Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040500090500080009090607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MDkzMjA2WjAjBgkqhkiG9w0BCQQxFgQU 9oT5MqZpUsUNhsyGDXR9c3LQGJswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJTqgDxKNDUh59NdSPgMQ3aT17LFcNrcMJGgNZLghX7WQkcO Yyqg3oJC4OQN53R9OZqC8JNq3kumH8+mbpwylck0xOtQmG1U/qCHTA6aCp4qEBrh7pzJ7RO1 8OOmp30KwvVdSYAn5e77uhRlPoXqxI8n7w/cpROzL3fqTiVNCb45qBL9Fp30wkJ81JJESYXu CDPjeqAuj7ylfN7DwTIiCFK58GC0xhU+1InEpubpOQrRNP1gPXd8y/plCNi8VvVERrL3b3D5 OCENbnBk1L3Q2Yknt0QtQRrgGT1IrTK0BCMG1D3vMfk0wn2+I+NTBpto1EUYoZg/Xy4iPxtb 3U8kwncAAAAAAAA= --------------ms040500090500080009090607-- From muenz@net.in.tum.de Tue Feb 24 01:51:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335B93A6A84 for ; Tue, 24 Feb 2009 01:51:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPqxpZqL+ub4 for ; Tue, 24 Feb 2009 01:51:12 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id AF6BE3A67FD for ; Tue, 24 Feb 2009 01:51:11 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 2736B483A4; Tue, 24 Feb 2009 10:51:29 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0EDF54FB4; Tue, 24 Feb 2009 10:51:29 +0100 (CET) Message-ID: <49A3C322.4030000@net.in.tum.de> Date: Tue, 24 Feb 2009 10:51:30 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Aitken References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> In-Reply-To: <49A31B3C.8070004@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080602030008080509030701" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 09:51:17 -0000 This is a cryptographically signed message in MIME format. --------------ms080602030008080509030701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, Paul Aitken wrote: >> After long discussions with Paul, I was convinced that configuring the= >> metering process through the template is putting the cart before the >> horse. >=20 > A support question I received some years ago asked how to reconfigure > our NFv9 templates - because they thought this would change what was > being monitored. It wouldn't; that's never been our model. Export has > always followed from monitoring and not the other way around. >=20 >> However, I also think that the configuration of a fixed set of fields >> per record (as in Maji and Vermont) has its merits because it easy to >> implement. >> >> If there is support from your side (and maybe others), we can extend t= he >> configuration model such that the configuration of such IPFIX >> implementations is supported as well. >=20 > The existing IPFIX-CONFIG design already allows for this, if you > consider that the cache is being configured (rather than the exporter, > as in Maji and Vermont) and that the exporter matches with it 1:1. In fact, it is not possible to describe a configuration that results in a 1:1 mapping of Cache Layout and Template with the existing IPFIX-CONFIG= =2E The current rules guarantee that a Cache accounts every incoming packet in a single Flow Record. At the end, this may result in Flow Records with different combination of fields defined in the Cache Layout. For each of these combinations, the Exporting Process will define a different Template. The "Cache" of Maji and Vermont only accounts packets that contain a certain set of fields. As a result, it generates Flow Records with one fixed combination of fields. To achieve this, it implicitly filters out packets that miss any of these fields specified in the Cache Layout. With the current configuration model, it is not possible to configure such a filter mechansim that only accepts packets from which certain fields can be extracted. To solve this, we could add a parameter that specifies how packets with missing fields are treated by the Cache, with settings such as "accept" and "ignore". I'm open to better solutions :) Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms080602030008080509030701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MDk1MTMwWjAjBgkqhkiG9w0BCQQxFgQU T0pAIWdGXuB/pfLoYmvZm3Scud0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJc7R5L4ECVaAflUaL44xW6pFIR64I8rEeLrbn7pjBcDO4VZ 2QEVW4aVHHvYIa8ihtsHUXVf1RGZQJ4HdntDOeSL6qDd1mmkQmFgdSyWfFK2FJU2H4oIhbZl OpDCEOqA7TtoKQnshWvdiyDuISqvXfzIFLxK9NktfcRpxH00OhKo2WBY39d5+xfHrNJ7pA91 eIReJwPmvGUeJSQW2ZS5ho306g8nrblAlPaBN6pQGeb0u5Rl1rXWVhdMJZoCkHn+k3TKqofh sZ6ubv7ALRtxItzEESqA834p72BQcV0RTPDcikVZA8Z/TyH33p/1GXWQiaIoREWa8Tf5nCj/ 3kmrtpIAAAAAAAA= --------------ms080602030008080509030701-- From paitken@cisco.com Tue Feb 24 03:19:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056DF28C134 for ; Tue, 24 Feb 2009 03:19:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGUzdYgbUqFC for ; Tue, 24 Feb 2009 03:19:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B39523A67D1 for ; Tue, 24 Feb 2009 03:19:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,258,1233532800"; d="scan'208";a="34654464" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 11:19:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1OBJRFP019214; Tue, 24 Feb 2009 12:19:27 +0100 Received: from [10.61.108.129] (dhcp-10-61-108-129.cisco.com [10.61.108.129]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OBJRc8003881; Tue, 24 Feb 2009 11:19:27 GMT Message-ID: <49A3D7BE.5070709@cisco.com> Date: Tue, 24 Feb 2009 11:19:26 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> In-Reply-To: <49A3C322.4030000@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2042; t=1235474367; x=1236338367; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Maji=20-=20an=20open=20=20sou rce=20IPFIX=20meter=20implementation |Sender:=20; bh=jvyh4YsdXz3fA3PSUo+sS8bWf+bd3MuW3PSXqukk/jE=; b=KdEh7hBtzZlxJ/GuYqHq+tnP2W+zBfNCh8fcmtS34t8J1V0ZO2htv6lHEz HobPaKJmsE+mLNv44iUI8bgZAEIK3dfH9P4g9ubuEQ29R4ITCdyF7e/XVEmR SzM3YCf7rH; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 11:19:11 -0000 Gerhard, > In fact, it is not possible to describe a configuration that results in > a 1:1 mapping of Cache Layout and Template with the existing IPFIX-CONFIG. I'm surprised. I must re-review the draft. > The current rules guarantee that a Cache accounts every incoming packet > in a single Flow Record. At the end, this may result in Flow Records > with different combination of fields defined in the Cache Layout. Because some fields could not be observed. > For each of these combinations, the Exporting Process will define a > different Template. For simplicity - and especially when a large number of fields might lead to a combinatorial explosion in the number of templates - it'd be good if we could export a single template describing all the fields in the cache, and either set the unobserved fields to an out-of-band value or export a bitfield indicating which particular fields had been observed. > The "Cache" of Maji and Vermont only accounts packets that contain a > certain set of fields. As a result, it generates Flow Records with one > fixed combination of fields. To achieve this, it implicitly filters out > packets that miss any of these fields specified in the Cache Layout. > With the current configuration model, it is not possible to configure > such a filter mechansim that only accepts packets from which certain > fields can be extracted. > > To solve this, we could add a parameter that specifies how packets with > missing fields are treated by the Cache, with settings such as "accept" > and "ignore". This reminds me of an ACL. It seems to be an important and necessary filter, complimentary to the existing filters. eg, if you only want to account TCP traffic, or only IPv6, or only traffic with a specific IPv4 option or IPv6 extension header. Or again, if you specifically want to rule out certain subsets of traffic. P. > I'm open to better solutions :) > > Gerhard > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From muenz@net.in.tum.de Tue Feb 24 04:13:37 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09C628C124 for ; Tue, 24 Feb 2009 04:13:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDcYNCEnd1H6 for ; Tue, 24 Feb 2009 04:13:36 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 566CA3A67A4 for ; Tue, 24 Feb 2009 04:13:36 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 7CBCC483AF; Tue, 24 Feb 2009 13:13:42 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 6720C4FB4; Tue, 24 Feb 2009 13:13:42 +0100 (CET) Message-ID: <49A3E478.2000303@net.in.tum.de> Date: Tue, 24 Feb 2009 13:13:44 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Aitken References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3D7BE.5070709@cisco.com> In-Reply-To: <49A3D7BE.5070709@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040000020104090404000409" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:13:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040000020104090404000409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, >> The current rules guarantee that a Cache accounts every incoming packe= t >> in a single Flow Record. At the end, this may result in Flow Records >> with different combination of fields defined in the Cache Layout. >=20 > Because some fields could not be observed. >=20 >> For each of these combinations, the Exporting Process will define a >> different Template. >=20 > For simplicity - and especially when a large number of fields might lea= d > to a combinatorial explosion in the number of templates - it'd be good > if we could export a single template describing all the fields in the > cache, and either set the unobserved fields to an out-of-band value or > export a bitfield indicating which particular fields had been observed.= Out-of-band values do not exist for many Information Elements. And if they exist, IPFIX currently does not specify how to interpret them. The bitfield seems to be a feasible solution that can be easily standardized. However, we first need a consensus in the WG that invalid field values in a Record are generally acceptable. >> The "Cache" of Maji and Vermont only accounts packets that contain a >> certain set of fields. As a result, it generates Flow Records with one= >> fixed combination of fields. To achieve this, it implicitly filters ou= t >> packets that miss any of these fields specified in the Cache Layout. >> With the current configuration model, it is not possible to configure >> such a filter mechansim that only accepts packets from which certain >> fields can be extracted. >> >> To solve this, we could add a parameter that specifies how packets wit= h >> missing fields are treated by the Cache, with settings such as "accept= " >> and "ignore". >=20 > This reminds me of an ACL. It seems to be an important and necessary > filter, complimentary to the existing filters. eg, if you only want to > account TCP traffic, or only IPv6, or only traffic with a specific IPv4= > option or IPv6 extension header. Or again, if you specifically want to > rule out certain subsets of traffic. You are right, the filter could be a new type of Selector that is implemented in front of the cache: +----+ +-------+ packets --->| SP |--->| Cache |---> records +----+ +-------+ In this case, the SP must be configured with the same fields as the Cache= ! A shortcut would be the additional parameter that I mentioned before: +-----------------------------------------+ packets --->| Cache |---> records | ignorePacketsWithMissingFields =3D "true" | +-----------------------------------------+ (I havn't found a better parameter name, yet.) Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040000020104090404000409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MTIxMzQ0WjAjBgkqhkiG9w0BCQQxFgQU OicTYUk3sYEEnS9cOPITsyZU2HAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABY8YOP+laLdiVvNH/9w8WPJycF0veE3AHGMjZrXS6GIfmTX O7HBy+yPhlw2qm5IQBys7vDfpI7oXO1ZP3DWFlFL5NhyOXF3NK5IRtJWM7K6Ben5PXyk6Urg FRifxp+3zWQMqb6Uw9wJbk6YXv+PCIJo6WXDCDRL6kI/8QaFZOFSYYd3fIEb6n9280f3hAw9 nu0pAPP0RIbzVFTl4Mt6Zl15hhvIh9ve0FLddRXjQ0RKkboZ3qeVsTMc2prjfUdhfr6tSQQ9 5ElUoWgxCUyClb6pl/O0n3eOeXSMjsGZL7VDjH4J9nMV1hF7cW3Gd28pnognogEkBE9WY1Z2 Jcmm2bIAAAAAAAA= --------------ms040000020104090404000409-- From paitken@cisco.com Tue Feb 24 04:54:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD423A687E for ; Tue, 24 Feb 2009 04:54:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs1SEBNBMneT for ; Tue, 24 Feb 2009 04:54:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8141A3A6837 for ; Tue, 24 Feb 2009 04:54:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="34667675" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 12:54:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1OCslA7019793; Tue, 24 Feb 2009 13:54:47 +0100 Received: from [10.61.108.129] (dhcp-10-61-108-129.cisco.com [10.61.108.129]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OCslNI010105; Tue, 24 Feb 2009 12:54:47 GMT Message-ID: <49A3EE16.6070803@cisco.com> Date: Tue, 24 Feb 2009 12:54:46 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3D7BE.5070709@cisco.com> <49A3E478.2000303@net.in.tum.de> In-Reply-To: <49A3E478.2000303@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3287; t=1235480087; x=1236344087; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Maji=20-=20an=20open=20=20sou rce=20IPFIX=20meter=20implementation |Sender:=20; bh=A6e5ANgO9lRTTLVchEWQ5IWMhZdIAX2zqhw13ZKw6ZA=; b=vtDWKofsuKK5Nhw3EPJ9bqNme2gRSH4OtkYqRGOZpQUnlr5gUTBXzl4cyE Cvf/lL2amx8gPAxP6pGbCAQ6sERWDXWq3wRarLfOo+feboXOoZ2O4PKXKKVg gWrcOm2k/S; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:54:35 -0000 Gerhard, >> For simplicity - and especially when a large number of fields might lead >> to a combinatorial explosion in the number of templates - it'd be good >> if we could export a single template describing all the fields in the >> cache, and either set the unobserved fields to an out-of-band value or >> export a bitfield indicating which particular fields had been observed. > > Out-of-band values do not exist for many Information Elements. And if > they exist, IPFIX currently does not specify how to interpret them. Exactly. > The bitfield seems to be a feasible solution that can be easily > standardized. Good, we agree. I'm thinking of something similar to the flowKeyIndicator. > However, we first need a consensus in the WG that invalid field values > in a Record are generally acceptable. Sure. There are advantages in several situations: 1) where the exporting or collecting process/device is too simple (lack of memory, CPU, time etc) to be able to make/store/decode all the necessary templates. 2) where an excessive combination of fields might make the number of templates unmanageable. >>> The "Cache" of Maji and Vermont only accounts packets that contain a >>> certain set of fields. As a result, it generates Flow Records with one >>> fixed combination of fields. To achieve this, it implicitly filters out >>> packets that miss any of these fields specified in the Cache Layout. >>> With the current configuration model, it is not possible to configure >>> such a filter mechansim that only accepts packets from which certain >>> fields can be extracted. >>> >>> To solve this, we could add a parameter that specifies how packets with >>> missing fields are treated by the Cache, with settings such as "accept" >>> and "ignore". >> This reminds me of an ACL. It seems to be an important and necessary >> filter, complimentary to the existing filters. eg, if you only want to >> account TCP traffic, or only IPv6, or only traffic with a specific IPv4 >> option or IPv6 extension header. Or again, if you specifically want to >> rule out certain subsets of traffic. > > You are right, the filter could be a new type of Selector that is > implemented in front of the cache: > > +----+ +-------+ > packets --->| SP |--->| Cache |---> records > +----+ +-------+ > > In this case, the SP must be configured with the same fields as the Cache! Yes. However, an implementation of the configuration model could easily take care of that - perhaps even implementing it as you show below. > A shortcut would be the additional parameter that I mentioned before: > > +-----------------------------------------+ > packets --->| Cache |---> records > | ignorePacketsWithMissingFields = "true" | > +-----------------------------------------+ This allows modeling of "ignore non-TCP traffic" (ie, "monitor only TCP traffic") by putting TCP specific fields in the cache. However, it doesn't allow the opposite, ie "monitor non-TCP traffic" - so it's not quite as flexible as having a pre-filtering SP. Cheers, P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From andrjohn@cisco.com Tue Feb 24 05:10:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A06C3A67D0 for ; Tue, 24 Feb 2009 05:10:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81MTh0UFU+VM for ; Tue, 24 Feb 2009 05:10:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E60C73A67A4 for ; Tue, 24 Feb 2009 05:10:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="34669879" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 13:10:32 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1ODAW9x025271; Tue, 24 Feb 2009 14:10:32 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1ODAVpZ016123; Tue, 24 Feb 2009 13:10:31 GMT Received: from [10.55.163.41] (ams-andrjohn-8718.cisco.com [10.55.163.41]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n1ODAUF18916; Tue, 24 Feb 2009 13:10:30 GMT Message-ID: <49A3F1CA.80801@cisco.com> Date: Tue, 24 Feb 2009 13:10:34 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> In-Reply-To: <49A3C322.4030000@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1141; t=1235481032; x=1236345032; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20[Sender=3A=20ipfix-bounces@ie tf.org]=20Re=3A=20Maji=20-=20an=20open=20source=0A=20IPFIX=2 0meter=20implementation |Sender:=20; bh=q9p0rOB8kRXWFnRMBEO9rlwJlHy2nB6H8LLMkI+hrz4=; b=FBjRhtg6wJqmU1u8kvlQCMA3HUyfDHODMYpBoskyw5co3swP6xu5WxcwMf C8DV7gGn9hnKoSv8rE1xxkplIDSz1I0wWr7NQlBMnLhnhQGTY9scYtEKI3hQ wUTjBVVSFk; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:10:16 -0000 Hi Gerhard Gerhard Muenz wrote: [SNIP] > The "Cache" of Maji and Vermont only accounts packets that contain a > certain set of fields. As a result, it generates Flow Records with one > fixed combination of fields. To achieve this, it implicitly filters out > packets that miss any of these fields specified in the Cache Layout. > With the current configuration model, it is not possible to configure > such a filter mechansim that only accepts packets from which certain > fields can be extracted. > > To solve this, we could add a parameter that specifies how packets with > missing fields are treated by the Cache, with settings such as "accept" > and "ignore". > > I'm open to better solutions :) It seems to me that explicitly configuring the filter would be more helpful. In [PSAMP-PROTO], section 6.5.2 there are details on how to export the config of various types of filtering and sampling mechanisms. Specifically 6.5.2.5 details how filters are configured. This could be used as the basis for an extension to ipfix-configuration that would specify how to configure filtering. Cheers Andrew From trammell@tik.ee.ethz.ch Tue Feb 24 05:24:15 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09ED23A691D for ; Tue, 24 Feb 2009 05:24:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yarQt+tWVAH9 for ; Tue, 24 Feb 2009 05:24:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 19BAF3A68D0 for ; Tue, 24 Feb 2009 05:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6E0B8D9376; Tue, 24 Feb 2009 14:24: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 DdUV1xpF3DPc; Tue, 24 Feb 2009 14:24:31 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 03FB4D9373; Tue, 24 Feb 2009 14:24:31 +0100 (MET) Message-Id: From: Brian Trammell To: Andrew Johnson In-Reply-To: <49A3F1CA.80801@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 14:24:30 +0100 References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:24:15 -0000 Hi Andrew, all, I'd tend to agree with Andrew on this point; specifying implicit filtering through template specification seems to be a _very_ implementation-specific sort of thing, which should to the extent possible be avoided in the configuration draft. Cheers, Brian On Feb 24, 2009, at 2:10 PM, Andrew Johnson wrote: > Hi Gerhard > > Gerhard Muenz wrote: > [SNIP] >> The "Cache" of Maji and Vermont only accounts packets that contain a >> certain set of fields. As a result, it generates Flow Records with >> one >> fixed combination of fields. To achieve this, it implicitly filters >> out >> packets that miss any of these fields specified in the Cache Layout. >> With the current configuration model, it is not possible to configure >> such a filter mechansim that only accepts packets from which certain >> fields can be extracted. >> To solve this, we could add a parameter that specifies how packets >> with >> missing fields are treated by the Cache, with settings such as >> "accept" >> and "ignore". >> I'm open to better solutions :) > > It seems to me that explicitly configuring the filter would be more > helpful. > > In [PSAMP-PROTO], section 6.5.2 there are details on how to export > the config of various types of filtering and sampling mechanisms. > Specifically 6.5.2.5 details how filters are configured. This could > be used as the basis for an extension to ipfix-configuration that > would specify how to configure filtering. > > Cheers > > Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Tue Feb 24 05:36:44 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBB53A6839 for ; Tue, 24 Feb 2009 05:36:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj0V2pMuqdAT for ; Tue, 24 Feb 2009 05:36:43 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id BEB523A67D4 for ; Tue, 24 Feb 2009 05:36:42 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 23CFB483A4; Tue, 24 Feb 2009 14:37:00 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 1038A2BB3; Tue, 24 Feb 2009 14:37:00 +0100 (CET) Message-ID: <49A3F7FD.7080902@net.in.tum.de> Date: Tue, 24 Feb 2009 14:37:01 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030303000408090301010100" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:36:44 -0000 This is a cryptographically signed message in MIME format. --------------ms030303000408090301010100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, all, I understand what you mean, yet you use the wrong terminology ;) Templates are currently not configured, and we do not plan to do so. What we do configure is the Cache, which requires that we have a common understand how a Cache functions. Andrew is completely right that we need to report any kind of filtering (whether implicit or explicit) to the Collector. This should be done in the PSAMP way. I agree with both of you that modeling the filter explicitly is more consistent with the current separation of packet selection and flow generation functions. So, what is the right way to standardize a new Selector? Is the configuration draft the right place to do this? Same question for the bitfield Information Element Paul suggested? Cheers, Gerhard Brian Trammell wrote: > Hi Andrew, all, >=20 > I'd tend to agree with Andrew on this point; specifying implicit > filtering through template specification seems to be a _very_ > implementation-specific sort of thing, which should to the extent > possible be avoided in the configuration draft. >=20 > Cheers, >=20 > Brian >=20 > On Feb 24, 2009, at 2:10 PM, Andrew Johnson wrote: >=20 >> Hi Gerhard >> >> Gerhard Muenz wrote: >> [SNIP] >>> The "Cache" of Maji and Vermont only accounts packets that contain a >>> certain set of fields. As a result, it generates Flow Records with on= e >>> fixed combination of fields. To achieve this, it implicitly filters o= ut >>> packets that miss any of these fields specified in the Cache Layout. >>> With the current configuration model, it is not possible to configure= >>> such a filter mechansim that only accepts packets from which certain >>> fields can be extracted. >>> To solve this, we could add a parameter that specifies how packets wi= th >>> missing fields are treated by the Cache, with settings such as "accep= t" >>> and "ignore". >>> I'm open to better solutions :) >> >> It seems to me that explicitly configuring the filter would be more >> helpful. >> >> In [PSAMP-PROTO], section 6.5.2 there are details on how to export the= >> config of various types of filtering and sampling mechanisms. >> Specifically 6.5.2.5 details how filters are configured. This could >> be used as the basis for an extension to ipfix-configuration that >> would specify how to configure filtering. >> >> Cheers >> >> Andrew >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms030303000408090301010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MTMzNzAxWjAjBgkqhkiG9w0BCQQxFgQU 4TEfUnfTzgDcluMvoc64AwyAXRgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIUdDgi5617WcLedvH4KCjC5osVT5DFP1OdnDEczioesmDgK 7gTSj9H3OTlMEooyDWB/M2pdscO4Klf3OxxD4OpGFaQgLOo2YRrAyJ+K4mQ01qewHbakM9K8 xVWb+aPIubWjfPYBGiR9A9gnG6HpS7SbQ9wGWwNV0vUAxqSq1eOdRgn/dPKqNtG/BG/imD4k hKm71Vz88gTGA9QVFci3dH8L+Fl+iHAXpaK/MNKXsL7JHPQBIi1XjOfCzeCkW2hqjP8Z7fP8 dsSz2oHMrmge36FjDk5skoAAhKbPQ1cNYZbXaqZhBeRCwz3VP9r5yG0UQkKH78MIIB+LxTey OAS8wLUAAAAAAAA= --------------ms030303000408090301010100-- From andrjohn@cisco.com Tue Feb 24 05:47:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831C73A68A6 for ; Tue, 24 Feb 2009 05:47:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2Tt24vxL8Li for ; Tue, 24 Feb 2009 05:47:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1F3183A67A2 for ; Tue, 24 Feb 2009 05:47:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="34675004" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 13:48:07 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1ODm7JF005664; Tue, 24 Feb 2009 14:48:07 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1ODm6TW029717; Tue, 24 Feb 2009 13:48:07 GMT Received: from [10.55.163.41] (ams-andrjohn-8718.cisco.com [10.55.163.41]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n1ODm4F22142; Tue, 24 Feb 2009 13:48:05 GMT Message-ID: <49A3FA98.6060403@cisco.com> Date: Tue, 24 Feb 2009 13:48:08 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> In-Reply-To: <49A3F7FD.7080902@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3191; t=1235483287; x=1236347287; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20[Sender=3A=20ipfix-bounces@ie tf.org]=20Re=3A=20Maji=20-=20an=20open=20source=0A=20IPFIX=2 0meter=20implementation |Sender:=20; bh=hABpJNPBuGoujVC227wTKMT2sAB0U3XTl7wlYlv9pd0=; b=BhImT7Ahg2T+T0mvFSQ0Nv8EXcrWywS2f+6Q5MyvMX8WtXv105JcUDEp5d 8TpBUdZ1qrQaUSuZRynBF0TbegFe0R9zLOGZnS2+mC74MRvP3qZwZ6ne+juw 8+jmrMHqhd; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:47:50 -0000 Hi Gerhard You can register a new bitfield with IANA without it being a part of any draft. You can then reference it from your draft. Why do you want a new Selector? Can you not use the Selector that is defined in [PSAMP-PROTO]? I had hoped that the configuration model would be extended to include the PSAMP configuration. I thought that would most likely be done with a new draft that built upon your current one, but perhaps you could see if there are elements that are worth bringing in today. Cheers Andrew Gerhard Muenz wrote: > Brian, all, > > I understand what you mean, yet you use the wrong terminology ;) > > Templates are currently not configured, and we do not plan to do so. > > What we do configure is the Cache, which requires that we have a common > understand how a Cache functions. > > Andrew is completely right that we need to report any kind of filtering > (whether implicit or explicit) to the Collector. This should be done in > the PSAMP way. > > I agree with both of you that modeling the filter explicitly is more > consistent with the current separation of packet selection and flow > generation functions. > > So, what is the right way to standardize a new Selector? > Is the configuration draft the right place to do this? > Same question for the bitfield Information Element Paul suggested? > > Cheers, > Gerhard > > > Brian Trammell wrote: >> Hi Andrew, all, >> >> I'd tend to agree with Andrew on this point; specifying implicit >> filtering through template specification seems to be a _very_ >> implementation-specific sort of thing, which should to the extent >> possible be avoided in the configuration draft. >> >> Cheers, >> >> Brian >> >> On Feb 24, 2009, at 2:10 PM, Andrew Johnson wrote: >> >>> Hi Gerhard >>> >>> Gerhard Muenz wrote: >>> [SNIP] >>>> The "Cache" of Maji and Vermont only accounts packets that contain a >>>> certain set of fields. As a result, it generates Flow Records with one >>>> fixed combination of fields. To achieve this, it implicitly filters out >>>> packets that miss any of these fields specified in the Cache Layout. >>>> With the current configuration model, it is not possible to configure >>>> such a filter mechansim that only accepts packets from which certain >>>> fields can be extracted. >>>> To solve this, we could add a parameter that specifies how packets with >>>> missing fields are treated by the Cache, with settings such as "accept" >>>> and "ignore". >>>> I'm open to better solutions :) >>> It seems to me that explicitly configuring the filter would be more >>> helpful. >>> >>> In [PSAMP-PROTO], section 6.5.2 there are details on how to export the >>> config of various types of filtering and sampling mechanisms. >>> Specifically 6.5.2.5 details how filters are configured. This could >>> be used as the basis for an extension to ipfix-configuration that >>> would specify how to configure filtering. >>> >>> Cheers >>> >>> Andrew >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > From muenz@net.in.tum.de Tue Feb 24 06:01:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1043A69BB for ; Tue, 24 Feb 2009 06:01:51 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV9MTgXbNm8e for ; Tue, 24 Feb 2009 06:01:50 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 610BB3A6966 for ; Tue, 24 Feb 2009 06:01:50 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 360A9483A4; Tue, 24 Feb 2009 15:02:08 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 19302280E; Tue, 24 Feb 2009 15:02:08 +0100 (CET) Message-ID: <49A3FDE1.6040405@net.in.tum.de> Date: Tue, 24 Feb 2009 15:02:09 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andrew Johnson References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> In-Reply-To: <49A3FA98.6060403@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070900040104080804080506" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:01:51 -0000 This is a cryptographically signed message in MIME format. --------------ms070900040104080804080506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, > Why do you want a new Selector? Can you not use the Selector that is > defined in [PSAMP-PROTO]? PSAMP specifies "property match filtering", but that is not what we want to do. Or do you know how to deploy this filter for our purpose? > I had hoped that the configuration model would be extended to include > the PSAMP configuration. =20 It already does. The configuration of those Selectors that are specified in the PSAMP documents has been included since the beginning. Cheers, Gerhard > I thought that would most likely be done with > a new draft that built upon your current one, but perhaps you could see= > if there are elements that are worth bringing in today. >=20 > Cheers >=20 > Andrew --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070900040104080804080506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MTQwMjA5WjAjBgkqhkiG9w0BCQQxFgQU 20iO3foezzUUjrGoBQ0PdrFCGpAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADGeqcCOADi8UwuBMcQJEer1vlQn5fuKRvRXGOQ0TvZf63JR QRUTMdtL4sVevAJJFf5g2nM6g4otL3II9t1Wc7mMwt6+IsUkK8G/G4Gf9nMFygmr7YyAq+SV yMww3Eptdz8Y9xPyg2r3Cc4ivIwUWu81S8QAuXBOw+LJlEXN6EB5TXKm5Jyibpfsbj7sB2JQ UBkz+ZZA23JtiF1chjKLDONAiOQUz215wxduLoEmeSpmIe7t4b3NpkuXLV4eFPu9g8FmQuPJ loIstPJI+vXNY+J/7ygGQUMaXwMmapvQb+11cc+r1OGtI0EbdcyyRG3SbooS5t7ezaGL/cca /moA4IgAAAAAAAA= --------------ms070900040104080804080506-- From andrjohn@cisco.com Tue Feb 24 06:48:04 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAC93A6A3C for ; Tue, 24 Feb 2009 06:48: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SGLpbpCRqAo for ; Tue, 24 Feb 2009 06:48:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C29CC3A6A4B for ; Tue, 24 Feb 2009 06:48:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="34684149" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 14:48:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1OEmKJl027783; Tue, 24 Feb 2009 15:48:20 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OEmKaJ023890; Tue, 24 Feb 2009 14:48:20 GMT Received: from [10.55.163.41] (ams-andrjohn-8718.cisco.com [10.55.163.41]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n1OEm9F27883; Tue, 24 Feb 2009 14:48:09 GMT Message-ID: <49A408AD.7080201@cisco.com> Date: Tue, 24 Feb 2009 14:48:13 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> In-Reply-To: <49A3FDE1.6040405@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1777; t=1235486900; x=1236350900; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20[Sender=3A=20ipfix-bounces@ie tf.org]=20Re=3A=20Maji=20-=20an=20open=20source=0A=20IPFIX=2 0meter=20implementation |Sender:=20; bh=mRGnf0K7yzDvBeC3RiCSAPNu918nZZ+9yVFa4go0fmQ=; b=iygnAIDQTNJnQJMt/KC0X8rYlf1lz0ZCACHqLNmf28KmDa1FGnTsJwHc+P cgPup/UINz7eXdmxZhWIW2PjgrOeFPFF+O8DBUYGf4pLIFkUFJLfTU3coefk XLP/+JCJFJ; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:48:04 -0000 Gerhard Muenz wrote: > Hi Andrew, > >> Why do you want a new Selector? Can you not use the Selector that is >> defined in [PSAMP-PROTO]? > > PSAMP specifies "property match filtering", but that is not what we want > to do. Or do you know how to deploy this filter for our purpose? Well, I'm not sure yet that it'll cover all fields, but it seems that it you can do a lot with it. For example, if you have TCP flags in your cache you could filter on the IP protocol matching TCP. Looking again, you seem to have have a start, stop and mask value for each filter. So what would you expect the behaviour to be of a filter that demands a TCP flags value of 0 when faced with a UDP packet? My instinct is that it should reject the UDP packet because it cannot provide a TCP flags value of 0. An alternate filter could be set up to accept UDP packets. If we agree on that point, then how about a TCP flags filter that filtered on TCP flags being in the range 0x00 to 0xFF. It would accept all values for the TCP flags field, but reject packets that didn't have the field. >> I had hoped that the configuration model would be extended to include >> the PSAMP configuration. > > It already does. The configuration of those Selectors that are specified > in the PSAMP documents has been included since the beginning. Great. I remembered some parts of it were in, and our discussions on selector chaining, but had forgotten how much your draft covers. Cheers Andrew > Cheers, > Gerhard > >> I thought that would most likely be done with >> a new draft that built upon your current one, but perhaps you could see >> if there are elements that are worth bringing in today. >> >> Cheers >> >> Andrew > From muenz@net.in.tum.de Tue Feb 24 07:19:21 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F333A6836 for ; Tue, 24 Feb 2009 07:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l50ZAUlQwBva for ; Tue, 24 Feb 2009 07:19:20 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 3F27E3A6805 for ; Tue, 24 Feb 2009 07:19:19 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B6F74483A4; Tue, 24 Feb 2009 16:19:37 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9E305280E; Tue, 24 Feb 2009 16:19:37 +0100 (CET) Message-ID: <49A4100C.3070902@net.in.tum.de> Date: Tue, 24 Feb 2009 16:19:40 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andrew Johnson References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> In-Reply-To: <49A408AD.7080201@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030306040808080304050207" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:19:21 -0000 This is a cryptographically signed message in MIME format. --------------ms030306040808080304050207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, Andrew Johnson wrote: > Gerhard Muenz wrote: >>> Why do you want a new Selector? Can you not use the Selector that is= >>> defined in [PSAMP-PROTO]? >> >> PSAMP specifies "property match filtering", but that is not what we wa= nt >> to do. Or do you know how to deploy this filter for our purpose? >=20 > Well, I'm not sure yet that it'll cover all fields, but it seems that i= t > you can do a lot with it. For example, if you have TCP flags in your > cache you could filter on the IP protocol matching TCP. Concluding that one field is present because of the value of another field is a work-around that does not work in general. > Looking again, you seem to have have a start, stop and mask value for > each filter. So what would you expect the behaviour to be of a filter > that demands a TCP flags value of 0 when faced with a UDP packet? I do not know. Is it defined somewhere? > My instinct is that it should reject the UDP packet because it cannot > provide a TCP flags value of 0. An alternate filter could be set up to= > accept UDP packets. >=20 > If we agree on that point, then how about a TCP flags filter that > filtered on TCP flags being in the range 0x00 to 0xFF. It would accept= > all values for the TCP flags field, but reject packets that didn't have= > the field. Then, we could place a property match filter in front of the Cache that matches all fields of the Cache Layout with mask=3D0x00 (or start=3D0 and= end=3Dinfinity) to ensure that all fields are present. However, I'm a little bit confused about the following paragraph in PSAMP-TECH: 6.1 Property Match Filtering .... A packet is selected if Field=3DValue. Masks and ranges are only supported to the extent to which [RFC5102] allows them e.g. by providing explicit fields like the netmasks for source and destination addresses. Also, PSAMP-PROTOCOL does not allow to export a value range [start, stop] in an Option :( Note that the configuration data model is based in PSAMP-MIB where "start", "stop" and "mask" are mentioned as parameters of property match filtering. It seems that these parameters are outdated? Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms030306040808080304050207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI0MTUxOTQwWjAjBgkqhkiG9w0BCQQxFgQU NfJhwUYE/Ia61birCiLaQCdsESUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALZbVVKXy/GjlXfVeWoHhm9ScoSNAkkc2tvLmPDR6eGScH6o x0UkfB98vjWto8U7Xwvb07OeKiwEQzPTqYAGP8+24QGjU0OpcCAQPMq26Zm2fGjjB9b88HE0 a/tdKw0ugw7bOx0W6bF93Um6h4XqN7fJMF7og3SjBfRyWys4XbGf85qrBtMrZiHouVxpuvtE 2XcnuaTgpFXvz58fmjx0T0b853NIn2MPSJhNQ2YTS0+OF8qtkx6VFydcQC5DG+xLjwjvNGoy Jx/f+mkc90fO183XbZCXsOOZLDPh139ERHqY3YlW8t8Ldh1FKG2gDB704ichqWF3EK/2A9O2 uYW9X80AAAAAAAA= --------------ms030306040808080304050207-- From andrjohn@cisco.com Tue Feb 24 07:45:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA5D3A690F for ; Tue, 24 Feb 2009 07:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fajzhz1K+74h for ; Tue, 24 Feb 2009 07:45:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4EFC63A689F for ; Tue, 24 Feb 2009 07:45:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="34692105" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2009 15:45:49 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1OFjnFn015049; Tue, 24 Feb 2009 16:45:49 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OFjnqF015328; Tue, 24 Feb 2009 15:45:49 GMT Received: from [10.55.163.41] (ams-andrjohn-8718.cisco.com [10.55.163.41]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n1OFjmF04718; Tue, 24 Feb 2009 15:45:48 GMT Message-ID: <49A41630.4030208@cisco.com> Date: Tue, 24 Feb 2009 15:45:52 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> <49A4100C.3070902@net.in.tum.de> In-Reply-To: <49A4100C.3070902@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2950; t=1235490349; x=1236354349; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20[Sender=3A=20ipfix-bounces@ie tf.org]=20Re=3A=20Maji=20-=20an=20open=20source=0A=20IPFIX=2 0meter=20implementation |Sender:=20; bh=gAyoNegyEHZv56qli21uNEXdwDSMzOwQ+scV+VRmCyg=; b=pBO7qhtSR5HYBNqsPTBA5m8bjIgjsnTfW7cbSP+9h7qS+zLw87BCSfrIMx q3Zb+fqlhg+IxyV5ENcDrqpeGddp6qdB0p8Z39rC6DM8/RP6s//zPG9+tGMn 8Xey5TEySe; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:45:32 -0000 Hi Gerhard Gerhard Muenz wrote: > Hi Andrew, > > Andrew Johnson wrote: >> Gerhard Muenz wrote: >>>> Why do you want a new Selector? Can you not use the Selector that is >>>> defined in [PSAMP-PROTO]? >>> PSAMP specifies "property match filtering", but that is not what we want >>> to do. Or do you know how to deploy this filter for our purpose? >> Well, I'm not sure yet that it'll cover all fields, but it seems that it >> you can do a lot with it. For example, if you have TCP flags in your >> cache you could filter on the IP protocol matching TCP. > > Concluding that one field is present because of the value of another > field is a work-around that does not work in general. I agree, it's only useful for fields taken from the packet. >> Looking again, you seem to have have a start, stop and mask value for >> each filter. So what would you expect the behaviour to be of a filter >> that demands a TCP flags value of 0 when faced with a UDP packet? > > I do not know. Is it defined somewhere? Not as far as I know, however if you're matching on and IPv4 address of 192.168.0.1, I would not expect all IPv6 traffic to pass the filter. >> My instinct is that it should reject the UDP packet because it cannot >> provide a TCP flags value of 0. An alternate filter could be set up to >> accept UDP packets. >> >> If we agree on that point, then how about a TCP flags filter that >> filtered on TCP flags being in the range 0x00 to 0xFF. It would accept >> all values for the TCP flags field, but reject packets that didn't have >> the field. > > Then, we could place a property match filter in front of the Cache that > matches all fields of the Cache Layout with mask=0x00 (or start=0 and > end=infinity) to ensure that all fields are present. Exactly. > However, I'm a little bit confused about the following paragraph in > PSAMP-TECH: > > 6.1 Property Match Filtering > > .... > > A packet is selected if Field=Value. Masks and ranges are only > supported to the extent to which [RFC5102] allows them e.g. by > providing explicit fields like the netmasks for source and > destination addresses. > > Also, PSAMP-PROTOCOL does not allow to export a value range [start, > stop] in an Option :( Yes, I know. It's very difficult to export min/max/mask using IPFIX without defining new Information Elements for each field you want to filter on. > Note that the configuration data model is based in PSAMP-MIB where > "start", "stop" and "mask" are mentioned as parameters of property match > filtering. It seems that these parameters are outdated? When we added the Filtering Interpretation Report in version 02 we didn't have min/max/mask either. There's just no easy way to export this sort of think in IPFIX without defining three additional I.E.s per field. Unless anyone can think of something? Cheers Andrew From salcock@cs.waikato.ac.nz Tue Feb 24 14:06:19 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CB128C10C for ; Tue, 24 Feb 2009 14:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8-3k-9Lozfr for ; Tue, 24 Feb 2009 14:06:17 -0800 (PST) Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by core3.amsl.com (Postfix) with ESMTP id 515193A66B4 for ; Tue, 24 Feb 2009 14:06:17 -0800 (PST) Received: from voodoo.cs.waikato.ac.nz ([130.217.250.13]) by zombie.scms.waikato.ac.nz with esmtp (Exim 4.69) (envelope-from ) id 1Lc5QB-0001va-9H; Wed, 25 Feb 2009 11:06:35 +1300 Message-ID: <49A46F6A.6000307@cs.waikato.ac.nz> Date: Wed, 25 Feb 2009 11:06:34 +1300 From: Shane Alcock User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A328C6.4040301@cs.waikato.ac.nz> <49A3BE96.3020304@net.in.tum.de> In-Reply-To: <49A3BE96.3020304@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:06:19 -0000 Gerhard, Responses are once again in-line. Gerhard Muenz wrote: > Shane Alcock wrote: > >> Gerhard Muenz wrote: >> >>> Please tell me if the following is correct: >>> It seems that you configure the templates exactly as they will be >>> exported. The definition of the templates implicitly configures the >>> metering process. Packets that contain all fields of a given template >>> are aggregated into a corresponding flow record. On the other hand, if >>> any field of the template is missing, the packet is not accounted. >>> Hence, the configuration of the template implicitly defines a packet >>> filter. >>> >>> >> This is true to an extent. If any field that is part of the flow key for >> a template is missing, then the packet will be essentially ignored. If >> the field is not part of the flow key, a "default" value is provided for >> that field, usually either 0 or MAXINT (depending on whether zero is a >> valid value for the field or not). This is far from an ideal approach, >> as it would be very easy for a collector or analysis program to >> misinterpret the defaults as genuine measurements. >> > > Ok, so you distinguish between missing flow key fields and non-key fields. > > What do you mean by "depending on whether zero is valid or not"? > Do you use zero if it is a valid value? Or is the default value chosen > to be invalid so that the collector can recognize it as such? > > For each information element implemented within maji, I tried to select a default value that was highly unlikely to occur in "reality". For most elements, zero worked very well for this purpose. For example, the ipTTL field is set to zero if there is no valid IP header in the packet. However, zero is a valid ICMP type, so for the icmpTypeIPv4 element, I instead use 255 as the default value for all non-ICMP packets. > Anyway, records are generated that contain fields that contain wrong or > invalid values. Netflow used to do similar things. Often, the collector > can recognize such invalid fields, for example if a TCP flags field > appears in a UDP flow. > > However, I do not think that the export of invalid field values is > conform to the IPFIX standard. If we wanted to do so, we would need to > define which values to be considered as invalid for every Information > Element. This is not done in RFC5102. > As I had read it, the standard did not define what exactly to do in the case where an element could not be determined from the packet (and the configuration draft had not been written at the time). I had the problem that I had to put some value into the flow record to conform to my templates. In the end, I selected what I thought were the best default values for each individual element. The aim was to at least give the collector some hope of recognising the value as invalid or undefined. I don't advocate this as the best solution, nor do I suggest that anyone start formally defining such values in the standard - especially as there will be elements for which all of the possible values are equally valid. But I do think that there needs to be a nice way to indicate that certain fields in a flow record are undefined. Preferably one that isn't reliant on my better judgment! :) > >>> This is a feasible approach. BTW, we did the same in our monitoring >>> probe implementation Vermont. >>> >>> However, in the course of standardizing the IPFIX configuration model, >>> we got to a different solution where we configure packet filters and >>> "cache layouts" of the metering process. The cache layout defines a >>> superset of all fields that are contained in the resulting records if >>> they are available in the incoming packets. Hence, we do not drop a >>> packet or flow if a field is missing. Instead, it is accounted in a >>> record that does not include this field. As a consequence, one cache >>> layout definition may result in multiple templates that have to be >>> generated on demand by the exporting process. >>> >>> The idea is to clearly separate metering and export functions in the >>> configuration model. Also, the configuration of cache layouts instead of >>> templates is closer to Cisco's current version of Flexible Netflow. >>> As a downside, the exporting process must support dynamic template >>> generation, which can be quite complex to implement. >>> >>> >> This would alleviate the problems with the "default" values and an >> implementation of this approach may make it into a subsequent version of >> maji (at least for non-key elements) :) >> > > Ok :) but if restricted to non-key elements, you still implicitly drop > packets that do not have all flow key fields. > > Correct. In the case of maji, the template also defines what a flow is - if I can't extract all the key elements, how can I determine the flow that the packet belongs to? If a packet can't be matched to a flow, I have no real choice but to ignore it. Shane From muenz@net.in.tum.de Wed Feb 25 00:23:43 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EF83A689A for ; Wed, 25 Feb 2009 00:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU0rTXUoCVA8 for ; Wed, 25 Feb 2009 00:23:42 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id BD47D3A6951 for ; Wed, 25 Feb 2009 00:23:41 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B3C114720D; Wed, 25 Feb 2009 09:23:58 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9A4C82807; Wed, 25 Feb 2009 09:23:58 +0100 (CET) Message-ID: <49A50021.3050100@net.in.tum.de> Date: Wed, 25 Feb 2009 09:24:01 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andrew Johnson References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> <49A4100C.3070902@net.in.tum.de> <49A41630.4030208@cisco.com> In-Reply-To: <49A41630.4030208@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108080405050506000107" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:23:43 -0000 This is a cryptographically signed message in MIME format. --------------ms030108080405050506000107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, >>> Looking again, you seem to have have a start, stop and mask value for= >>> each filter. So what would you expect the behaviour to be of a filte= r >>> that demands a TCP flags value of 0 when faced with a UDP packet? >> >> I do not know. Is it defined somewhere? >=20 > Not as far as I know, however if you're matching on and IPv4 address of= > 192.168.0.1, I would not expect all IPv6 traffic to pass the filter. Is it useful to add a note to PSAMP-TECH? >>> My instinct is that it should reject the UDP packet because it cannot= >>> provide a TCP flags value of 0. An alternate filter could be set up = to >>> accept UDP packets. >>> >>> If we agree on that point, then how about a TCP flags filter that >>> filtered on TCP flags being in the range 0x00 to 0xFF. It would acce= pt >>> all values for the TCP flags field, but reject packets that didn't ha= ve >>> the field. >> >> Then, we could place a property match filter in front of the Cache tha= t >> matches all fields of the Cache Layout with mask=3D0x00 (or start=3D0 = and >> end=3Dinfinity) to ensure that all fields are present. >=20 > Exactly. >=20 >=20 >> However, I'm a little bit confused about the following paragraph in >> PSAMP-TECH: >> >> 6.1 Property Match Filtering >> >> .... >> >> A packet is selected if Field=3DValue. Masks and ranges are only >> supported to the extent to which [RFC5102] allows them e.g. by >> providing explicit fields like the netmasks for source and >> destination addresses. >> >> Also, PSAMP-PROTOCOL does not allow to export a value range [start, >> stop] in an Option :( >=20 > Yes, I know. It's very difficult to export min/max/mask using IPFIX > without defining new Information Elements for each field you want to > filter on. Hm, I do not think that defining min/max/mask IEs for every existing IE is needed. I'm sure that a better solution can be found. >> Note that the configuration data model is based in PSAMP-MIB where >> "start", "stop" and "mask" are mentioned as parameters of property mat= ch >> filtering. It seems that these parameters are outdated? >=20 > When we added the Filtering Interpretation Report in version 02 we > didn't have min/max/mask either. There's just no easy way to export > this sort of think in IPFIX without defining three additional I.E.s per= > field. Unless anyone can think of something? Yes: http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01 In my opinion, the current property match filtering specified in PSAMP is too restrictive because it only covers simplistic fiters that are rarely used in practice. Maybe it should be removed from the documents until a better solution is found. Cheers, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms030108080405050506000107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI1MDgyNDAxWjAjBgkqhkiG9w0BCQQxFgQU 61vDJfaNjS08Jhnsa6Nswhq+jRgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIWNcI40ysr8iyF4bNZhZM8EEsE1XDf2jIcGm951tTugWgVe hS2EzBvd6gt9XhcaVJ69hXklsf3s4ordykSn1l5FJBm0H6j1t4wP8ZB0eu2Xo+zlFmdS59RH grlPWo8dSDBNOdmOh36uFNErjyNmx44X9I+d3Hu+CaqZXDTI9liN1kikCXSvdzVr+jKtVxYP i/51+97QXWpDuTcXhp/SEDjbC7O4D9gciaFv6IOBCezFf9yWIRqsK3SURgRHO7gqHsngzGEw oOuFHB5wC6Ov67ODFmnvJ+qJlJMvmLpLLxtwTPK0m2kbTuXbzXUC5AhNrggv6EFQeLcrAoif b1jwwgcAAAAAAAA= --------------ms030108080405050506000107-- From muenz@net.in.tum.de Wed Feb 25 06:11:12 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B3528C0F1 for ; Wed, 25 Feb 2009 06:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcTjZ+r6swBy for ; Wed, 25 Feb 2009 06:11:11 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id F08753A67FD for ; Wed, 25 Feb 2009 06:11:10 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id C197B483D0 for ; Wed, 25 Feb 2009 15:11:29 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id ABA3A288A for ; Wed, 25 Feb 2009 15:11:29 +0100 (CET) Message-ID: <49A55194.1090609@net.in.tum.de> Date: Wed, 25 Feb 2009 15:11:32 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040508000905080403000507" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX-MIB: ipfixMeteringProcessMessages, ipfixMeteringProcessErrors, ipfixMeteringProcessDataRecords X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 14:11:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040508000905080403000507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thomas, Benoit, I do not understand why the following statistics are associated to the Metering Process: ipfixMeteringProcessMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPFIX messages transmitted." ::=3D { ipfixMeteringProcessStatsEntry 3 } ipfixMeteringProcessErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that could not be sent due to e.g. internal buffer overflows or network congestion." ::=3D { ipfixMeteringProcessStatsEntry 4 } The Metering Process does not generate or transmit any IPFIX Messages. Also, IPFIX Messages including Data Records of a specific Metering Process can be sent to different collectors resulting in different Message errors. I think the two counters should be removed. The Transport Session statistics are sufficient. It is interesting to count the Data Records *generated* (not transmitted) by a Metering Process. Therefore, the following DESCRIPTION should be changed: ipfixMeteringProcessDataRecords OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Data Records transmitted." ::=3D { ipfixMeteringProcessStatsEntry 5 } Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040508000905080403000507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI1MTQxMTMyWjAjBgkqhkiG9w0BCQQxFgQU RwuCGdoQtcTiVz1bgBortBUMFFgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABiTOlBgrNYEQF+A1gd0sJceyeD22Q6ndG5o9CtOUh7K89bC 1mDtt/MI3JLmBBQbxiQtD5GCpEdc8gNL0vI0VI+uoAUOtn6lmyVFons3GlTlLtyiTCAeyWgO alRlfVY/leOfTSdBc8fovofnRzguSS7wraBSLxBJMkbnKv7cwuX/QPFLkdEvzkt9dQkgNoLn a2pJfJaQe+SHcrMiiQiHsI/Ibv5CrunNjDTxBHFcUBl666noaTameX/ZGxIAMTin1V1/5Tjr o7HtXMF5Vtb73PKQufdnIV8i7uW5o5bGKD8QFlObKCwuJRVTozqHterONd6OPljSCHK+GyEF WFVFPM0AAAAAAAA= --------------ms040508000905080403000507-- From andrjohn@cisco.com Wed Feb 25 07:06:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6419C3A6A22 for ; Wed, 25 Feb 2009 07:06:11 -0800 (PST) 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=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iLAKMqBOE7t for ; Wed, 25 Feb 2009 07:06:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 623723A68AC for ; Wed, 25 Feb 2009 07:06:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,265,1233532800"; d="scan'208";a="34809184" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2009 15:06:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1PF6Doi023939; Wed, 25 Feb 2009 16:06:13 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1PF6DHk019052; Wed, 25 Feb 2009 15:06:13 GMT Received: from [144.254.153.39] (dhcp-144-254-153-39.cisco.com [144.254.153.39]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n1PF63k10420; Wed, 25 Feb 2009 15:06:03 GMT Message-ID: <49A55E5E.9060609@cisco.com> Date: Wed, 25 Feb 2009 15:06:06 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Gerhard Muenz References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> <49A4100C.3070902@net.in.tum.de> <49A41630.4030208@cisco.com> <49A50021.3050100@net.in.tum.de> In-Reply-To: <49A50021.3050100@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4129; t=1235574373; x=1236438373; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20[Sender=3A=20ipfix-bounces@ie tf.org]=20Re=3A=20Maji=20-=20an=20open=20source=0A=20IPFIX=2 0meter=20implementation |Sender:=20; bh=cWTOPe/4bx9vp6GYjjTe/JKpFh/haecSbGuM7GG+7bk=; b=s/YZ08pxmK12pPL2UQQpz3LCbDtiPkSQIlHnT5VuI+13rYiFuUs6rHMteq gAjQp7S3QOzxQHcQkbYRM1txMBHA+QSrjqLXWPGGPe4qzjSBe6jeolBNkJ1R 1B4nCT/QFz; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:06:11 -0000 Gerhard Muenz wrote: > Hi Andrew, > >>>> Looking again, you seem to have have a start, stop and mask value for >>>> each filter. So what would you expect the behaviour to be of a filter >>>> that demands a TCP flags value of 0 when faced with a UDP packet? >>> I do not know. Is it defined somewhere? >> Not as far as I know, however if you're matching on and IPv4 address of >> 192.168.0.1, I would not expect all IPv6 traffic to pass the filter. > > Is it useful to add a note to PSAMP-TECH? Probably, but maybe too late now. >>>> My instinct is that it should reject the UDP packet because it cannot >>>> provide a TCP flags value of 0. An alternate filter could be set up to >>>> accept UDP packets. >>>> >>>> If we agree on that point, then how about a TCP flags filter that >>>> filtered on TCP flags being in the range 0x00 to 0xFF. It would accept >>>> all values for the TCP flags field, but reject packets that didn't have >>>> the field. >>> Then, we could place a property match filter in front of the Cache that >>> matches all fields of the Cache Layout with mask=0x00 (or start=0 and >>> end=infinity) to ensure that all fields are present. >> Exactly. >> >> >>> However, I'm a little bit confused about the following paragraph in >>> PSAMP-TECH: >>> >>> 6.1 Property Match Filtering >>> >>> .... >>> >>> A packet is selected if Field=Value. Masks and ranges are only >>> supported to the extent to which [RFC5102] allows them e.g. by >>> providing explicit fields like the netmasks for source and >>> destination addresses. >>> >>> Also, PSAMP-PROTOCOL does not allow to export a value range [start, >>> stop] in an Option :( >> Yes, I know. It's very difficult to export min/max/mask using IPFIX >> without defining new Information Elements for each field you want to >> filter on. > > Hm, I do not think that defining min/max/mask IEs for every existing IE > is needed. I'm sure that a better solution can be found. Perhaps, I'd certainly like to think so, but so far I've not seen any real contenders. I can't think of anything that doesn't need data types and/or deviate a lot from how we use IPFIX today. >>> Note that the configuration data model is based in PSAMP-MIB where >>> "start", "stop" and "mask" are mentioned as parameters of property match >>> filtering. It seems that these parameters are outdated? >> When we added the Filtering Interpretation Report in version 02 we >> didn't have min/max/mask either. There's just no easy way to export >> this sort of think in IPFIX without defining three additional I.E.s per >> field. Unless anyone can think of something? > > Yes: > http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01 I don't see how this helps, other than the ability to exclude certain values. I didn't see any indication of how to handle multiple uses of the same I.E., but presumably they follow the same rule as for different I.E.s and are added with an AND operation, and are therefore automatically conflicting. For example, how would you represent a match on the TCP syn flag? With min/max/flags we could have 0x02, 0x02, 0x02. Easy. In the Filtering Interpretation Report you could use multiple inclusion filters / selection paths: OP1, TCP flags = 0x02 OP1, TCP flags = 0x03 OP1, TCP flags = 0x06 OP1, TCP flags = 0x07 ... OP1, TCP flags = 0x1A OP1, TCP flags = 0x1B OP1, TCP flags = 0x1E OP1, TCP flags = 0x1F Yuck. How would this be done with http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01? > In my opinion, the current property match filtering specified in PSAMP > is too restrictive because it only covers simplistic fiters that are > rarely used in practice. Maybe it should be removed from the documents > until a better solution is found. Well, a future draft could extend the filtering mechanisms, but I don't think we should discard what we have today. A new selection type can be added later when we have a way of representing more complex solutions. Cheers Andrew From muenz@net.in.tum.de Thu Feb 26 00:37:44 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54593A69B4 for ; Thu, 26 Feb 2009 00:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhNxb8sk9XGi for ; Thu, 26 Feb 2009 00:37:43 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 8DB453A69A1 for ; Thu, 26 Feb 2009 00:37:42 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9BEA1483D0; Thu, 26 Feb 2009 09:38:01 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 81F5E3CD7; Thu, 26 Feb 2009 09:38:01 +0100 (CET) Message-ID: <49A654E6.8000605@net.in.tum.de> Date: Thu, 26 Feb 2009 09:37:58 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andrew Johnson References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> <49A4100C.3070902@net.in.tum.de> <49A41630.4030208@cisco.com> <49A50021.3050100@net.in.tum.de> <49A55E5E.9060609@cisco.com> In-Reply-To: <49A55E5E.9060609@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009060307070808020305" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:37:45 -0000 This is a cryptographically signed message in MIME format. --------------ms080009060307070808020305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, >>> Yes, I know. It's very difficult to export min/max/mask using IPFIX >>> without defining new Information Elements for each field you want to >>> filter on. >> >> Hm, I do not think that defining min/max/mask IEs for every existing I= E >> is needed. I'm sure that a better solution can be found. >=20 > Perhaps, I'd certainly like to think so, but so far I've not seen any r= eal > contenders. I can't think of anything that doesn't need data types and= /or > deviate a lot from how we use IPFIX today. >=20 >>>> Note that the configuration data model is based in PSAMP-MIB where >>>> "start", "stop" and "mask" are mentioned as parameters of property >>>> match >>>> filtering. It seems that these parameters are outdated? >>> When we added the Filtering Interpretation Report in version 02 we >>> didn't have min/max/mask either. There's just no easy way to export >>> this sort of think in IPFIX without defining three additional I.E.s p= er >>> field. Unless anyone can think of something? >> >> Yes: >> http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01 >=20 > I don't see how this helps, other than the ability to exclude certain > values. I didn't see any indication of how to handle multiple uses of > the same I.E., but presumably they follow the same rule as for differen= t > I.E.s and are added with an AND operation, and are therefore > automatically conflicting. The abstract data type portRanges has been conceived to report a list of port numbers. This ADT can be used to define an IE destinationTransportPortList which can be used in the Filtering Interpretation Report we have today. I admit that an ADT portRange is very restrictive. Maybe, it is better to standardize an ADT listUnsigned16 which works like "orderedList" in the draft. This ADT can be used to express a list of values for any unsigned16-field. You are right, this approach requires new IEs, but only one new IE for any existing one where it makes sense. Instead of assigning new IE Ids, we could think of a trick using a specific enterprise number (like in biflow) to extend the ADT of existing IEs to list-type ADTs. > For example, how would you represent a match on the TCP syn flag? With= > min/max/flags we could have 0x02, 0x02, 0x02. Easy. > > In the Filtering Interpretation Report you could use multiple inclusion= > filters / selection paths: >=20 > OP1, TCP flags =3D 0x02 > OP1, TCP flags =3D 0x03 > OP1, TCP flags =3D 0x06 > OP1, TCP flags =3D 0x07 > ... > OP1, TCP flags =3D 0x1A > OP1, TCP flags =3D 0x1B > OP1, TCP flags =3D 0x1E > OP1, TCP flags =3D 0x1F >=20 > Yuck. Can you give me an example of all destination ports except port 80 ;) > How would this be done with > http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01? We have not thought of TCP flags, yet. First, we could define an ADT listUnsigned8. Then you can describe all the values from above with a single IE tcpControlBitsList. If you prefer min/max/mask, an ADT minMaxMaskUnsigned8 could be defined with a length of 3 octets. >> In my opinion, the current property match filtering specified in PSAMP= >> is too restrictive because it only covers simplistic fiters that are >> rarely used in practice. Maybe it should be removed from the documents= >> until a better solution is found. >=20 > Well, a future draft could extend the filtering mechanisms, but I don't= > think we should discard what we have today. A new selection type can b= e > added later when we have a way of representing more complex solutions. Do you think that it is possible to standardize such ADTs that follow this "any value of"-semantic? Or would it be a solution that deviates "a lot from how we use IPFIX today" - as you call it? Cheers, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms080009060307070808020305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI2MDgzNzU4WjAjBgkqhkiG9w0BCQQxFgQU OLuu7U5gSV1AspiGMPUGVbbbpB8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIqhI5soQLTpQh1S8kuL7wb4TLLMgSKrUrLRvy7yQu0u5Ul9 s43cQXU2/GzSgK89Atw/NgdsCOFkLUz5RrB+WyoQjm8F3QrhVtqHmSDo1qbOVNf6uRlh/iBJ su3ubjkA25Nasxxn5CtKTaNYqpRQC/hdR7kTqFa3dIfZ63j/z4e1pLrYDLgKYeMWIrrb91+Y heLv6O63Z+U6KljIvGgdO7ir0Fj0Qg/Z2OgD49e02cqGYN7bQY/uyGJ0xtSMVYuPL3tUKBj8 NIyerm0ckcH8TPVJNIs4WYnEkLD9ECQXToeI56iMGZS3ao9qvzofcWMzAIr4hO0h0B82CeYG Alw4XasAAAAAAAA= --------------ms080009060307070808020305-- From muenz@net.in.tum.de Thu Feb 26 01:38:40 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2403A6A32 for ; Thu, 26 Feb 2009 01:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbD0t+QLnMsC for ; Thu, 26 Feb 2009 01:38:39 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id F3C9A3A688C for ; Thu, 26 Feb 2009 01:38:35 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id CE4A748309 for ; Thu, 26 Feb 2009 10:38:46 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B1D0C2807 for ; Thu, 26 Feb 2009 10:38:46 +0100 (CET) Message-ID: <49A6632A.2040201@net.in.tum.de> Date: Thu, 26 Feb 2009 10:38:50 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040603010802030509050205" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX-MIB: comments to AD review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:38:40 -0000 This is a cryptographically signed message in MIME format. --------------ms040603010802030509050205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thomas, all, Sorry for all these late comments. The reason is that I'm currently aligning the MIB to the configuration data model. I would like to add some comments to the AD/MIB doctor review. Possibly, you already solved these issues. > T24. I am wondering whether more counters in this MIB module need to be= > Counter64 rather than Counter32 - especially the bytes and packets > counters ipfixTransportSessionRecords is Counter64, so ipfixMeteringProcessDataRecords should be the same? (currently Counter32) > T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC > 4181) for the following objects: ipfixMeteringProcessId, > ipfixObservationPointGroupReference, ipfixObservationPointIndex, > ipfixTransportSessionRate Same for ipfixObservationDomainId, ipfixTemplateId, ipfixTemplateSetId, ipfixTemplateDefinitionIeId, ipfixTemplateDefinitionIeLength, ipfixTemplateDefinitionEnterprise? Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040603010802030509050205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI2MDkzODUwWjAjBgkqhkiG9w0BCQQxFgQU u/PoNwf9p/BnPF0TaZ366WgjUAUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALlN6aQKGM2uOYbdTyRplZmjbMn/TrsF38KnbeANeVErQ2ih GYKSFowlVlgmf+GHOHwQkwow/r6qh4tpOB4KL2V7pHc8WT2Qocrhz9y5rcvAv6DHnqK+DMFO W2Iri9iAE1/ibHycSpuPtDX2YzIUdBl+9KCYQ7Re5biq8z26o0caYBQOTIKHi3tqJzHkPAQl QKhOee12hFN9pyvz4GZsbXPsImx/GdyVjoVYMWBwQxuusmFuIdv2BqeVicx+hofk4191jTrM Scku/CJkeYXZMzXVOIEgDv9+Qx3EGgucFduDzqwfE5ZErKmt4PU5K24gss214IPNIk+83vg9 mDAprAQAAAAAAAA= --------------ms040603010802030509050205-- From muenz@net.in.tum.de Thu Feb 26 09:49:54 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A623A684E for ; Thu, 26 Feb 2009 09:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OewroapBQaHk for ; Thu, 26 Feb 2009 09:49:53 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 8812F3A68D2 for ; Thu, 26 Feb 2009 09:49:53 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id A23F248309 for ; Thu, 26 Feb 2009 18:50:13 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 85FC0280E for ; Thu, 26 Feb 2009 18:50:13 +0100 (CET) Message-ID: <49A6D65A.8000008@net.in.tum.de> Date: Thu, 26 Feb 2009 18:50:18 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ipfix@ietf.org" References: <49A6632A.2040201@net.in.tum.de> In-Reply-To: <49A6632A.2040201@net.in.tum.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070000030008010000020805" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] IPFIX-MIB: comments to AD review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:49:54 -0000 This is a cryptographically signed message in MIME format. --------------ms070000030008010000020805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One more: ipfixExportMemberType OBJECT-TYPE SYNTAX INTEGER { unknown(0), primary(1), secondary(2), parallel(3), loadBalancing(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of a member Transport Session in a Transport Session group (identified by the value of ipfixExportIndex, ipfixObservationDomainId and ipfixMeteringProcessCacheId). The following values are valid: unknown(0) This value MUST be used if the status of the group membership cannot be detected by the equipment. This value should be avoided as far as possible. primary(1) This value is used for a group member that is used as the primary target of an Exporter. Other group members (with the same ipfixExportIndex and ipfixMeteringProcessCacheId) MUST NOT have the value primary(1) but MUST have the value secondary(2). This value MUST also be specified if the Exporter does not support Transport Session grouping.In this case the group contains only one Transport Session. secondary(2) This value is used for a group member that is used as a secondary target of an Exporter. The Exporter will use one of the targets specified as secondary(2) within the same Transport Session group when the primary target is not reachable. duplicate(3) This value is used for a group member that is used for duplicate exporting i.e., all group members identified by the ipfixExportIndex are exporting the same Records in parallel. This implies that all group members MUST have the the same membertype duplicate(3). loadBalancing(4) This value is used for a group member that is used as as one target for load-balancing. This means that a Record is sent to one of the group members in this group identified by ipfixExportIndex. This implies that all group members MUST have the same membertype load-balancing(4)." ::=3D { ipfixExportEntry 2 } Do you prefer duplicate or parallel for value 3? --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070000030008010000020805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMjI2MTc1MDE4WjAjBgkqhkiG9w0BCQQxFgQU erzCsxvf5t6PL3iCBys9pBZlKLQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACEKGmfNvvEb+ITXCBUdIWH08+hcShUcBPQRFTTjIVYgiOa9 fZdJV4BZCcKIlt21oYMscYFbAtqbEIE9aBxle8CM3JvMCdNkIvPz75U180S7fyTZgEAFopGx p1j/MJIKb7XAlsWqCxe0BzBfyPXykxNLqisHoMc/WfzyTZrZbcQ870n7IbV1AqA1zlmkQ2Ka /cvucPzi9cWy0dAsUC/wNjkhCgYaisyTame7pTxxhozxRO0UXR+BMUXpN42DMeJJBFdA7IXL hWNG/hURhl6JH/tWRc5zXNJJ8NkX+Q3HZgYhSyPLcjeuZpqb8yr4+mnU6faEHCU37R9yiN14 G6HKPscAAAAAAAA= --------------ms070000030008010000020805-- From Quittek@nw.neclab.eu Fri Feb 27 00:27:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DED3A6A60; Fri, 27 Feb 2009 00:27:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktsS0f2TpoZD; Fri, 27 Feb 2009 00:27:32 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B80883A6A76; Fri, 27 Feb 2009 00:27:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B426F2C0004DA; Fri, 27 Feb 2009 09:27:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTZt3j1Ebwi8; Fri, 27 Feb 2009 09:27:53 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 7C1E72C0000EB; Fri, 27 Feb 2009 09:27:43 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Feb 2009 08:27:43 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3318571666_2526679" Content-class: urn:content-classes:message Date: Fri, 27 Feb 2009 09:27:46 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Initial Version I-D Submission Deadline Extended to March 4, 2009 Thread-Index: AcmYtURZX/ltTPd/vECAvW29UxKK3A== From: "Juergen Quittek" To: "IETF IPFIX Working Group" , "IETF PSAMP Working Group" Subject: [IPFIX] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 08:27:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3318571666_2526679 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit For your information. Juergen On 26.02.09 20:27 "Alexa Morris" wrote: > The IESG has extended the deadline for initial version (00) > submissions of Internet Drafts by 2 days (48 hours). The new deadline > is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) > and the extension is for IETF 74 only. The deadline has been extended > due to the copyright legend text alternative being recently finalized, > approved and implemented. > > Please note that the date for updated I-D versions has NOT been > extended, and is still March 9, 2009. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com > --B_3318571666_2526679 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTwOgUdrVfBkuDU5+WN 4G15NAECJzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAy MjcwODI3NDZaMA0GCSqGSIb3DQEBAQUABIIBAHvBdQG3ns3lXQc9wkD/NEkJLAWj9KKFfB8i E/mpXZ00x4ejLJkr4gwnCe8b/xVK/FKUX4XE8CcSRTtxLFuWmTzBVBs2dyNd+7083s15zX2W 5XcBTbHz/d7LfxWK9ivc17697IJYoFgJT5yCyhvkOqpef5m75TroZvqxXf09vqwWlKI5hCoY 6/xm9xnoQOjQLg76dJmQ3GOX37oLLUWkiGhSiZ48gcFJHLOuu9IdkpVYdTu3LSpZZo4nJ0W0 9vh4Hl0pdmrFTSZMrtSil4tVcsKy+bkW4E5iypc9HnYUQvMemqesqSYwxiSqqugaax8m0U6H resRSY3kfkQWYHZpG0s= --B_3318571666_2526679-- From bclaise@cisco.com Fri Feb 27 05:28:40 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824963A67D7 for ; Fri, 27 Feb 2009 05:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kBxi6WBvTik for ; Fri, 27 Feb 2009 05:28:39 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 15A143A6765 for ; Fri, 27 Feb 2009 05:28:38 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1RDSep17223; Fri, 27 Feb 2009 14:28:40 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1RDSdt18737; Fri, 27 Feb 2009 14:28:39 +0100 (CET) Message-ID: <49A7EA86.4020402@cisco.com> Date: Fri, 27 Feb 2009 14:28:38 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <4992F155.2000307@cisco.com> <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> <4993DFF3.9090508@cisco.com> In-Reply-To: <4993DFF3.9090508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sven Anderson , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:28:40 -0000 Dear all, While discussing further with Brian, the agreement is: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of PR-SCTP with the full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. Note that use of UDP is less efficient for the transmission of Common Properties, as they have to be re-sent regularly. If someone objects, please quickly react. Regards, Benoit. > Brian, > > First of all, I would like to have Sven's feedback, as he was the one > asking for this change. > Then, see inline. >> Hi Benoit, all, >> >> Hm, that's still kind of confusing. First off, there's no "reliable >> mode" in PR-SCTP. SCTP is modeless, reliability is per-message. >> PR-SCTP can provide "fully reliable" transport. But this terminology >> seems to be overloaded: >> >> "If the path from the Exporting Process to the Collecting Process is >> full reliable" >> >> What does this mean, precisely? My assumption is that it means "if >> the link between the Exporting Process and the Collecting Process has >> low loss and reordering characteristics..." However, the guidance >> doesn't actually change depending on the loss characteristics of the >> lower layer: RR prefers reliable transport for Common Properties, >> full stop. I'd suggest (as usual...) removing any mention of UDP as >> recommended: > The recommendation doesn't change, agreed. > But the sentence is a warning/clarification against the use of UDP, > even if the path is fully reliable. > So my preference is to keep this sentence (slightly modified, see > below)... however, this is a minor point IMHO. > What are the others thinking? > > >> >> NEW: >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the use >> of PR-SCTP with the full reliability or TCP is recommended for the >> transmission of IPFIX Messages containing Common Properties. > NEW: > The proposed method is most effective using a reliable transport > protocol for the transfer > of the Common Properties. Therefore the use of PR-SCTP with the > full reliability or TCP > is recommended for the transmission of IPFIX Messages containing > Common Properties. > If the path from the Exporting Process to the Collecting Process is > fully reliable (i.e., no loss), > the use of UDP is less effective because the Common Properties have > to be re-sent regularly. > > > Regards, Benoit. >> >> Cheers, >> >> Brian >> >> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: >> >>> Dear all, >>> >>> We received the following remark from Sven regarding >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >>> >>>> 8.1. Transport Protocol Choice >>>> >>>> The proposed method is most effective using a reliable transport >>>> protocol for the transfer of the Common Properties. Therefore the >>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>> However, if the path from the Exporting Process to the Collecting >>>> Process is not fully reliable, the SCTP or TCP retransmission might >>>> reduce the benefits of this specification. If the path from the >>>> Exporting Process to the Collecting Process is full reliable, the >>>> use >>>> of UDP is less effective because the Common Properties have to be >>>> re- >>>> sent regularly. >>> >>> Do I understand that section correctly: If the path is reliable, you >>> should use a reliable transport, and if the path is unreliable you >>> should use unreliable UDP? Isn't that upside down? If the path is >>> reliable, you can use UDP _without_ retransmission, no need for a >>> reliable transport protocol then. >>> We proposed the following text, removing the confusing sentence. >>> NEW: >>> >>> The proposed method is most effective using a reliable transport >>> protocol for the transfer of the Common Properties. Therefore the >>> use of PR-SCTP with the reliable mode or TCP is recommended. >>> If the path from the Exporting Process to the Collecting Process is >>> full reliable, the use of UDP is less effective because the Common >>> Properties have to be re-sent regularly. >>> >>> Any objections? >>> Pending on nobody objecting in a couple of work days, this >>> editorial disambiguation will be applied. >>> >>> Regards, Benoit. >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Fri Feb 27 05:52:38 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F043A6A09 for ; Fri, 27 Feb 2009 05:52:38 -0800 (PST) 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.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y8eiy0BH+Ut for ; Fri, 27 Feb 2009 05:52:37 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 6D51D3A67A4 for ; Fri, 27 Feb 2009 05:52:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1RDqxk19223; Fri, 27 Feb 2009 14:52:59 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1RDqwt05886; Fri, 27 Feb 2009 14:52:58 +0100 (CET) Message-ID: <49A7F03A.8010607@cisco.com> Date: Fri, 27 Feb 2009 14:52:58 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <4992F155.2000307@cisco.com> <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> <4993DFF3.9090508@cisco.com> <49A7EA86.4020402@cisco.com> In-Reply-To: <49A7EA86.4020402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sven Anderson , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:52:39 -0000 Dear all, One quick objection received already for an editorial improvement: remove "the" twice NEW: The proposed method is most effective using a reliable transport protocol for the transfer of Common Properties. Therefore the use of PR-SCTP with full reliability or TCP ^^^ ^^^ is recommended for the transmission of IPFIX Messages containing Common Properties. Note that use of UDP is less efficient for the transmission of Common Properties, as they have to be re-sent regularly. Regards, Benoit. > Dear all, > > While discussing further with Brian, the agreement is: > > The proposed method is most effective using a reliable transport > protocol for the transfer > of the Common Properties. Therefore the use of PR-SCTP with the full > reliability or TCP > is recommended for the transmission of IPFIX Messages containing > Common Properties. > Note that use of UDP is less efficient for the transmission of > Common Properties, as > they have to be re-sent regularly. > > If someone objects, please quickly react. > > Regards, Benoit. > >> Brian, >> >> First of all, I would like to have Sven's feedback, as he was the one >> asking for this change. >> Then, see inline. >>> Hi Benoit, all, >>> >>> Hm, that's still kind of confusing. First off, there's no "reliable >>> mode" in PR-SCTP. SCTP is modeless, reliability is per-message. >>> PR-SCTP can provide "fully reliable" transport. But this terminology >>> seems to be overloaded: >>> >>> "If the path from the Exporting Process to the Collecting Process is >>> full reliable" >>> >>> What does this mean, precisely? My assumption is that it means "if >>> the link between the Exporting Process and the Collecting Process >>> has low loss and reordering characteristics..." However, the >>> guidance doesn't actually change depending on the loss >>> characteristics of the lower layer: RR prefers reliable transport >>> for Common Properties, full stop. I'd suggest (as usual...) removing >>> any mention of UDP as recommended: >> The recommendation doesn't change, agreed. >> But the sentence is a warning/clarification against the use of UDP, >> even if the path is fully reliable. >> So my preference is to keep this sentence (slightly modified, see >> below)... however, this is a minor point IMHO. >> What are the others thinking? >> >> >>> >>> NEW: >>> The proposed method is most effective using a reliable transport >>> protocol for the transfer of the Common Properties. Therefore the >>> use of PR-SCTP with the full reliability or TCP is recommended for >>> the transmission of IPFIX Messages containing Common Properties. >> NEW: >> The proposed method is most effective using a reliable transport >> protocol for the transfer >> of the Common Properties. Therefore the use of PR-SCTP with the >> full reliability or TCP >> is recommended for the transmission of IPFIX Messages containing >> Common Properties. >> If the path from the Exporting Process to the Collecting Process >> is fully reliable (i.e., no loss), >> the use of UDP is less effective because the Common Properties >> have to be re-sent regularly. >> >> >> Regards, Benoit. >>> >>> Cheers, >>> >>> Brian >>> >>> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: >>> >>>> Dear all, >>>> >>>> We received the following remark from Sven regarding >>>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >>>> >>>>> 8.1. Transport Protocol Choice >>>>> >>>>> The proposed method is most effective using a reliable transport >>>>> protocol for the transfer of the Common Properties. Therefore the >>>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>>> However, if the path from the Exporting Process to the Collecting >>>>> Process is not fully reliable, the SCTP or TCP retransmission might >>>>> reduce the benefits of this specification. If the path from the >>>>> Exporting Process to the Collecting Process is full reliable, >>>>> the use >>>>> of UDP is less effective because the Common Properties have to >>>>> be re- >>>>> sent regularly. >>>> >>>> Do I understand that section correctly: If the path is reliable, >>>> you should use a reliable transport, and if the path is unreliable >>>> you should use unreliable UDP? Isn't that upside down? If the path >>>> is reliable, you can use UDP _without_ retransmission, no need for >>>> a reliable transport protocol then. >>>> We proposed the following text, removing the confusing sentence. >>>> NEW: >>>> >>>> The proposed method is most effective using a reliable transport >>>> protocol for the transfer of the Common Properties. Therefore the >>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>> If the path from the Exporting Process to the Collecting Process is >>>> full reliable, the use of UDP is less effective because the Common >>>> Properties have to be re-sent regularly. >>>> >>>> Any objections? >>>> Pending on nobody objecting in a couple of work days, this >>>> editorial disambiguation will be applied. >>>> >>>> Regards, Benoit. >>>> _______________________________________________ >>>> 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 Sven.Anderson@CS.Uni-Goettingen.DE Fri Feb 27 07:34:46 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7778D3A6C2A for ; Fri, 27 Feb 2009 07:34:46 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+oCywsyNTvw for ; Fri, 27 Feb 2009 07:34:45 -0800 (PST) Received: from serv-80-156.SerNet.DE (serv-80-156.SerNet.de [193.175.80.156]) by core3.amsl.com (Postfix) with ESMTP id A159D3A69C7 for ; Fri, 27 Feb 2009 07:34:44 -0800 (PST) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=ltsvenanderson.tmg.loc) by serv-80-156.SerNet.DE with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1Ld4jx-0003Dg-18; Fri, 27 Feb 2009 16:35:05 +0100 Message-Id: <31AEDC66-E325-44F8-B1D4-157AB826FA04@CS.Uni-Goettingen.DE> From: Sven Anderson To: Benoit Claise In-Reply-To: <49A7F03A.8010607@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 16:35:04 +0100 References: <4992F155.2000307@cisco.com> <06231E82-198F-4192-9103-431AADFFBFF2@tik.ee.ethz.ch> <4993DFF3.9090508@cisco.com> <49A7EA86.4020402@cisco.com> <49A7F03A.8010607@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:34:46 -0000 Dear all, Am 27.02.2009 um 14:52 schrieb Benoit Claise: > Dear all, > > One quick objection received already for an editorial improvement: > remove "the" twice > NEW: > The proposed method is most effective using a reliable transport > protocol for the transfer > of Common Properties. Therefore the use of PR-SCTP with full > reliability or TCP > > ^ > ^ > ^ > ^ > ^^ > is recommended for the transmission of IPFIX Messages containing > Common Properties. > Note that use of UDP is less efficient for the transmission of > Common Properties, as > they have to be re-sent regularly. sorry for the long delay. I'm fine with this. Sidenote: Is there a real life example for a reliable (no loss/ reordering) link layer? If so, it would be useful to have an IPFIX transport mode of using UDP _without_ retransmissions. In any other case: always discourage from using UDP. (Which makes the whole UDP/ retransmission scheme useless.) Regards, Sven > Regards, Benoit. > >> Dear all, >> >> While discussing further with Brian, the agreement is: >> >> The proposed method is most effective using a reliable transport >> protocol for the transfer >> of the Common Properties. Therefore the use of PR-SCTP with the >> full reliability or TCP >> is recommended for the transmission of IPFIX Messages containing >> Common Properties. >> Note that use of UDP is less efficient for the transmission of >> Common Properties, as >> they have to be re-sent regularly. >> >> If someone objects, please quickly react. >> >> Regards, Benoit. >> >>> Brian, >>> >>> First of all, I would like to have Sven's feedback, as he was the >>> one asking for this change. >>> Then, see inline. >>>> Hi Benoit, all, >>>> >>>> Hm, that's still kind of confusing. First off, there's no >>>> "reliable mode" in PR-SCTP. SCTP is modeless, reliability is per- >>>> message. PR-SCTP can provide "fully reliable" transport. But this >>>> terminology seems to be overloaded: >>>> >>>> "If the path from the Exporting Process to the Collecting Process >>>> is full reliable" >>>> >>>> What does this mean, precisely? My assumption is that it means >>>> "if the link between the Exporting Process and the Collecting >>>> Process has low loss and reordering characteristics..." However, >>>> the guidance doesn't actually change depending on the loss >>>> characteristics of the lower layer: RR prefers reliable transport >>>> for Common Properties, full stop. I'd suggest (as usual...) >>>> removing any mention of UDP as recommended: >>> The recommendation doesn't change, agreed. >>> But the sentence is a warning/clarification against the use of >>> UDP, even if the path is fully reliable. >>> So my preference is to keep this sentence (slightly modified, see >>> below)... however, this is a minor point IMHO. >>> What are the others thinking? >>> >>> >>>> >>>> NEW: >>>> The proposed method is most effective using a reliable transport >>>> protocol for the transfer of the Common Properties. Therefore the >>>> use of PR-SCTP with the full reliability or TCP is recommended >>>> for the transmission of IPFIX Messages containing Common >>>> Properties. >>> NEW: >>> The proposed method is most effective using a reliable transport >>> protocol for the transfer >>> of the Common Properties. Therefore the use of PR-SCTP with the >>> full reliability or TCP >>> is recommended for the transmission of IPFIX Messages containing >>> Common Properties. >>> If the path from the Exporting Process to the Collecting Process >>> is fully reliable (i.e., no loss), >>> the use of UDP is less effective because the Common Properties >>> have to be re-sent regularly. >>> >>> >>> Regards, Benoit. >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote: >>>> >>>>> Dear all, >>>>> >>>>> We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt >>>>>> 8.1. Transport Protocol Choice >>>>>> >>>>>> The proposed method is most effective using a reliable transport >>>>>> protocol for the transfer of the Common Properties. Therefore >>>>>> the >>>>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>>>> However, if the path from the Exporting Process to the >>>>>> Collecting >>>>>> Process is not fully reliable, the SCTP or TCP retransmission >>>>>> might >>>>>> reduce the benefits of this specification. If the path from the >>>>>> Exporting Process to the Collecting Process is full reliable, >>>>>> the use >>>>>> of UDP is less effective because the Common Properties have to >>>>>> be re- >>>>>> sent regularly. >>>>> >>>>> Do I understand that section correctly: If the path is reliable, >>>>> you should use a reliable transport, and if the path is >>>>> unreliable you should use unreliable UDP? Isn't that upside >>>>> down? If the path is reliable, you can use UDP _without_ >>>>> retransmission, no need for a reliable transport protocol then. >>>>> We proposed the following text, removing the confusing sentence. >>>>> NEW: >>>>> >>>>> The proposed method is most effective using a reliable transport >>>>> protocol for the transfer of the Common Properties. Therefore >>>>> the >>>>> use of PR-SCTP with the reliable mode or TCP is recommended. >>>>> If the path from the Exporting Process to the Collecting >>>>> Process is >>>>> full reliable, the use of UDP is less effective because the >>>>> Common >>>>> Properties have to be re-sent regularly. >>>>> >>>>> Any objections? >>>>> Pending on nobody objecting in a couple of work days, this >>>>> editorial disambiguation will be applied. >>>>> >>>>> Regards, Benoit. >>>>> _______________________________________________ >>>>> 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 >