From ipfix-bounces@ietf.org Mon Oct 13 14:07:53 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201D33A68A9; Mon, 13 Oct 2008 14:07:53 -0700 (PDT) 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 0989C3A68A9 for ; Mon, 13 Oct 2008 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=1.593, BAYES_40=-0.185, 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 O-qvwMioXSKr for ; Mon, 13 Oct 2008 14:07:51 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id ED3253A6821 for ; Mon, 13 Oct 2008 14:07:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2A83C481CEE for ; Tue, 14 Oct 2008 10:07:49 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs9-YBNANaSt for ; Tue, 14 Oct 2008 10:07:49 +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 02B3D4816B3 for ; Tue, 14 Oct 2008 10:07:48 +1300 (NZDT) Message-ID: <48F3B8A4.7030202@auckland.ac.nz> Date: Tue, 14 Oct 2008 10:07:48 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Review of IPFIX MIB -04 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've read the mib-04 draft carefully; it seems clear and consistent, and certainly provides useful insight as to how one could implement an IPFIX Exporter or Collector. One question: Section 5.2, 'Transport Session Table,' holds lots of information about every transpot-layer connection, but it doesn't have an object that says whether a connection is being used for Export or Import. Maybe one could infer that by looking to see whether the end wusing port 4739 is not the one hosting the MIB, but a user may choose not to use the reserved port. I guess one could also infer it from entries in the other tables - Metering Processes perhaps? However, would it be useful to have an object that specifies export/import directly here? Suggested 'editorial' changes: section 2, p5: s/how IPFIX Data Record and Templates/ how IPFIX Data Records and Templates/ sect 3, p6: s/compliant to the SMIv2/compliant with the SMIv2/ s 5.2, p8: s/across unreliable connections as UDP/ across unreliable connections with UDP/ s 5.4, p13: | +- ipfixExportedTemplateDefinitionIeId (2) = 159 | | (flowStartDeltaMicroseconds) s/(flowStartDeltaMicroseconds)/ (flowEndDeltaMicroseconds)/ s 5.5, p14: s/This also The member type/The member type/ s 5.6, p15: s/Observation Points they are observed/ Observation Points where they are observed/ s 5.9, p17: | +- ipfixFuncF2Avail (is the function F2 available) s/available)/available?)/ 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 13 14:07:53 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201D33A68A9; Mon, 13 Oct 2008 14:07:53 -0700 (PDT) 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 0989C3A68A9 for ; Mon, 13 Oct 2008 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=1.593, BAYES_40=-0.185, 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 O-qvwMioXSKr for ; Mon, 13 Oct 2008 14:07:51 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id ED3253A6821 for ; Mon, 13 Oct 2008 14:07:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2A83C481CEE for ; Tue, 14 Oct 2008 10:07:49 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs9-YBNANaSt for ; Tue, 14 Oct 2008 10:07:49 +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 02B3D4816B3 for ; Tue, 14 Oct 2008 10:07:48 +1300 (NZDT) Message-ID: <48F3B8A4.7030202@auckland.ac.nz> Date: Tue, 14 Oct 2008 10:07:48 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Review of IPFIX MIB -04 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've read the mib-04 draft carefully; it seems clear and consistent, and certainly provides useful insight as to how one could implement an IPFIX Exporter or Collector. One question: Section 5.2, 'Transport Session Table,' holds lots of information about every transpot-layer connection, but it doesn't have an object that says whether a connection is being used for Export or Import. Maybe one could infer that by looking to see whether the end wusing port 4739 is not the one hosting the MIB, but a user may choose not to use the reserved port. I guess one could also infer it from entries in the other tables - Metering Processes perhaps? However, would it be useful to have an object that specifies export/import directly here? Suggested 'editorial' changes: section 2, p5: s/how IPFIX Data Record and Templates/ how IPFIX Data Records and Templates/ sect 3, p6: s/compliant to the SMIv2/compliant with the SMIv2/ s 5.2, p8: s/across unreliable connections as UDP/ across unreliable connections with UDP/ s 5.4, p13: | +- ipfixExportedTemplateDefinitionIeId (2) = 159 | | (flowStartDeltaMicroseconds) s/(flowStartDeltaMicroseconds)/ (flowEndDeltaMicroseconds)/ s 5.5, p14: s/This also The member type/The member type/ s 5.6, p15: s/Observation Points they are observed/ Observation Points where they are observed/ s 5.9, p17: | +- ipfixFuncF2Avail (is the function F2 available) s/available)/available?)/ 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 15 07:53:15 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C797B3A6975; Wed, 15 Oct 2008 07:53:15 -0700 (PDT) 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 BBD0A3A695B for ; Wed, 15 Oct 2008 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-2jO9htAauC for ; Wed, 15 Oct 2008 07:53:08 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 5582F3A6975 for ; Wed, 15 Oct 2008 07:53:07 -0700 (PDT) Received: from repulse.net.informatik.tu-muenchen.de ([131.159.14.99]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Kq7lG-0001S4-8y for ipfix@ietf.org; Wed, 15 Oct 2008 16:54:06 +0200 Message-ID: <48F6040C.5090209@informatik.uni-tuebingen.de> Date: Wed, 15 Oct 2008 16:54:04 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> <20080308212938.7A9F.AKOBA@nttv6.net> In-Reply-To: <20080308212938.7A9F.AKOBA@nttv6.net> Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: muenz@net.in.tum.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Kobayashi, A late reply to your proposal to add ACL configuration into IPFIX configuration. We (the authors of the draft) think that ACL configuration is out of scope of IPFIX. The reason is that ACLs in routers are not restricted to packet filtering for IPFIX/Netflow. They affect other router functions as well. Therefore, an ACL should not be regarded as a PSAMP Selection Process. You are right that today's router allow configuring IPFIX/Netflow functions for a given ACL. From the IPFIX point of view, the output of the ACL should then be regarded as the Observation Point, e.g.: linecard =3D> ACL =3D> OP =3D> ... | |--> from here, we are in the scope of IPFIX You are also right that ACL configuration would be a nice feature. However, we think that this is not part of IPFIX standardization. Regards, Gerhard Kobayashi Atsushi wrote: > Hi Gerhard, Benoit and all, > = > This draft is almost complete and great work. > I think that such XML configuration enhances efficiency of the use of > flexibility of IPFIX. > = > IMHO, I am afraid that the filtering method is different than current ACL > implemented in several routers. Therefore, the IPFIX XML cfg might not > be implemented, because of the gap between current ACL filter and IPFIX > XML cfg, even if psamp mention "AND" operation only. = > = > I propose the following XML schema added the ACL elements to -03 draft. > I am not familiar with YANG yet, sorry. > = > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > = > The following Complex/Simple type elements are added. > - Complex Type: accessListMatch_type > - Complex Type: sequenceList_type > - Simple Type: action_type = > = > In addition, it allows "selectionProcess_type" to include > "AccessListMatch" element. = > = > What do you think about that? I think that it enhances flexibility as > optional. = > = > Regards, > Atsushi KOBAYASHI > = > On Mon, 25 Feb 2008 17:50:21 +0100 > Gerhard Muenz wrote: > = >> Dear all, >> >> A new revision of the IPFIX/PSAMP configuration data model has been >> published: >> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.t= xt >> >> Apart from smaller changes in the model itself, the big change compared >> to the previous version concerns the specification language: instead of >> XML Schema, we now use YANG, a new language for modelling Netconf data >> models. As a consequence, conformance to Netconf can be guaranteed. >> >> We received a lot of valuable feedback and support from Martin Bjorklund >> who is a Netconf expert and author of the YANG draft. We will try to get >> some additional feedback from other Netconf experts as well. >> >> Regards, >> Gerhard >> >> -- = >> Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Sand 13 (Room B309), D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 >> E-mail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> > = > --- = > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > = -- = 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 15 07:53:15 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C797B3A6975; Wed, 15 Oct 2008 07:53:15 -0700 (PDT) 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 BBD0A3A695B for ; Wed, 15 Oct 2008 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-2jO9htAauC for ; Wed, 15 Oct 2008 07:53:08 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 5582F3A6975 for ; Wed, 15 Oct 2008 07:53:07 -0700 (PDT) Received: from repulse.net.informatik.tu-muenchen.de ([131.159.14.99]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Kq7lG-0001S4-8y for ipfix@ietf.org; Wed, 15 Oct 2008 16:54:06 +0200 Message-ID: <48F6040C.5090209@informatik.uni-tuebingen.de> Date: Wed, 15 Oct 2008 16:54:04 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> <20080308212938.7A9F.AKOBA@nttv6.net> In-Reply-To: <20080308212938.7A9F.AKOBA@nttv6.net> Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: muenz@net.in.tum.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Kobayashi, A late reply to your proposal to add ACL configuration into IPFIX configuration. We (the authors of the draft) think that ACL configuration is out of scope of IPFIX. The reason is that ACLs in routers are not restricted to packet filtering for IPFIX/Netflow. They affect other router functions as well. Therefore, an ACL should not be regarded as a PSAMP Selection Process. You are right that today's router allow configuring IPFIX/Netflow functions for a given ACL. From the IPFIX point of view, the output of the ACL should then be regarded as the Observation Point, e.g.: linecard =3D> ACL =3D> OP =3D> ... | |--> from here, we are in the scope of IPFIX You are also right that ACL configuration would be a nice feature. However, we think that this is not part of IPFIX standardization. Regards, Gerhard Kobayashi Atsushi wrote: > Hi Gerhard, Benoit and all, > = > This draft is almost complete and great work. > I think that such XML configuration enhances efficiency of the use of > flexibility of IPFIX. > = > IMHO, I am afraid that the filtering method is different than current ACL > implemented in several routers. Therefore, the IPFIX XML cfg might not > be implemented, because of the gap between current ACL filter and IPFIX > XML cfg, even if psamp mention "AND" operation only. = > = > I propose the following XML schema added the ACL elements to -03 draft. > I am not familiar with YANG yet, sorry. > = > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > = > The following Complex/Simple type elements are added. > - Complex Type: accessListMatch_type > - Complex Type: sequenceList_type > - Simple Type: action_type = > = > In addition, it allows "selectionProcess_type" to include > "AccessListMatch" element. = > = > What do you think about that? I think that it enhances flexibility as > optional. = > = > Regards, > Atsushi KOBAYASHI > = > On Mon, 25 Feb 2008 17:50:21 +0100 > Gerhard Muenz wrote: > = >> Dear all, >> >> A new revision of the IPFIX/PSAMP configuration data model has been >> published: >> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.t= xt >> >> Apart from smaller changes in the model itself, the big change compared >> to the previous version concerns the specification language: instead of >> XML Schema, we now use YANG, a new language for modelling Netconf data >> models. As a consequence, conformance to Netconf can be guaranteed. >> >> We received a lot of valuable feedback and support from Martin Bjorklund >> who is a Netconf expert and author of the YANG draft. We will try to get >> some additional feedback from other Netconf experts as well. >> >> Regards, >> Gerhard >> >> -- = >> Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Sand 13 (Room B309), D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 >> E-mail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> > = > --- = > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > = -- = 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From Tax_Refund@IRS.gov Wed Oct 15 09:23:39 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A39928C283 for ; Wed, 15 Oct 2008 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.36 X-Spam-Level: X-Spam-Status: No, score=-94.36 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, MIME_HTML_ONLY=1.457, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] 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 hoopD-WX-tGL for ; Wed, 15 Oct 2008 09:23:39 -0700 (PDT) Received: from www.focusonline.com (www.focusonline.com [72.3.245.108]) by core3.amsl.com (Postfix) with ESMTP id 0F79128C277 for ; Wed, 15 Oct 2008 09:23:38 -0700 (PDT) Received: from User (cmr-208-97-105-83.cr.net.cable.rogers.com [208.97.105.83]) (authenticated bits=0) by www.focusonline.com (8.12.11.20060308/8.12.11) with ESMTP id m9FGOYNG024926; Wed, 15 Oct 2008 10:24:36 -0600 Message-Id: <200810151624.m9FGOYNG024926@www.focusonline.com> Reply-To: From: "Internal Revenue Service" Subject: IRS : Tax refund value is $252.60 Date: Wed, 15 Oct 2008 12:29:50 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 To: undisclosed-recipients:;

 

Dear Applicant:



After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $252.60.
Please submit the tax refund request and allow us 3-6 days in order to IWP the data received.



▪ If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will
be used for section 497 (c) (15) purposes.



▪ If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors,
trustees, members, or major contributors.



To access the form for your tax refund, please click here



This notification has been sent by the Internal Revenue Service,
a bureau of the Department of the Treasury.

Sincerely Yours,
Director, Exempt. Organization
Rulings and Agreements Letter
Internal Revenue Service


Note:
▪ If you received this message in your SPAM/BULK folder, that is because  of the restrictions implemented by your ISP
▪ For security reasons, we will record your ip address, the date and time.
▪ Deliberate wrong imputs are criminally pursued and indicted.

© Copyright 2008, Internal Revenue Service U.S.A.

From ipfix-bounces@ietf.org Thu Oct 16 03:51:21 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4813A3A6906; Thu, 16 Oct 2008 03:51:21 -0700 (PDT) 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 8101C3A657C for ; Thu, 16 Oct 2008 03:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EPM4JiPfqlSu for ; Thu, 16 Oct 2008 03:50:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 5915C3A6906 for ; Thu, 16 Oct 2008 03:50:47 -0700 (PDT) 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 m9GApbg15768; Thu, 16 Oct 2008 12:51:38 +0200 (CEST) Received: from [10.61.93.146] (ams3-vpn-dhcp7571.cisco.com [10.61.93.146]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9GApZG15739; Thu, 16 Oct 2008 12:51:35 +0200 (CEST) Message-ID: <48F71CB7.706@cisco.com> Date: Thu, 16 Oct 2008 12:51:35 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Brian Trammell References: <3B2C1602-5624-4428-A706-5CFF6C3DDE52@tik.ee.ethz.ch> In-Reply-To: <3B2C1602-5624-4428-A706-5CFF6C3DDE52@tik.ee.ethz.ch> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] SCTP per-stream WGLC 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: , Content-Type: multipart/mixed; boundary="===============1144050565==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1144050565== Content-Type: multipart/alternative; boundary="------------010003000207020803040704" This is a multi-part message in MIME format. --------------010003000207020803040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Many thanks! Not only you got some good points, but you even proposed some new text. This is the perfect review. See inline. > All, > > The following is a review of the SCTP perstream draft for WGLC. > > Serious issues (repeated inline): > > It is not clear in the language of the document that it is not > intended to update 5101, though its intended status precludes this. > At the beginning of section 4, there is this proposed text: This section introduces improvements compared to the IPFIX specifications in [RFC5101]. These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119 ]. > Additionally, there are some specifications with respect to Collecting > Processes which may break interoperability. > > The Data Record Reliability Options Template does not appear to be > necessary, or at least, its purpose is unclear. As I read it the CP > can deduce all the information it provides rather easily. > > General comments: > > I have not consistently corrected the grammar in the document where it > does not have a significant impact on clarity (e.g. spurious > articles), though the document does need a grammar and typographic > editing pass between now and final publication. > Surely one of the native English speakers in the author list will do a final check > There is one general terminology issue which should be addressed; it > appears that throughout the document the phrase "Template ID" is used > to mean "number identifying a Template" as well as "Data Records (or > Data Sets) described by (or associated with) a Template". I agree this > latter construct is really awkward, but "Template ID" is a confusing > shorthand for the concept, and suggest finding a replacement and using > it consistently. > I reviewed all "template" instances in the document, and I agree with your statement. I changed a few sentences. > >> 1. Terminology >> >> IPFIX-specific terminology used in this document is defined >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- >> specific terms have the first letter of a word capitalized >> when used in this document. >> >> Template Reuse Delay >> >> The configurable timeout to allow the Collecting Process >> to receive and process the last Data Record using this >> Template information before which the Template Withdrawal >> Message MUST NOT be sent. [RFC5101] specifies a default >> value of 5 seconds. >> > > The wording here is confusing. I don't know what a Template Reuse > Delay is from this text. Is this correct: > > "The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template." > This is a better wording, you're right. Alternatively, I can simply cut and paste the sentence from RFC5101 According to the IPFIX specifications [RFC5101], the Template Withdrawal Message MUST NOT be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This configurable time is called the Template Reuse Delay. [RFC5101] specifies a default value of 5 seconds. Which one do you prefer? > It's not a CP delay, or is it? I'm confused as to what configurability > at the CP has to do with it. > > >> 2. Introduction >> >> The IPFIX working group has specified a protocol to export IP >> Flow information [RFC5101]. This protocol is designed to >> export information about IP traffic Flows and related >> measurement data, where a Flow is defined by a set of key >> attributes (e.g. source and destination IP address, source >> and destination port, etc.). However, thanks to its template >> mechanism, the IPFIX protocol can export any type of >> information, as long as the relevant Information Element is >> specified in the IPFIX Information Model [RFC5102], >> registered with IANA, or specified as an enterprise-specific >> Information Element. >> >> The IPFIX protocol [RFC5101] specifies that IP traffic >> measurements for Flows are exported using a TLV (type, >> length, value) format. The information is exported using a >> Template Record that is sent once to export the {type, >> length} pairs that define the data format for the Information >> Elements in a Flow. The Data Records specify values for each >> Flow. >> >> The IPFIX protocol [RFC5101] is flexible: it foresees the >> usage >> of the multiple SCTP streams per association; it allows the >> transmission of Data Sets, Template Sets, and/or Options >> Template Sets on any stream; it offers the full or partial >> reliability export of Data Sets; it proposes the ordered or >> out- >> of-order delivery of Data Sets. However, due to bandwidth >> >> >> Expires January 1, 2009 [Page 5] >> >> Internet-Draft July >> 2008 >> >> >> restrictions and packet losses in the network as well as >> resource constraints on the Exporter and Collector (e.g., >> limited buffer sizes), it is not always possible to export all >> Data Sets in a reliable way. >> >> > > I'm going to make a few stylistic suggestions here in the > introduction, because the introduction, I think, needs to be very > clear as to what the document is, and it reads a little awkwardly to > me as it stands. > > >> Without delving into the details of the specifications >> described >> later on in this document, the basic idea is to export the >> Template Record and its associated Data Sets into a single >> unique SCTP stream, ideally to limit the Template ID to a >> single >> stream, while imposing in-order transmission. >> > > Introductory construct is a little unclear. Suggest replacement of > this paragraph with: > > This document specifies a method for exporting a Template Record and > its associated Data Sets in a single SCTP stream, limiting each > Template ID to a single stream if possible, and imposing in-order > transmission. > That reads a lot better. Done. > >> The specification in this document offers several advantages >> such as: calculation of Data Record losses in case of >> partially- >> reliable SCTP export, immediate export of the Template >> Withdrawal Message, immediate reuse of template ID within a >> stream, reduced likelihood of losing Data Record, and the >> Collecting Process's job is easier. >> > > Text is not parallel; there are typographic errors here as well. > Suggest replacement of this paragraph with: > > This method offers several advantages over IPFIX export as specified > in [RFC5101] such as the ability to calculate Data Record losses for > PR-SCTP, immediate export of Template Withdrawal Messages, immediate > reuse of Template IDs within an SCTP stream, reduced likelihood of > Data Record loss, and reduced demands on the Collecting Process. > > Good proposal. Done. I've also updated the abstract to be in line with this paragraph. >> 2.1. Relationship with IPFIX and PSAMP >> >> The specification in this document applies to the IPFIX >> protocol specifications [RFC5101]. However, it only applies >> to the SCTP transport protocol [RFC4960] option of the IPFIX >> protocol specifications, specifically in the case of the >> partial reliability extension [RFC3758]. All specifications >> from [RFC5101] apply unless specified otherwise in this >> document. >> >> As the Packet Sampling (PSAMP) protocol specifications >> [PSAMP-PROTO] are based on the IPFIX protocol specifications, >> the specifications in this document are also valid for the >> PSAMP protocol. Therefore, the advantages specified by this >> document also apply to PSAMP. >> > > The document specifies a method, not a set of advantages; suggest > "Therefore, the method..." > Done. >> 2.2. Applicability >> >> The specifications are required in cases where we must know >> how >> many Data Records of a certain type (i.e. from a certain >> Template ID) were lost. Furthermore, they apply in cases >> where >> the Exporter can not afford to export all the Flow Records >> reliably, due to the limited resources to buffer the huge >> amount >> of flow records. Such situations may occur if Data Sets are >> generated at a higher rate at the Exporter than can be >> transferred to the Collector because of bandwidth >> limitations in >> >> >> Expires January 1, 2009 [Page 6] >> >> Internet-Draft July >> 2008 >> >> >> the network or slow reception at the Collector. A typically >> example is a router exporting billing records. >> > > typical example > Done. > >> To be more precise, the specification applicability is the >> case >> where multiple Template IDs are sent within a SCTP Transport >> Session and the calculation of the Data Record loss for a >> particular one Template ID is required. Indeed, with the >> current IPFIX specifications [RFC5101], if an IPFIX Message is >> lost (UDP or SCTP partially reliable), it is not possible to >> determine to which Template ID of the Transport Session the >> lost >> Data Records belong to. >> > > Not in the general case, no. An EP can of course use only a single > template for all export in a given session, or use a separate > observation domain for each application. This is not the _only_ way > under the current spec to estimate loss, it's just the most SCTP > friendly, and the least hackish. > Understood. To stress the point, I changed "within a SCTP Transport Session" into "within a _single _SCTP Transport Session" I also added the following sentence as a new paragraph at the end of the section 3.1.1 (I think it's more appropriate there): "Note that a workaround allowed by the IPFIX specifications [RFC5101] is to use only one Template per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template are required." I propose not to mention the option of separate observation domain as this hack will certainly lead to some more confusion. > >> In terms of Collector, there is backwards compatibility: the >> Collecting Process does not require any changes to support an >> Exporter that complies to the specifications in this document. >> > > Suggest: > > Exporting Processes following this specification will interoperate > with existing Collecting Processes that comply with [RFC5101]; no > changes are required at the Collecting Process to support this method. > Done. > >> 2.3. Limitations >> >> To be compliant with the specifications in this document, the >> Transport Session must support multiple SCTP streams. >> Furthermore, if the SCTP Transport Session does not support >> enough streams for the increasing number of Template ID in the >> Transport Session, the addition of streams must be supported >> according to [SCTP-RESET]. Alternatively, the new Template ID >> and associated Data Records may be added to an existing stream >> at the cost of diluting the granularity of Data Records loss. >> The other alternatives, which is not practical in operational >> networks, is to restart the SCTP association with an increase >> number of streams. >> > > A few unclear and nonstandard constructs here, and a little > terminology confusion. The discussion of alternatives to one-session- > per-stream and SCTP reset is not a limitation of the approach, it's a > workaround to limitations in certain SCTP stacks, and is a bit > detailed for an introduction I think. Suggest replacement: > > This method requires multiple SCTP streams in the association between > the Exporting and Collecting Process, ideally one per Template. The > SCTP association should support the addition of streams according to > [SCTP-RESET] in order to handle the transmission of additional > Templates during the Transport Session. > Perfect. > >> 3. IPFIX Protocol Specifications Limitations and Improvements >> > > I think this section needs some frontmatter explaining its > organization. From the point of view of the TOC it makes sense, but > reading the document through end to end it's a little disorienting. > New proposal For three specific topics (Data Record Loss per Template, Transmission Order within a Stream, No Transmission Order across SCTP Streams), this section explains the IPFIX protocol specifications limitations on one hand, and the advantages of the method specified in this document on the other hand. > >> 3.2.2. IPFIX Export per SCTP Stream Advantages >> >> By exporting each Template Record and the corresponding Data >> Records within a single stream and imposing in-order >> transmission, the Template will always arrive before the >> associated Data Records. Therefore, there is no risk that >> the Collecting Process discards Data Records while waiting >> for the Template to arrive. >> >> Furthermore, when reusing a Template ID within a stream, the >> Template Withdrawal Message will be guaranteed to arrive >> before the new definition of the Template and therefore the >> Template Record may be sent directly after the Template >> Withdrawal Message. In other words, the Template Reuse Delay >> restriction (by default, 5 seconds, as specified in [RFC5101] >> is removed for Template ID reuse within the same stream. >> >> Another advantage with the new specifications in this >> document is that the Collecting Process's job is now easier. >> Indeed, the Collecting Process doesn't have to store the Data >> Records while waiting for the Template Records, as the >> transmission order is always guaranteed. This way, extra >> reliability of the Data Records is achieved without extra >> burden on the Collecting Process. >> > > Prefer "reduces load on the CP" to "the CP's job is now easier"; the > latter reads quite informally for a specification. > Done. > It might be nice if there were some way for a full-featured CP (i.e. > one that supports buffering of Data Sets with missing Templates) to > know whether it had to preallocate buffers for such a thing, but this > is a very minor technical point. > Since we must have the backwards compatible with other RFC 5101 CPs, I'm not sure if this possible. > >> 3.3.2. IPFIX Export per SCTP Stream Advantages >> >> By exporting each Template Record and the corresponding Data >> Records within a single stream, imposing in-order >> transmission, and limiting the Template ID to a single >> stream, the issue of ordered transmission across multiple >> streams is avoided. >> >> By exporting all corresponding Data Records within the same >> ordered stream as the Template Definition, each stream is >> independent and self-contained and the interaction between >> streams is limited to that of Options Data interactions. This >> has several advantageous consequences, including the order >> preservation that does not result in the blocking of unrelated >> data and the Collector's job simplification (as the Template >> Records are guaranteed to be delivered before the associated >> Data Records). >> > > see previous comments about the "collector's job" language. > New text: This has several advantageous consequences, including the order preservation that does not result in the blocking of unrelated data and load reduction on the Collecting Process (as the Template Records are guaranteed to be delivered before the associated Data Records, there is no need for buffering of Data Sets with missing Templates). > >> 4. Specifications >> >> 4.1. Template Management >> >> This section introduces modifications compared to the Template >> Management section 8 in [RFC5101]. >> >> >> Expires January 1, 2009 [Page 10] >> >> Internet-Draft July >> 2008 >> >> >> >> As specified in [RFC5101], Template Sets and Options Template >> Sets MUST be sent reliably. In other words, any IPFIX Message >> containing an (Options) Template Set MUST be sent reliably. >> > > Verify that all 2119 keywords drawn from 5101 actually do restate the > point properly; as I recall there was a bit of trouble over this with > the implementation guidelines. > When I wrote "As specified in [RFC5101]", I always cut and pasted the exact sentence(s) from RFC5101. If there is something specific to this draft, I would start a new paragraph > >> Any Data Sets associated with a Template Record MUST be sent >> on >> the same stream on which the Template Record was sent. >> > > The use of 2119 MUST language here implies a mandatory modification to > 5101. I know this is not the case given the document's intended > status, but perhaps there should be some frontmatter in section four > scoping the 2119 keywords within this section to implementations of > the specification only. > Proposed new text in section 4 This section introduces improvements compared to the IPFIX specifications in [RFC5101]. These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119 ]. > >> The Exporter SHOULD send a single Template and associated Data >> Sets within a single stream in order to calculate the >> potential >> Data Record loss for this Template ID. >> > > in order to _enable_ calculation (it's the collector doing the loss > calculation, right, not the exporter?) > Done. > >> However, the Exporter >> MAY group related Templates and their associated Data Sets >> within a single stream so loss statistics are calculated for >> the >> group. This may be suitable in cases where there is >> insufficient SCTP streams to send each Template on its own >> stream and/or the case where there are slight variations on a >> single Template to show that some fields were unavailable at >> the >> time of monitoring. >> > > This last sentence is kind of confusing. What I think you mean is: > > This is suitable in cases where there are only slight variations among > the templates in a group, e.g. the omission of unavailable fields for > export efficiency, and may be necessary if the SCTP association does > not support enough streams to export each Template in its own stream. > Nicely expressed. Done. > Hmm... Actually, I think the specification would be greatly improved > by the formal introduction of a "template group" concept, and the > rephrasing of the specification to cover the export of one template > _group_ per stream. Since the omission of missing fields is not only > common practice but recommended by the documents, you're often likely > to get a set of related templates. Exporting these as a group is I > think what you're really trying to do with this document, since it's > application-granularity loss you're trying to estimate, yes? > Actually, we're saying: _always _export one template per SCTP stream, except in some circumstances: - you don't care about the loss calculation - you want to export within the same stream the option template record that will help the data record interpretation (example: sampling rate) - you don't have enough SCTP stream. If this is the case, use "template group" > >> If a SCTP stream contains a mixture of Data Records defined >> by a >> Template Record and Options Template Record(s), the Data >> Records >> defined by the Options Template Record(s) SHOULD be sent >> reliably within the same stream so that the Collector does not >> consider any loss to be associated with the Options Data. >> Indeed, if the Collector does not have the guarantee that the >> Data Records defined by the Options Template Record are sent >> reliably, the Collector can not determine whether the loss in >> that stream belongs to the Data Records defined by the >> Template >> Record, defined by the Option Template Record, or by both of >> them. By sending the Options Data reliably (which is usually >> required to interpret the Data Records correctly), any loss >> will >> be limited to the non-option Data Record and loss can still be >> calculated on a per Template basis. >> >> For each (Options) Template Record, the Exporting Process MUST >> send the Data Record Reliability Option Template using an >> Option >> Template with the following Information Elements: >> >> SCOPE: Template ID >> NOT-SCOPE: dataRecordsReliability >> >> The Data Record Reliability Option Template MUST be sent >> reliably. >> >> > > It's a template, so it must be sent reliably. This is redundant. Yes. I removed it. > Or do > you mean the record described by this template? > > More seriously, I don't see the point of this Option. Can't the CP > just deduce from the EP's actions whether it's sending the data for a > given template reliably or not? How? Isn't it a layer violation if the Exporter looks in the SCTP transport to determine the reliability level? Also, just because the Exporter sent some records reliably there is not a guaranteed indication of future intent, or more specifically an indication that any lost records won't be associated with this Template ID. > Also, what additional functionality > does the CP really gain by deducing this? Doesn't all the stream loss > estimation stuff still work (well, on a per-group basis, anyway)? > If you're sending with the same SCTP stream, a mix of: flows record with sampled data and sampler ID option template describing the sampling rate asssociated with a specifier sampler ID If the CP sees a gap in the sequence number, and the CP doesn't know that the option data records (for a lack a better term) are sent reliably, what should be the CP deduce? 1. I lost a flow record -> this is pretty bad from an accuracy point of view OR 2. I lost an option data record -> I can't fully interpret my data. This mechanism will help the CP to say that the loss comes only from data record, because the option data record were sent reliably. I understand that this is a different "group" that what you described above, as in this case the group contains data records and associated option data records. Really the options data is considered information that supports the interpretation of the group data, but isn't part of the group. > >> Expires January 1, 2009 [Page 11] >> >> Internet-Draft July >> 2008 >> >> >> The Option Data Record SHOULD be sent before the Data Record >> that needs it so that it arrives first and is available for >> the >> Collector to use. >> > > And I presume it should also be sent reliably? > Yes, added. Note: the "Option Data Record" doesn't exist. New text: The Data Record defined by the Data Record Reliability Option Template SHOULD be sent, reliably, before the Data Record that needs it so that it arrives first and is available for the Collector to use. In some other instances of "Option Data Record", I changed the draft to use _o_ption Data Record > >> 4.2. New Information Element >> >> dataRecordsReliability >> >> Description: >> The Data Records reliability associated with this >> Template ID. The integer value 1 means that the Data >> Records are sent reliably, while the integer value 2 >> means that the Data Records are not sent reliably. >> Abstract Data Type: boolean >> Data Type Semantics: identifier >> ElementId: xxx >> Status: current >> > > Inconsistent. Is it an integer, or a boolean? > >From RFC5101 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579 ]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet. However, you're right, let's not confuse the information model with the encoding rule New proposed text: Description: The Data Records reliability associated with this Template ID. The true value means that the Data Records are sent reliably, while the false value means that the Data Records are not sent reliably. > >> 4.3. SCTP >> >> This section introduces modifications compared to the "SCTP" >> section 10.2 (and subsections) in [RFC5101]. More >> specifically >> the "Stream" section 10.2.4.3 >> > > See above about 2119 language and intended status. This frontmatter > clearly reads as if it supercedes or updates 5101, which is not the > case. > This section introduces some more specific specifications compared to the "SCTP" section 10.2 (and subsections) in [RFC5101]. > >> PR-SCTP [RFC3758] MUST be implemented by all compliant >> implementations. >> >> All IPFIX Messages MUST be sent in order within a stream. >> >> Depending on the application requirement, the Exporting >> Process >> MAY send Data Sets with full or partial reliability. >> Unreliable >> data transfer MAY be used where the application does not >> require >> reliable transmission or the use of a retransmission queue is >> impractical due to resource restrictions at the Exporter. >> >> >> If the Exporting Process requires to export a new Template but >> there are no more free SCTP streams available, it SHOULD >> attempt >> to increase the number of outbound streams it is able to send >> to, per [SCTP-RESET]. Alternatively, the Exporting Process >> MAY >> add the Template Set and Data Records to an existing stream at >> the cost of diluting the granularity of Data Records loss. >> >> >> >> >> >> Expires January 1, 2009 [Page 12] >> >> Internet-Draft July >> 2008 >> >> >> 4.4. Template Withdrawal Message >> >> This section introduces Template Withdrawal Message-related >> modifications compared to the Template Management section 8 in >> [RFC5101]. >> > > As above. > > >> Templates that are not used anymore SHOULD be deleted. Before >> reusing a Template ID, the Template MUST be deleted. In order >> to delete an allocated Template, the Template is withdrawn >> through the use of a Template Withdrawal Message. The >> Template >> Withdrawal Message MUST be sent on the same stream as the >> Template Record. >> > > Inconsistent terminology. Template deletion == withdrawal? > > The first two sentences are cut and pasted from RFC5101. I added "as specified in [RFC5101] in front of them > >> As the Template Withdrawal Message MUST be sent reliably, >> using >> SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages >> are sent in order within a stream (per the specifications in >> this document), the IPFIX Message containing the Template >> Withdrawal Message will not arrive at the Collecting Process >> before any associated and previously sent Data Record. As a >> consequence, no Data Records will be lost due to delayed >> arrival >> at the Collector. >> >> The Template ID from a withdrawn Template MAY be reused on the >> same stream immediately after the Template Withdrawal >> Message is >> sent. This case is equivalent to the use of a Template Reuse >> Delay value of 0. >> >> If the new definition of the Template ID is to be reused on a >> different stream, the Template Withdrawal Message MUST NOT be >> sent before the Template Reuse Delay. >> >> A Template Withdrawal Message to withdraw all Templates for >> the >> Observation Domain ID specified in the IPFIX Message header >> MUST >> NOT be used. >> >> Multiple Template IDs MAY be withdrawn with a single Template >> Withdrawal Message at the condition that all the Template >> IDs in >> the Template Withdrawal Message are used on the same SCTP >> stream. >> >> >> 4.5. The Collecting Process's Side >> >> This section introduces modifications to the Collection >> Process >> as compared to section 9 in [RFC5101]. >> > > Modification of Collecting Process behavior is in conflict with the > statement in the introduction that EPs using this spec interoperate > with 5101 CPs. Which is it? > New proposal. This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101]. However, the new specifications are backwards compatible with RFC5101-compliant Collecting Processes. > >> Expires January 1, 2009 [Page 13] >> >> Internet-Draft July >> 2008 >> >> >> The Collecting Process SHOULD listen for a new association >> request from the Exporting Process. The Exporting Process >> will >> request a number of streams to use for export: the number of >> streams SHOULD be equivalent to the number of simultaneous >> Template Records used in the association. Note that the >> Template >> Records don't include the Options Template Records. >> > > This statement does not modify 5101 CP behavior and is superfluous. > It might not be obvious for new comers. So we thought about adding that. Anyway, removed. > >> A Collecting Process SHOULD support the procedure for the >> addition of an SCTP stream [SCTP-RESET]. >> >> The IPFIX protocol has a Sequence Number field in the IPFIX >> Message header that increases with the number of IPFIX Data >> Records in the IPFIX Message. A Collector may detect out-of- >> sequence, dropped, or duplicate IPFIX Messages by tracking the >> Sequence Number. As this Sequence Number is per SCTP stream, >> the loss for the Data Records sent in that stream can be >> calculated in case of partially-reliable export. >> > > A recommendation for how to do this calculation would be nice here. > New proposal When one or more IPFIX Messages are considered lost, the number of lost Data Records is equal to the Sequence Number of the first IPFIX Message Header following the lost packets (S2) minus the Sequence Number of the first lost IPFIX Message (S1). The Sequence Number of the first lost IPFIX Message can be calculated as the Sequence Number of the last IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the number of Data Records in that IPFIX Message (N0). S1 = S0 + N0 loss = S2 - S1 = S2 - (S0 + N0) > >> If the Collecting Process receives a Template Withdrawal >> Message >> on a different stream than the one on which the Template ID is >> used, then the Collecting Process MUST reset the association >> and >> SHOULD log an error message. >> > > This is not possible without superceding 5101 and breaking > interoperability with stock 5101 EPs. Therefore it must be removed. > Good catch. New text: If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message. > Furthermore (though I know we do it all over the protocol), CP- > initiated Transport Session shutdown does not follow the general > protocol design rule of "be conservative in what you send and liberal > in what you accept". Adding a new condition where we do this would be > less than ideal. But I accept that I lost this fight a while ago. :) > Actually we have heard some very good arguments against Postel's robustness principle. In 2001 Marshall Rose wrote: Counter-intuitively, Postel's robustness principle ("be conservative in what you send, liberal in what you accept") often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next. > >> The following sentences from [RFC5101] are not applicable in >> this specification: >> >> "The Collecting Process normally receives Template Records >> from the Exporting Process before receiving Data Records. >> The Data Records are then decoded and stored by the >> Collector. If the Template Records have not been >> received at >> the time Data Records are received, the Collecting Process >> MAY store the Data Records for a short period of time and >> decode them after the Template Records are received." >> > > No need to remove this. CPs may still support buffering of template- > less Data even if the EP doesn't require them to. > Sentences removed. Regards, Benoit. > Regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------010003000207020803040704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Many thanks! Not only you got some good points, but you even proposed some new text. This is the perfect review.
See inline.
All,

The following is a review of the SCTP perstream draft for WGLC.

Serious issues (repeated inline):

It is not clear in the language of the document that it is not  
intended to update 5101, though its intended status precludes this.
At the beginning of section 4, there is this proposed text:

This section introduces improvements compared to the IPFIX specifications in [RFC5101].  These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119].


Additionally, there are some specifications with respect to Collecting  
Processes which may break interoperability.

The Data Record Reliability Options Template does not appear to be  
necessary, or at least, its purpose is unclear. As I read it the CP  
can deduce all the information it provides rather easily.

General comments:

I have not consistently corrected the grammar in the document where it  
does not have a significant impact on clarity (e.g. spurious  
articles), though the document does need a grammar and typographic  
editing pass between now and final publication.
Surely one of the native English speakers in the author list will do a final check

There is one general terminology issue which should be addressed; it  
appears that throughout the document the phrase "Template ID" is used  
to mean "number identifying a Template" as well as "Data Records (or  
Data Sets) described by (or associated with) a Template". I agree this  
latter construct is really awkward, but "Template ID" is a confusing  
shorthand for the concept, and suggest finding a replacement and using  
it consistently.
I reviewed all "template" instances in the document, and I agree with your statement.
I changed a few sentences.
 
  
 1. Terminology

        IPFIX-specific terminology used in this document is defined
        in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
        specific terms have the first letter of a word capitalized
        when used in this document.

        Template Reuse Delay

           The configurable timeout to allow the Collecting Process
           to receive and process the last Data Record using this
           Template information before which the Template Withdrawal
           Message MUST NOT be sent.  [RFC5101] specifies a default
           value of 5 seconds.
    

The wording here is confusing. I don't know what a Template Reuse  
Delay is from this text. Is this correct:

"The time after sending the last Data Set described by a given  
Template the Exporting Process MUST wait before sending a Template  
Withdrawal Message for the Template."
This is a better wording, you're right.

Alternatively, I can simply cut and paste the sentence from RFC5101
   According to the IPFIX specifications [RFC5101], the Template 
   Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.  This
   configurable time is called the Template Reuse Delay.  [RFC5101] 
   specifies a default value of 5 seconds.
Which one do you prefer?
It's not a CP delay, or is it? I'm confused as to what configurability  
at the CP has to do with it.
  
  
     2. Introduction

        The IPFIX working group has specified a protocol to export IP
        Flow information [RFC5101].  This protocol is designed to
        export information about IP traffic Flows and related
        measurement data, where a Flow is defined by a set of key
        attributes (e.g. source and destination IP address, source
        and destination port, etc.).  However, thanks to its template
        mechanism, the IPFIX protocol can export any type of
        information, as long as the relevant Information Element is
        specified in the IPFIX Information Model [RFC5102],
        registered with IANA, or specified as an enterprise-specific
        Information Element.

        The IPFIX protocol [RFC5101] specifies that IP traffic
        measurements for Flows are exported using a TLV (type,
        length, value) format.  The information is exported using a
        Template Record that is sent once to export the {type,
        length} pairs that define the data format for the Information
        Elements in a Flow.  The Data Records specify values for each
        Flow.

        The IPFIX protocol [RFC5101] is flexible: it foresees the  
usage
        of the multiple SCTP streams per association; it allows the
        transmission of Data Sets, Template Sets, and/or Options
        Template Sets on any stream; it offers the full or partial
        reliability export of Data Sets; it proposes the ordered or  
out-
        of-order delivery of Data Sets.  However, due to bandwidth


     <Claise, et. Al>       Expires January 1, 2009           [Page 5]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        restrictions and packet losses in the network as well as
        resource constraints on the Exporter and Collector (e.g.,
        limited buffer sizes), it is not always possible to export all
        Data Sets in a reliable way.

    

I'm going to make a few stylistic suggestions here in the  
introduction, because the introduction, I think, needs to be very  
clear as to what the document is, and it reads a little awkwardly to  
me as it stands.

  
        Without delving into the details of the specifications  
described
        later on in this document, the basic idea is to export the
        Template Record and its associated Data Sets into a single
        unique SCTP stream, ideally to limit the Template ID to a  
single
        stream, while imposing in-order transmission.
    

Introductory construct is a little unclear. Suggest replacement of  
this paragraph with:

This document specifies a method for exporting a Template Record and  
its associated Data Sets in a single SCTP stream, limiting each  
Template ID to a single stream if possible, and imposing in-order  
transmission.
That reads a lot better. Done.
  
        The specification in this document offers several advantages
        such as: calculation of Data Record losses in case of  
partially-
        reliable SCTP export, immediate export of the Template
        Withdrawal Message, immediate reuse of template ID within a
        stream, reduced likelihood of losing Data Record, and the
        Collecting Process's job is easier.
    

Text is not parallel; there are typographic errors here as well.  
Suggest replacement of this paragraph with:

This method offers several advantages over IPFIX export as specified  
in [RFC5101] such as the ability to calculate Data Record losses for  
PR-SCTP, immediate export of Template Withdrawal Messages, immediate  
reuse of Template IDs within an SCTP stream, reduced likelihood of  
Data Record loss, and reduced demands on the Collecting Process.
Good proposal. Done.
I've also updated the abstract to be in line with this paragraph.
       2.1. Relationship with IPFIX and PSAMP

        The specification in this document applies to the IPFIX
        protocol specifications [RFC5101].  However, it only applies
        to the SCTP transport protocol [RFC4960] option of the IPFIX
        protocol specifications, specifically in the case of the
        partial reliability extension [RFC3758].  All specifications
        from [RFC5101] apply unless specified otherwise in this
        document.

        As the Packet Sampling (PSAMP) protocol specifications
        [PSAMP-PROTO] are based on the IPFIX protocol specifications,
        the specifications in this document are also valid for the
        PSAMP protocol.  Therefore, the advantages specified by this
        document also apply to PSAMP.
    

The document specifies a method, not a set of advantages; suggest  
"Therefore, the method..."
Done.
     2.2. Applicability

        The specifications are required in cases where we must know  
how
        many Data Records of a certain type (i.e. from a certain
        Template ID) were lost.  Furthermore, they apply in cases  
where
        the Exporter can not afford to export all the Flow Records
        reliably, due to the limited resources to buffer the huge  
amount
        of flow records.  Such situations may occur if Data Sets are
        generated at a higher rate at the Exporter than can be
        transferred to the Collector because of bandwidth  
limitations in


     <Claise, et. Al>       Expires January 1, 2009           [Page 6]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        the network or slow reception at the Collector.  A typically
        example is a router exporting billing records.
    

typical example
Done.
  
        To be more precise, the specification applicability is the  
case
        where multiple Template IDs are sent within a SCTP Transport
        Session and the calculation of the Data Record loss for a
        particular one Template ID is required.  Indeed, with the
        current IPFIX specifications [RFC5101], if an IPFIX Message is
        lost (UDP or SCTP partially reliable), it is not possible to
        determine to which Template ID of the Transport Session the  
lost
        Data Records belong to.
    

Not in the general case, no. An EP can of course use only a single  
template for all export in a given session, or use a separate  
observation domain for each application. This is not the _only_ way  
under the current spec to estimate loss, it's just the most SCTP  
friendly, and the least hackish.
Understood. To stress the point, I changed "within a SCTP Transport Session" into "within a single SCTP Transport Session"
I also added the following sentence as a new paragraph at the end of the section 3.1.1 (I think it's more appropriate there): "Note that a workaround allowed by the IPFIX specifications [RFC5101] is to use only one Template per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template are required."

I propose not to mention the option of separate observation domain as this hack will certainly lead to some more confusion.

  
        In terms of Collector, there is backwards compatibility: the
        Collecting Process does not require any changes to support an
        Exporter that complies to the specifications in this document.
    

Suggest:

Exporting Processes following this specification will interoperate  
with existing Collecting Processes that comply with [RFC5101]; no  
changes are required at the Collecting Process to support this method.
Done.
  
     2.3. Limitations

        To be compliant with the specifications in this document, the
        Transport Session must support multiple SCTP streams.
        Furthermore, if the SCTP Transport Session does not support
        enough streams for the increasing number of Template ID in the
        Transport Session, the addition of streams must be supported
        according to [SCTP-RESET].  Alternatively, the new Template ID
        and associated Data Records may be added to an existing stream
        at the cost of diluting the granularity of Data Records loss.
        The other alternatives, which is not practical in operational
        networks, is to restart the SCTP association with an increase
        number of streams.
    

A few unclear and nonstandard constructs here, and a little  
terminology confusion. The discussion of alternatives to one-session- 
per-stream and SCTP reset is not a limitation of the approach, it's a  
workaround to limitations in certain SCTP stacks, and is a bit  
detailed for an introduction I think.  Suggest replacement:

This method requires multiple SCTP streams in the association between  
the Exporting and Collecting Process, ideally one per Template. The  
SCTP association should support the addition of streams according to  
[SCTP-RESET] in order to handle the transmission of additional  
Templates during the Transport Session.
Perfect.
  
     3. IPFIX Protocol Specifications Limitations and Improvements
    

I think this section needs some frontmatter explaining its  
organization. From the point of view of the TOC it makes sense, but  
reading the document through end to end it's a little disorienting.
New proposal

For three specific topics (Data Record Loss per Template, Transmission Order within a Stream, No Transmission Order across SCTP Streams), this section explains the IPFIX protocol specifications limitations on one hand, and the advantages of the method specified in this document on the other hand. 

  
     3.2.2. IPFIX Export per SCTP Stream Advantages

        By exporting each Template Record and the corresponding Data
        Records within a single stream and imposing in-order
        transmission, the Template will always arrive before the
        associated Data Records.  Therefore, there is no risk that
        the Collecting Process discards Data Records while waiting
        for the Template to arrive.

        Furthermore, when reusing a Template ID within a stream, the
        Template Withdrawal Message will be guaranteed to arrive
        before the new definition of the Template and therefore the
        Template Record may be sent directly after the Template
        Withdrawal Message.  In other words, the Template Reuse Delay
        restriction (by default, 5 seconds, as specified in [RFC5101]
        is removed for Template ID reuse within the same stream.

        Another advantage with the new specifications in this
        document is that the Collecting Process's job is now easier.
        Indeed, the Collecting Process doesn't have to store the Data
        Records while waiting for the Template Records, as the
        transmission order is always guaranteed.  This way, extra
        reliability of the Data Records is achieved without extra
        burden on the Collecting Process.
    

Prefer "reduces load on the CP" to "the CP's job is now easier"; the  
latter reads quite informally for a specification.
Done.
It might be nice if there were some way for a full-featured CP (i.e.  
one that supports buffering of Data Sets with missing Templates) to  
know whether it had to preallocate buffers for such a thing, but this  
is a very minor technical point.
Since we must have the backwards compatible with other RFC 5101 CPs, I'm not sure if this possible.
  
     3.3.2. IPFIX Export per SCTP Stream Advantages

        By exporting each Template Record and the corresponding Data
        Records within a single stream, imposing in-order
        transmission, and limiting the Template ID to a single
        stream, the issue of ordered transmission across multiple
        streams is avoided.

        By exporting all corresponding Data Records within the same
        ordered stream as the Template Definition, each stream is
        independent and self-contained and the interaction between
        streams is limited to that of Options Data interactions.  This
        has several advantageous consequences, including the order
        preservation that does not result in the blocking of unrelated
        data and the Collector's job simplification (as the Template
        Records are guaranteed to be delivered before the associated
        Data Records).
    

see previous comments about the "collector's job" language.
New text:
This has several advantageous consequences, including the order preservation that does not result in the blocking of unrelated data and load reduction on the Collecting Process (as the Template Records are guaranteed to be delivered before the associated Data Records, there is no need for buffering of Data Sets with missing Templates).
  
     4. Specifications

     4.1. Template Management

        This section introduces modifications compared to the Template
        Management section 8 in [RFC5101].


     <Claise, et. Al>       Expires January 1, 2009          [Page 10]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008



        As specified in [RFC5101], Template Sets and Options Template
        Sets MUST be sent reliably.  In other words, any IPFIX Message
        containing an (Options) Template Set MUST be sent reliably.
    

Verify that all 2119 keywords drawn from 5101 actually do restate the  
point properly; as I recall there was a bit of trouble over this with  
the implementation guidelines.
When I wrote "As specified in [RFC5101]", I always cut and pasted the exact sentence(s) from RFC5101.
If there is something specific to this draft, I would start a new paragraph

  
        Any Data Sets associated with a Template Record MUST be sent  
on
        the same stream on which the Template Record was sent.
    

The use of 2119 MUST language here implies a mandatory modification to  
5101. I know this is not the case given the document's intended  
status, but perhaps there should be some frontmatter in section four  
scoping the 2119 keywords within this section to implementations of  
the specification only.
Proposed new text in section 4

This section introduces improvements compared to the IPFIX specifications in [RFC5101].  These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119].


  
        The Exporter SHOULD send a single Template and associated Data
        Sets within a single stream in order to calculate the  
potential
        Data Record loss for this Template ID.
    

in order to _enable_ calculation (it's the collector doing the loss  
calculation, right, not the exporter?)
Done.
  
 However, the Exporter
        MAY group related Templates and their associated Data Sets
        within a single stream so loss statistics are calculated for  
the
        group.  This may be suitable in cases where there is
        insufficient SCTP streams to send each Template on its own
        stream and/or the case where there are slight variations on a
        single Template to show that some fields were unavailable at  
the
        time of monitoring.
    

This last sentence is kind of confusing. What I think you mean is:

This is suitable in cases where there are only slight variations among  
the templates in a group, e.g. the omission of unavailable fields for  
export efficiency, and may be necessary if the SCTP association does  
not support enough streams to export each Template in its own stream.
Nicely expressed. Done.
Hmm... Actually, I think the specification would be greatly improved  
by the formal introduction of a "template group" concept, and the  
rephrasing of the specification to cover the export of one template  
_group_ per stream. Since the omission of missing fields is not only  
common practice but recommended by the documents, you're often likely  
to get a set of related templates. Exporting these as a group is I  
think what you're really trying to do with this document, since it's  
application-granularity loss you're trying to estimate, yes?
Actually, we're saying: always export one template per SCTP stream, except in some circumstances:
- you don't care about the loss calculation
- you want to export within the same stream the option template record that will help the data record interpretation (example: sampling rate)
- you don't have enough SCTP stream. If this is the case, use "template group"

  
        If a SCTP stream contains a mixture of Data Records defined  
by a
        Template Record and Options Template Record(s), the Data  
Records
        defined by the Options Template Record(s) SHOULD be sent
        reliably within the same stream so that the Collector does not
        consider any loss to be associated with the Options Data.
        Indeed, if the Collector does not have the guarantee that the
        Data Records defined by the Options Template Record are sent
        reliably, the Collector can not determine whether the loss in
        that stream belongs to the Data Records defined by the  
Template
        Record, defined by the Option Template Record, or by both of
        them.  By sending the Options Data reliably (which is usually
        required to interpret the Data Records correctly), any loss  
will
        be limited to the non-option Data Record and loss can still be
        calculated on a per Template basis.

        For each (Options) Template Record, the Exporting Process MUST
        send the Data Record Reliability Option Template using an  
Option
        Template with the following Information Elements:

         SCOPE:     Template ID
         NOT-SCOPE: dataRecordsReliability

        The Data Record Reliability Option Template MUST be sent
        reliably.

    

It's a template, so it must be sent reliably. This is redundant.
Yes. I removed it.
Or do  
you mean the record described by this template?

More seriously, I don't see the point of this Option. Can't the CP  
just deduce from the EP's actions whether it's sending the data for a  
given template reliably or not?
How?
Isn't it a layer violation if the Exporter looks in the SCTP transport to determine the reliability level?
Also, just because the Exporter sent some records reliably there is not a guaranteed indication of future intent, or more specifically an
indication that any lost records won't be associated with this Template ID. 
Also, what additional functionality  
does the CP really gain by deducing this? Doesn't all the stream loss  
estimation stuff still work (well, on a per-group basis, anyway)?
If you're sending with the same SCTP stream, a mix of:
    flows record with sampled data and sampler ID
    option template describing the sampling rate asssociated with a specifier sampler ID
If  the CP sees a gap in the sequence number, and the CP doesn't know that the option data records (for a lack a better term) are sent reliably, what should be the CP deduce?
    1. I lost a flow record -> this is pretty bad from an accuracy point of view
    OR
    2. I lost an option data record -> I can't fully interpret my data.
This mechanism will help the CP to say that the loss comes only from data record, because the option data record were sent reliably.
I understand that this is a different "group" that what you described above, as in this case the group contains data records and associated option data records. Really the options data is considered information that supports the interpretation of the group data, but isn't part of the group. 

  
     <Claise, et. Al>       Expires January 1, 2009          [Page 11]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        The Option Data Record SHOULD be sent before the Data Record
        that needs it so that it arrives first and is available for  
the
        Collector to use.
    

And I presume it should also be sent reliably?
Yes, added.
Note: the "Option Data Record" doesn't exist.
New text:

The Data Record defined by the Data Record Reliability Option Template SHOULD be sent, reliably, before the Data Record that needs it so that it arrives first and is available for the Collector to use.

In some other instances of "Option Data Record", I changed the draft to use option Data Record 
  
     4.2. New Information Element

        dataRecordsReliability

           Description:
                The Data Records reliability associated with this
                Template ID.  The integer value 1 means that the Data
                Records are sent reliably, while the integer value 2
                means that the Data Records are not sent reliably.
           Abstract Data Type: boolean
           Data Type Semantics: identifier
           ElementId: xxx
           Status: current
    

Inconsistent. Is it an integer, or a boolean?
>From RFC5101
6.1.5.  boolean


   The boolean data type is specified according to the TruthValue in
   [RFC2579]: it is an integer with the value 1 for true and a value 2
   for false.  Every other value is undefined.  The boolean data type
   MUST be encoded in a single octet.
However, you're right, let's not confuse the information model with the encoding rule
New proposed text:
Description:
                The Data Records reliability associated with this
                Template ID.  The true value means that the Data
                Records are sent reliably, while the false value
                means that the Data Records are not sent reliably.

  
     4.3. SCTP

        This section introduces modifications compared to the "SCTP"
        section 10.2 (and subsections) in [RFC5101].  More  
specifically
        the "Stream" section 10.2.4.3
    

See above about 2119 language and intended status. This frontmatter  
clearly reads as if it supercedes or updates 5101, which is not the  
case.
This section introduces some more specific specifications compared to the "SCTP" section 10.2 (and subsections) in [RFC5101].  
  
        PR-SCTP [RFC3758] MUST be implemented by all compliant
        implementations.

        All IPFIX Messages MUST be sent in order within a stream.

        Depending on the application requirement, the Exporting  
Process
        MAY send Data Sets with full or partial reliability.   
Unreliable
        data transfer MAY be used where the application does not  
require
        reliable transmission or the use of a retransmission queue is
        impractical due to resource restrictions at the Exporter.


        If the Exporting Process requires to export a new Template but
        there are no more free SCTP streams available, it SHOULD  
attempt
        to increase the number of outbound streams it is able to send
        to, per [SCTP-RESET].  Alternatively, the Exporting Process  
MAY
        add the Template Set and Data Records to an existing stream at
        the cost of diluting the granularity of Data Records loss.





     <Claise, et. Al>       Expires January 1, 2009          [Page 12]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


     4.4. Template Withdrawal Message

        This section introduces Template Withdrawal Message-related
        modifications compared to the Template Management section 8 in
        [RFC5101].
    

As above.

  
        Templates that are not used anymore SHOULD be deleted.  Before
        reusing a Template ID, the Template MUST be deleted.  In order
        to delete an allocated Template, the Template is withdrawn
        through the use of a Template Withdrawal Message.  The  
Template
        Withdrawal Message MUST be sent on the same stream as the
        Template Record.
    

Inconsistent terminology. Template deletion == withdrawal?
The first two sentences are cut and pasted from RFC5101.
I added "as specified in [RFC5101] in front of them
  
        As the Template Withdrawal Message MUST be sent reliably,  
using
        SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
        are sent in order within a stream (per the specifications in
        this document), the IPFIX Message containing the Template
        Withdrawal Message will not arrive at the Collecting Process
        before any associated and previously sent Data Record.  As a
        consequence, no Data Records will be lost due to delayed  
arrival
        at the Collector.

        The Template ID from a withdrawn Template MAY be reused on the
        same stream immediately after the Template Withdrawal  
Message is
        sent.  This case is equivalent to the use of a Template Reuse
        Delay value of 0.

        If the new definition of the Template ID is to be reused on a
        different stream, the Template Withdrawal Message MUST NOT be
        sent before the Template Reuse Delay.

        A Template Withdrawal Message to withdraw all Templates for  
the
        Observation Domain ID specified in the IPFIX Message header  
MUST
        NOT be used.

        Multiple Template IDs MAY be withdrawn with a single Template
        Withdrawal Message at the condition that all the Template  
IDs in
        the Template Withdrawal Message are used on the same SCTP
        stream.


     4.5. The Collecting Process's Side

        This section introduces modifications to the Collection  
Process
        as compared to section 9 in [RFC5101].
    

Modification of Collecting Process behavior is in conflict with the  
statement in the introduction that EPs using this spec interoperate  
with 5101 CPs. Which is it?
New proposal.

This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101].  However, the new specifications are backwards compatible with RFC5101-compliant Collecting Processes.


  
     <Claise, et. Al>       Expires January 1, 2009          [Page 13]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        The Collecting Process SHOULD listen for a new association
        request from the Exporting Process.  The Exporting Process  
will
        request a number of streams to use for export: the number of
        streams SHOULD be equivalent to the number of simultaneous
        Template Records used in the association. Note that the  
Template
        Records don't include the Options Template Records.
    

This statement does not modify 5101 CP behavior and is superfluous.
It might not be obvious for new comers. So we thought about adding that. Anyway, removed.
  
        A Collecting Process SHOULD support the procedure for the
        addition of an SCTP stream [SCTP-RESET].

        The IPFIX protocol has a Sequence Number field in the IPFIX
        Message header that increases with the number of IPFIX Data
        Records in the IPFIX Message.  A Collector may detect out-of-
        sequence, dropped, or duplicate IPFIX Messages by tracking the
        Sequence Number.  As this Sequence Number is per SCTP stream,
        the loss for the Data Records sent in that stream can be
        calculated in case of partially-reliable export.
    

A recommendation for how to do this calculation would be nice here.
New proposal

  When one or more IPFIX Messages are considered lost, the number of lost
  Data Records is equal to the Sequence Number of the first IPFIX Message Header
  following the lost packets (S2) minus the Sequence Number of the
  first lost IPFIX Message (S1).  The Sequence Number of the first lost
  IPFIX Message can be calculated as the Sequence Number of the last
  IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the number
  of Data Records in that IPFIX Message (N0).

    S1   = S0 + N0
    loss = S2 - S1 = S2 - (S0 + N0) 
  
        If the Collecting Process receives a Template Withdrawal  
Message
        on a different stream than the one on which the Template ID is
        used, then the Collecting Process MUST reset the association  
and
        SHOULD log an error message.
    

This is not possible without superceding 5101 and breaking  
interoperability with stock 5101 EPs. Therefore it must be removed.
Good catch.
New text:

 

If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message.

Furthermore (though I know we do it all over the protocol), CP- 
initiated Transport Session shutdown does not follow the general  
protocol design rule of "be conservative in what you send and liberal  
in what you accept". Adding a new condition where we do this would be  
less than ideal. But I accept that I lost this fight a while ago. :)
Actually we have heard some very good arguments against Postel’s robustness
principle. In 2001 Marshall Rose wrote:

    Counter-intuitively, Postel’s robustness principle (“be conservative
    in what you send, liberal in what you accept”) often leads to
    deployment problems. Why? When a new implementation is initially
    fielded, it is likely that it will encounter only a subset of existing
    implementations. If those implementations follow the robustness
    principle, then errors in the new implementation will likely go
    undetected. The new implementation then sees some, but not widespread
    deployment. This process repeats for several new implementations.
    Eventually, the not-quite-correct implementations run into other
    implementations that are less liberal than the initial set of
    implementations. The reader should be able to figure out what happens
    next. 
  
        The following sentences from [RFC5101] are not applicable in
        this specification:

           "The Collecting Process normally receives Template Records
           from the Exporting Process before receiving Data Records.
           The Data Records are then decoded and stored by the
           Collector.  If the Template Records have not been  
received at
           the time Data Records are received, the Collecting Process
           MAY store the Data Records for a short period of time and
           decode them after the Template Records are received."
    

No need to remove this. CPs may still support buffering of template- 
less Data even if the EP doesn't require them to.
Sentences removed.

Regards, Benoit.
Regards,

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

--------------010003000207020803040704-- --===============1144050565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1144050565==-- From ipfix-bounces@ietf.org Thu Oct 16 03:51:21 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4813A3A6906; Thu, 16 Oct 2008 03:51:21 -0700 (PDT) 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 8101C3A657C for ; Thu, 16 Oct 2008 03:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EPM4JiPfqlSu for ; Thu, 16 Oct 2008 03:50:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 5915C3A6906 for ; Thu, 16 Oct 2008 03:50:47 -0700 (PDT) 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 m9GApbg15768; Thu, 16 Oct 2008 12:51:38 +0200 (CEST) Received: from [10.61.93.146] (ams3-vpn-dhcp7571.cisco.com [10.61.93.146]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9GApZG15739; Thu, 16 Oct 2008 12:51:35 +0200 (CEST) Message-ID: <48F71CB7.706@cisco.com> Date: Thu, 16 Oct 2008 12:51:35 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Brian Trammell References: <3B2C1602-5624-4428-A706-5CFF6C3DDE52@tik.ee.ethz.ch> In-Reply-To: <3B2C1602-5624-4428-A706-5CFF6C3DDE52@tik.ee.ethz.ch> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] SCTP per-stream WGLC 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: , Content-Type: multipart/mixed; boundary="===============1144050565==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1144050565== Content-Type: multipart/alternative; boundary="------------010003000207020803040704" This is a multi-part message in MIME format. --------------010003000207020803040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Many thanks! Not only you got some good points, but you even proposed some new text. This is the perfect review. See inline. > All, > > The following is a review of the SCTP perstream draft for WGLC. > > Serious issues (repeated inline): > > It is not clear in the language of the document that it is not > intended to update 5101, though its intended status precludes this. > At the beginning of section 4, there is this proposed text: This section introduces improvements compared to the IPFIX specifications in [RFC5101]. These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119 ]. > Additionally, there are some specifications with respect to Collecting > Processes which may break interoperability. > > The Data Record Reliability Options Template does not appear to be > necessary, or at least, its purpose is unclear. As I read it the CP > can deduce all the information it provides rather easily. > > General comments: > > I have not consistently corrected the grammar in the document where it > does not have a significant impact on clarity (e.g. spurious > articles), though the document does need a grammar and typographic > editing pass between now and final publication. > Surely one of the native English speakers in the author list will do a final check > There is one general terminology issue which should be addressed; it > appears that throughout the document the phrase "Template ID" is used > to mean "number identifying a Template" as well as "Data Records (or > Data Sets) described by (or associated with) a Template". I agree this > latter construct is really awkward, but "Template ID" is a confusing > shorthand for the concept, and suggest finding a replacement and using > it consistently. > I reviewed all "template" instances in the document, and I agree with your statement. I changed a few sentences. > >> 1. Terminology >> >> IPFIX-specific terminology used in this document is defined >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- >> specific terms have the first letter of a word capitalized >> when used in this document. >> >> Template Reuse Delay >> >> The configurable timeout to allow the Collecting Process >> to receive and process the last Data Record using this >> Template information before which the Template Withdrawal >> Message MUST NOT be sent. [RFC5101] specifies a default >> value of 5 seconds. >> > > The wording here is confusing. I don't know what a Template Reuse > Delay is from this text. Is this correct: > > "The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template." > This is a better wording, you're right. Alternatively, I can simply cut and paste the sentence from RFC5101 According to the IPFIX specifications [RFC5101], the Template Withdrawal Message MUST NOT be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This configurable time is called the Template Reuse Delay. [RFC5101] specifies a default value of 5 seconds. Which one do you prefer? > It's not a CP delay, or is it? I'm confused as to what configurability > at the CP has to do with it. > > >> 2. Introduction >> >> The IPFIX working group has specified a protocol to export IP >> Flow information [RFC5101]. This protocol is designed to >> export information about IP traffic Flows and related >> measurement data, where a Flow is defined by a set of key >> attributes (e.g. source and destination IP address, source >> and destination port, etc.). However, thanks to its template >> mechanism, the IPFIX protocol can export any type of >> information, as long as the relevant Information Element is >> specified in the IPFIX Information Model [RFC5102], >> registered with IANA, or specified as an enterprise-specific >> Information Element. >> >> The IPFIX protocol [RFC5101] specifies that IP traffic >> measurements for Flows are exported using a TLV (type, >> length, value) format. The information is exported using a >> Template Record that is sent once to export the {type, >> length} pairs that define the data format for the Information >> Elements in a Flow. The Data Records specify values for each >> Flow. >> >> The IPFIX protocol [RFC5101] is flexible: it foresees the >> usage >> of the multiple SCTP streams per association; it allows the >> transmission of Data Sets, Template Sets, and/or Options >> Template Sets on any stream; it offers the full or partial >> reliability export of Data Sets; it proposes the ordered or >> out- >> of-order delivery of Data Sets. However, due to bandwidth >> >> >> Expires January 1, 2009 [Page 5] >> >> Internet-Draft July >> 2008 >> >> >> restrictions and packet losses in the network as well as >> resource constraints on the Exporter and Collector (e.g., >> limited buffer sizes), it is not always possible to export all >> Data Sets in a reliable way. >> >> > > I'm going to make a few stylistic suggestions here in the > introduction, because the introduction, I think, needs to be very > clear as to what the document is, and it reads a little awkwardly to > me as it stands. > > >> Without delving into the details of the specifications >> described >> later on in this document, the basic idea is to export the >> Template Record and its associated Data Sets into a single >> unique SCTP stream, ideally to limit the Template ID to a >> single >> stream, while imposing in-order transmission. >> > > Introductory construct is a little unclear. Suggest replacement of > this paragraph with: > > This document specifies a method for exporting a Template Record and > its associated Data Sets in a single SCTP stream, limiting each > Template ID to a single stream if possible, and imposing in-order > transmission. > That reads a lot better. Done. > >> The specification in this document offers several advantages >> such as: calculation of Data Record losses in case of >> partially- >> reliable SCTP export, immediate export of the Template >> Withdrawal Message, immediate reuse of template ID within a >> stream, reduced likelihood of losing Data Record, and the >> Collecting Process's job is easier. >> > > Text is not parallel; there are typographic errors here as well. > Suggest replacement of this paragraph with: > > This method offers several advantages over IPFIX export as specified > in [RFC5101] such as the ability to calculate Data Record losses for > PR-SCTP, immediate export of Template Withdrawal Messages, immediate > reuse of Template IDs within an SCTP stream, reduced likelihood of > Data Record loss, and reduced demands on the Collecting Process. > > Good proposal. Done. I've also updated the abstract to be in line with this paragraph. >> 2.1. Relationship with IPFIX and PSAMP >> >> The specification in this document applies to the IPFIX >> protocol specifications [RFC5101]. However, it only applies >> to the SCTP transport protocol [RFC4960] option of the IPFIX >> protocol specifications, specifically in the case of the >> partial reliability extension [RFC3758]. All specifications >> from [RFC5101] apply unless specified otherwise in this >> document. >> >> As the Packet Sampling (PSAMP) protocol specifications >> [PSAMP-PROTO] are based on the IPFIX protocol specifications, >> the specifications in this document are also valid for the >> PSAMP protocol. Therefore, the advantages specified by this >> document also apply to PSAMP. >> > > The document specifies a method, not a set of advantages; suggest > "Therefore, the method..." > Done. >> 2.2. Applicability >> >> The specifications are required in cases where we must know >> how >> many Data Records of a certain type (i.e. from a certain >> Template ID) were lost. Furthermore, they apply in cases >> where >> the Exporter can not afford to export all the Flow Records >> reliably, due to the limited resources to buffer the huge >> amount >> of flow records. Such situations may occur if Data Sets are >> generated at a higher rate at the Exporter than can be >> transferred to the Collector because of bandwidth >> limitations in >> >> >> Expires January 1, 2009 [Page 6] >> >> Internet-Draft July >> 2008 >> >> >> the network or slow reception at the Collector. A typically >> example is a router exporting billing records. >> > > typical example > Done. > >> To be more precise, the specification applicability is the >> case >> where multiple Template IDs are sent within a SCTP Transport >> Session and the calculation of the Data Record loss for a >> particular one Template ID is required. Indeed, with the >> current IPFIX specifications [RFC5101], if an IPFIX Message is >> lost (UDP or SCTP partially reliable), it is not possible to >> determine to which Template ID of the Transport Session the >> lost >> Data Records belong to. >> > > Not in the general case, no. An EP can of course use only a single > template for all export in a given session, or use a separate > observation domain for each application. This is not the _only_ way > under the current spec to estimate loss, it's just the most SCTP > friendly, and the least hackish. > Understood. To stress the point, I changed "within a SCTP Transport Session" into "within a _single _SCTP Transport Session" I also added the following sentence as a new paragraph at the end of the section 3.1.1 (I think it's more appropriate there): "Note that a workaround allowed by the IPFIX specifications [RFC5101] is to use only one Template per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template are required." I propose not to mention the option of separate observation domain as this hack will certainly lead to some more confusion. > >> In terms of Collector, there is backwards compatibility: the >> Collecting Process does not require any changes to support an >> Exporter that complies to the specifications in this document. >> > > Suggest: > > Exporting Processes following this specification will interoperate > with existing Collecting Processes that comply with [RFC5101]; no > changes are required at the Collecting Process to support this method. > Done. > >> 2.3. Limitations >> >> To be compliant with the specifications in this document, the >> Transport Session must support multiple SCTP streams. >> Furthermore, if the SCTP Transport Session does not support >> enough streams for the increasing number of Template ID in the >> Transport Session, the addition of streams must be supported >> according to [SCTP-RESET]. Alternatively, the new Template ID >> and associated Data Records may be added to an existing stream >> at the cost of diluting the granularity of Data Records loss. >> The other alternatives, which is not practical in operational >> networks, is to restart the SCTP association with an increase >> number of streams. >> > > A few unclear and nonstandard constructs here, and a little > terminology confusion. The discussion of alternatives to one-session- > per-stream and SCTP reset is not a limitation of the approach, it's a > workaround to limitations in certain SCTP stacks, and is a bit > detailed for an introduction I think. Suggest replacement: > > This method requires multiple SCTP streams in the association between > the Exporting and Collecting Process, ideally one per Template. The > SCTP association should support the addition of streams according to > [SCTP-RESET] in order to handle the transmission of additional > Templates during the Transport Session. > Perfect. > >> 3. IPFIX Protocol Specifications Limitations and Improvements >> > > I think this section needs some frontmatter explaining its > organization. From the point of view of the TOC it makes sense, but > reading the document through end to end it's a little disorienting. > New proposal For three specific topics (Data Record Loss per Template, Transmission Order within a Stream, No Transmission Order across SCTP Streams), this section explains the IPFIX protocol specifications limitations on one hand, and the advantages of the method specified in this document on the other hand. > >> 3.2.2. IPFIX Export per SCTP Stream Advantages >> >> By exporting each Template Record and the corresponding Data >> Records within a single stream and imposing in-order >> transmission, the Template will always arrive before the >> associated Data Records. Therefore, there is no risk that >> the Collecting Process discards Data Records while waiting >> for the Template to arrive. >> >> Furthermore, when reusing a Template ID within a stream, the >> Template Withdrawal Message will be guaranteed to arrive >> before the new definition of the Template and therefore the >> Template Record may be sent directly after the Template >> Withdrawal Message. In other words, the Template Reuse Delay >> restriction (by default, 5 seconds, as specified in [RFC5101] >> is removed for Template ID reuse within the same stream. >> >> Another advantage with the new specifications in this >> document is that the Collecting Process's job is now easier. >> Indeed, the Collecting Process doesn't have to store the Data >> Records while waiting for the Template Records, as the >> transmission order is always guaranteed. This way, extra >> reliability of the Data Records is achieved without extra >> burden on the Collecting Process. >> > > Prefer "reduces load on the CP" to "the CP's job is now easier"; the > latter reads quite informally for a specification. > Done. > It might be nice if there were some way for a full-featured CP (i.e. > one that supports buffering of Data Sets with missing Templates) to > know whether it had to preallocate buffers for such a thing, but this > is a very minor technical point. > Since we must have the backwards compatible with other RFC 5101 CPs, I'm not sure if this possible. > >> 3.3.2. IPFIX Export per SCTP Stream Advantages >> >> By exporting each Template Record and the corresponding Data >> Records within a single stream, imposing in-order >> transmission, and limiting the Template ID to a single >> stream, the issue of ordered transmission across multiple >> streams is avoided. >> >> By exporting all corresponding Data Records within the same >> ordered stream as the Template Definition, each stream is >> independent and self-contained and the interaction between >> streams is limited to that of Options Data interactions. This >> has several advantageous consequences, including the order >> preservation that does not result in the blocking of unrelated >> data and the Collector's job simplification (as the Template >> Records are guaranteed to be delivered before the associated >> Data Records). >> > > see previous comments about the "collector's job" language. > New text: This has several advantageous consequences, including the order preservation that does not result in the blocking of unrelated data and load reduction on the Collecting Process (as the Template Records are guaranteed to be delivered before the associated Data Records, there is no need for buffering of Data Sets with missing Templates). > >> 4. Specifications >> >> 4.1. Template Management >> >> This section introduces modifications compared to the Template >> Management section 8 in [RFC5101]. >> >> >> Expires January 1, 2009 [Page 10] >> >> Internet-Draft July >> 2008 >> >> >> >> As specified in [RFC5101], Template Sets and Options Template >> Sets MUST be sent reliably. In other words, any IPFIX Message >> containing an (Options) Template Set MUST be sent reliably. >> > > Verify that all 2119 keywords drawn from 5101 actually do restate the > point properly; as I recall there was a bit of trouble over this with > the implementation guidelines. > When I wrote "As specified in [RFC5101]", I always cut and pasted the exact sentence(s) from RFC5101. If there is something specific to this draft, I would start a new paragraph > >> Any Data Sets associated with a Template Record MUST be sent >> on >> the same stream on which the Template Record was sent. >> > > The use of 2119 MUST language here implies a mandatory modification to > 5101. I know this is not the case given the document's intended > status, but perhaps there should be some frontmatter in section four > scoping the 2119 keywords within this section to implementations of > the specification only. > Proposed new text in section 4 This section introduces improvements compared to the IPFIX specifications in [RFC5101]. These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119 ]. > >> The Exporter SHOULD send a single Template and associated Data >> Sets within a single stream in order to calculate the >> potential >> Data Record loss for this Template ID. >> > > in order to _enable_ calculation (it's the collector doing the loss > calculation, right, not the exporter?) > Done. > >> However, the Exporter >> MAY group related Templates and their associated Data Sets >> within a single stream so loss statistics are calculated for >> the >> group. This may be suitable in cases where there is >> insufficient SCTP streams to send each Template on its own >> stream and/or the case where there are slight variations on a >> single Template to show that some fields were unavailable at >> the >> time of monitoring. >> > > This last sentence is kind of confusing. What I think you mean is: > > This is suitable in cases where there are only slight variations among > the templates in a group, e.g. the omission of unavailable fields for > export efficiency, and may be necessary if the SCTP association does > not support enough streams to export each Template in its own stream. > Nicely expressed. Done. > Hmm... Actually, I think the specification would be greatly improved > by the formal introduction of a "template group" concept, and the > rephrasing of the specification to cover the export of one template > _group_ per stream. Since the omission of missing fields is not only > common practice but recommended by the documents, you're often likely > to get a set of related templates. Exporting these as a group is I > think what you're really trying to do with this document, since it's > application-granularity loss you're trying to estimate, yes? > Actually, we're saying: _always _export one template per SCTP stream, except in some circumstances: - you don't care about the loss calculation - you want to export within the same stream the option template record that will help the data record interpretation (example: sampling rate) - you don't have enough SCTP stream. If this is the case, use "template group" > >> If a SCTP stream contains a mixture of Data Records defined >> by a >> Template Record and Options Template Record(s), the Data >> Records >> defined by the Options Template Record(s) SHOULD be sent >> reliably within the same stream so that the Collector does not >> consider any loss to be associated with the Options Data. >> Indeed, if the Collector does not have the guarantee that the >> Data Records defined by the Options Template Record are sent >> reliably, the Collector can not determine whether the loss in >> that stream belongs to the Data Records defined by the >> Template >> Record, defined by the Option Template Record, or by both of >> them. By sending the Options Data reliably (which is usually >> required to interpret the Data Records correctly), any loss >> will >> be limited to the non-option Data Record and loss can still be >> calculated on a per Template basis. >> >> For each (Options) Template Record, the Exporting Process MUST >> send the Data Record Reliability Option Template using an >> Option >> Template with the following Information Elements: >> >> SCOPE: Template ID >> NOT-SCOPE: dataRecordsReliability >> >> The Data Record Reliability Option Template MUST be sent >> reliably. >> >> > > It's a template, so it must be sent reliably. This is redundant. Yes. I removed it. > Or do > you mean the record described by this template? > > More seriously, I don't see the point of this Option. Can't the CP > just deduce from the EP's actions whether it's sending the data for a > given template reliably or not? How? Isn't it a layer violation if the Exporter looks in the SCTP transport to determine the reliability level? Also, just because the Exporter sent some records reliably there is not a guaranteed indication of future intent, or more specifically an indication that any lost records won't be associated with this Template ID. > Also, what additional functionality > does the CP really gain by deducing this? Doesn't all the stream loss > estimation stuff still work (well, on a per-group basis, anyway)? > If you're sending with the same SCTP stream, a mix of: flows record with sampled data and sampler ID option template describing the sampling rate asssociated with a specifier sampler ID If the CP sees a gap in the sequence number, and the CP doesn't know that the option data records (for a lack a better term) are sent reliably, what should be the CP deduce? 1. I lost a flow record -> this is pretty bad from an accuracy point of view OR 2. I lost an option data record -> I can't fully interpret my data. This mechanism will help the CP to say that the loss comes only from data record, because the option data record were sent reliably. I understand that this is a different "group" that what you described above, as in this case the group contains data records and associated option data records. Really the options data is considered information that supports the interpretation of the group data, but isn't part of the group. > >> Expires January 1, 2009 [Page 11] >> >> Internet-Draft July >> 2008 >> >> >> The Option Data Record SHOULD be sent before the Data Record >> that needs it so that it arrives first and is available for >> the >> Collector to use. >> > > And I presume it should also be sent reliably? > Yes, added. Note: the "Option Data Record" doesn't exist. New text: The Data Record defined by the Data Record Reliability Option Template SHOULD be sent, reliably, before the Data Record that needs it so that it arrives first and is available for the Collector to use. In some other instances of "Option Data Record", I changed the draft to use _o_ption Data Record > >> 4.2. New Information Element >> >> dataRecordsReliability >> >> Description: >> The Data Records reliability associated with this >> Template ID. The integer value 1 means that the Data >> Records are sent reliably, while the integer value 2 >> means that the Data Records are not sent reliably. >> Abstract Data Type: boolean >> Data Type Semantics: identifier >> ElementId: xxx >> Status: current >> > > Inconsistent. Is it an integer, or a boolean? > >From RFC5101 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579 ]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet. However, you're right, let's not confuse the information model with the encoding rule New proposed text: Description: The Data Records reliability associated with this Template ID. The true value means that the Data Records are sent reliably, while the false value means that the Data Records are not sent reliably. > >> 4.3. SCTP >> >> This section introduces modifications compared to the "SCTP" >> section 10.2 (and subsections) in [RFC5101]. More >> specifically >> the "Stream" section 10.2.4.3 >> > > See above about 2119 language and intended status. This frontmatter > clearly reads as if it supercedes or updates 5101, which is not the > case. > This section introduces some more specific specifications compared to the "SCTP" section 10.2 (and subsections) in [RFC5101]. > >> PR-SCTP [RFC3758] MUST be implemented by all compliant >> implementations. >> >> All IPFIX Messages MUST be sent in order within a stream. >> >> Depending on the application requirement, the Exporting >> Process >> MAY send Data Sets with full or partial reliability. >> Unreliable >> data transfer MAY be used where the application does not >> require >> reliable transmission or the use of a retransmission queue is >> impractical due to resource restrictions at the Exporter. >> >> >> If the Exporting Process requires to export a new Template but >> there are no more free SCTP streams available, it SHOULD >> attempt >> to increase the number of outbound streams it is able to send >> to, per [SCTP-RESET]. Alternatively, the Exporting Process >> MAY >> add the Template Set and Data Records to an existing stream at >> the cost of diluting the granularity of Data Records loss. >> >> >> >> >> >> Expires January 1, 2009 [Page 12] >> >> Internet-Draft July >> 2008 >> >> >> 4.4. Template Withdrawal Message >> >> This section introduces Template Withdrawal Message-related >> modifications compared to the Template Management section 8 in >> [RFC5101]. >> > > As above. > > >> Templates that are not used anymore SHOULD be deleted. Before >> reusing a Template ID, the Template MUST be deleted. In order >> to delete an allocated Template, the Template is withdrawn >> through the use of a Template Withdrawal Message. The >> Template >> Withdrawal Message MUST be sent on the same stream as the >> Template Record. >> > > Inconsistent terminology. Template deletion == withdrawal? > > The first two sentences are cut and pasted from RFC5101. I added "as specified in [RFC5101] in front of them > >> As the Template Withdrawal Message MUST be sent reliably, >> using >> SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages >> are sent in order within a stream (per the specifications in >> this document), the IPFIX Message containing the Template >> Withdrawal Message will not arrive at the Collecting Process >> before any associated and previously sent Data Record. As a >> consequence, no Data Records will be lost due to delayed >> arrival >> at the Collector. >> >> The Template ID from a withdrawn Template MAY be reused on the >> same stream immediately after the Template Withdrawal >> Message is >> sent. This case is equivalent to the use of a Template Reuse >> Delay value of 0. >> >> If the new definition of the Template ID is to be reused on a >> different stream, the Template Withdrawal Message MUST NOT be >> sent before the Template Reuse Delay. >> >> A Template Withdrawal Message to withdraw all Templates for >> the >> Observation Domain ID specified in the IPFIX Message header >> MUST >> NOT be used. >> >> Multiple Template IDs MAY be withdrawn with a single Template >> Withdrawal Message at the condition that all the Template >> IDs in >> the Template Withdrawal Message are used on the same SCTP >> stream. >> >> >> 4.5. The Collecting Process's Side >> >> This section introduces modifications to the Collection >> Process >> as compared to section 9 in [RFC5101]. >> > > Modification of Collecting Process behavior is in conflict with the > statement in the introduction that EPs using this spec interoperate > with 5101 CPs. Which is it? > New proposal. This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101]. However, the new specifications are backwards compatible with RFC5101-compliant Collecting Processes. > >> Expires January 1, 2009 [Page 13] >> >> Internet-Draft July >> 2008 >> >> >> The Collecting Process SHOULD listen for a new association >> request from the Exporting Process. The Exporting Process >> will >> request a number of streams to use for export: the number of >> streams SHOULD be equivalent to the number of simultaneous >> Template Records used in the association. Note that the >> Template >> Records don't include the Options Template Records. >> > > This statement does not modify 5101 CP behavior and is superfluous. > It might not be obvious for new comers. So we thought about adding that. Anyway, removed. > >> A Collecting Process SHOULD support the procedure for the >> addition of an SCTP stream [SCTP-RESET]. >> >> The IPFIX protocol has a Sequence Number field in the IPFIX >> Message header that increases with the number of IPFIX Data >> Records in the IPFIX Message. A Collector may detect out-of- >> sequence, dropped, or duplicate IPFIX Messages by tracking the >> Sequence Number. As this Sequence Number is per SCTP stream, >> the loss for the Data Records sent in that stream can be >> calculated in case of partially-reliable export. >> > > A recommendation for how to do this calculation would be nice here. > New proposal When one or more IPFIX Messages are considered lost, the number of lost Data Records is equal to the Sequence Number of the first IPFIX Message Header following the lost packets (S2) minus the Sequence Number of the first lost IPFIX Message (S1). The Sequence Number of the first lost IPFIX Message can be calculated as the Sequence Number of the last IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the number of Data Records in that IPFIX Message (N0). S1 = S0 + N0 loss = S2 - S1 = S2 - (S0 + N0) > >> If the Collecting Process receives a Template Withdrawal >> Message >> on a different stream than the one on which the Template ID is >> used, then the Collecting Process MUST reset the association >> and >> SHOULD log an error message. >> > > This is not possible without superceding 5101 and breaking > interoperability with stock 5101 EPs. Therefore it must be removed. > Good catch. New text: If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message. > Furthermore (though I know we do it all over the protocol), CP- > initiated Transport Session shutdown does not follow the general > protocol design rule of "be conservative in what you send and liberal > in what you accept". Adding a new condition where we do this would be > less than ideal. But I accept that I lost this fight a while ago. :) > Actually we have heard some very good arguments against Postel's robustness principle. In 2001 Marshall Rose wrote: Counter-intuitively, Postel's robustness principle ("be conservative in what you send, liberal in what you accept") often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next. > >> The following sentences from [RFC5101] are not applicable in >> this specification: >> >> "The Collecting Process normally receives Template Records >> from the Exporting Process before receiving Data Records. >> The Data Records are then decoded and stored by the >> Collector. If the Template Records have not been >> received at >> the time Data Records are received, the Collecting Process >> MAY store the Data Records for a short period of time and >> decode them after the Template Records are received." >> > > No need to remove this. CPs may still support buffering of template- > less Data even if the EP doesn't require them to. > Sentences removed. Regards, Benoit. > Regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------010003000207020803040704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Many thanks! Not only you got some good points, but you even proposed some new text. This is the perfect review.
See inline.
All,

The following is a review of the SCTP perstream draft for WGLC.

Serious issues (repeated inline):

It is not clear in the language of the document that it is not  
intended to update 5101, though its intended status precludes this.
At the beginning of section 4, there is this proposed text:

This section introduces improvements compared to the IPFIX specifications in [RFC5101].  These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119].


Additionally, there are some specifications with respect to Collecting  
Processes which may break interoperability.

The Data Record Reliability Options Template does not appear to be  
necessary, or at least, its purpose is unclear. As I read it the CP  
can deduce all the information it provides rather easily.

General comments:

I have not consistently corrected the grammar in the document where it  
does not have a significant impact on clarity (e.g. spurious  
articles), though the document does need a grammar and typographic  
editing pass between now and final publication.
Surely one of the native English speakers in the author list will do a final check

There is one general terminology issue which should be addressed; it  
appears that throughout the document the phrase "Template ID" is used  
to mean "number identifying a Template" as well as "Data Records (or  
Data Sets) described by (or associated with) a Template". I agree this  
latter construct is really awkward, but "Template ID" is a confusing  
shorthand for the concept, and suggest finding a replacement and using  
it consistently.
I reviewed all "template" instances in the document, and I agree with your statement.
I changed a few sentences.
 
  
 1. Terminology

        IPFIX-specific terminology used in this document is defined
        in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
        specific terms have the first letter of a word capitalized
        when used in this document.

        Template Reuse Delay

           The configurable timeout to allow the Collecting Process
           to receive and process the last Data Record using this
           Template information before which the Template Withdrawal
           Message MUST NOT be sent.  [RFC5101] specifies a default
           value of 5 seconds.
    

The wording here is confusing. I don't know what a Template Reuse  
Delay is from this text. Is this correct:

"The time after sending the last Data Set described by a given  
Template the Exporting Process MUST wait before sending a Template  
Withdrawal Message for the Template."
This is a better wording, you're right.

Alternatively, I can simply cut and paste the sentence from RFC5101
   According to the IPFIX specifications [RFC5101], the Template 
   Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.  This
   configurable time is called the Template Reuse Delay.  [RFC5101] 
   specifies a default value of 5 seconds.
Which one do you prefer?
It's not a CP delay, or is it? I'm confused as to what configurability  
at the CP has to do with it.
  
  
     2. Introduction

        The IPFIX working group has specified a protocol to export IP
        Flow information [RFC5101].  This protocol is designed to
        export information about IP traffic Flows and related
        measurement data, where a Flow is defined by a set of key
        attributes (e.g. source and destination IP address, source
        and destination port, etc.).  However, thanks to its template
        mechanism, the IPFIX protocol can export any type of
        information, as long as the relevant Information Element is
        specified in the IPFIX Information Model [RFC5102],
        registered with IANA, or specified as an enterprise-specific
        Information Element.

        The IPFIX protocol [RFC5101] specifies that IP traffic
        measurements for Flows are exported using a TLV (type,
        length, value) format.  The information is exported using a
        Template Record that is sent once to export the {type,
        length} pairs that define the data format for the Information
        Elements in a Flow.  The Data Records specify values for each
        Flow.

        The IPFIX protocol [RFC5101] is flexible: it foresees the  
usage
        of the multiple SCTP streams per association; it allows the
        transmission of Data Sets, Template Sets, and/or Options
        Template Sets on any stream; it offers the full or partial
        reliability export of Data Sets; it proposes the ordered or  
out-
        of-order delivery of Data Sets.  However, due to bandwidth


     <Claise, et. Al>       Expires January 1, 2009           [Page 5]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        restrictions and packet losses in the network as well as
        resource constraints on the Exporter and Collector (e.g.,
        limited buffer sizes), it is not always possible to export all
        Data Sets in a reliable way.

    

I'm going to make a few stylistic suggestions here in the  
introduction, because the introduction, I think, needs to be very  
clear as to what the document is, and it reads a little awkwardly to  
me as it stands.

  
        Without delving into the details of the specifications  
described
        later on in this document, the basic idea is to export the
        Template Record and its associated Data Sets into a single
        unique SCTP stream, ideally to limit the Template ID to a  
single
        stream, while imposing in-order transmission.
    

Introductory construct is a little unclear. Suggest replacement of  
this paragraph with:

This document specifies a method for exporting a Template Record and  
its associated Data Sets in a single SCTP stream, limiting each  
Template ID to a single stream if possible, and imposing in-order  
transmission.
That reads a lot better. Done.
  
        The specification in this document offers several advantages
        such as: calculation of Data Record losses in case of  
partially-
        reliable SCTP export, immediate export of the Template
        Withdrawal Message, immediate reuse of template ID within a
        stream, reduced likelihood of losing Data Record, and the
        Collecting Process's job is easier.
    

Text is not parallel; there are typographic errors here as well.  
Suggest replacement of this paragraph with:

This method offers several advantages over IPFIX export as specified  
in [RFC5101] such as the ability to calculate Data Record losses for  
PR-SCTP, immediate export of Template Withdrawal Messages, immediate  
reuse of Template IDs within an SCTP stream, reduced likelihood of  
Data Record loss, and reduced demands on the Collecting Process.
Good proposal. Done.
I've also updated the abstract to be in line with this paragraph.
       2.1. Relationship with IPFIX and PSAMP

        The specification in this document applies to the IPFIX
        protocol specifications [RFC5101].  However, it only applies
        to the SCTP transport protocol [RFC4960] option of the IPFIX
        protocol specifications, specifically in the case of the
        partial reliability extension [RFC3758].  All specifications
        from [RFC5101] apply unless specified otherwise in this
        document.

        As the Packet Sampling (PSAMP) protocol specifications
        [PSAMP-PROTO] are based on the IPFIX protocol specifications,
        the specifications in this document are also valid for the
        PSAMP protocol.  Therefore, the advantages specified by this
        document also apply to PSAMP.
    

The document specifies a method, not a set of advantages; suggest  
"Therefore, the method..."
Done.
     2.2. Applicability

        The specifications are required in cases where we must know  
how
        many Data Records of a certain type (i.e. from a certain
        Template ID) were lost.  Furthermore, they apply in cases  
where
        the Exporter can not afford to export all the Flow Records
        reliably, due to the limited resources to buffer the huge  
amount
        of flow records.  Such situations may occur if Data Sets are
        generated at a higher rate at the Exporter than can be
        transferred to the Collector because of bandwidth  
limitations in


     <Claise, et. Al>       Expires January 1, 2009           [Page 6]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        the network or slow reception at the Collector.  A typically
        example is a router exporting billing records.
    

typical example
Done.
  
        To be more precise, the specification applicability is the  
case
        where multiple Template IDs are sent within a SCTP Transport
        Session and the calculation of the Data Record loss for a
        particular one Template ID is required.  Indeed, with the
        current IPFIX specifications [RFC5101], if an IPFIX Message is
        lost (UDP or SCTP partially reliable), it is not possible to
        determine to which Template ID of the Transport Session the  
lost
        Data Records belong to.
    

Not in the general case, no. An EP can of course use only a single  
template for all export in a given session, or use a separate  
observation domain for each application. This is not the _only_ way  
under the current spec to estimate loss, it's just the most SCTP  
friendly, and the least hackish.
Understood. To stress the point, I changed "within a SCTP Transport Session" into "within a single SCTP Transport Session"
I also added the following sentence as a new paragraph at the end of the section 3.1.1 (I think it's more appropriate there): "Note that a workaround allowed by the IPFIX specifications [RFC5101] is to use only one Template per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template are required."

I propose not to mention the option of separate observation domain as this hack will certainly lead to some more confusion.

  
        In terms of Collector, there is backwards compatibility: the
        Collecting Process does not require any changes to support an
        Exporter that complies to the specifications in this document.
    

Suggest:

Exporting Processes following this specification will interoperate  
with existing Collecting Processes that comply with [RFC5101]; no  
changes are required at the Collecting Process to support this method.
Done.
  
     2.3. Limitations

        To be compliant with the specifications in this document, the
        Transport Session must support multiple SCTP streams.
        Furthermore, if the SCTP Transport Session does not support
        enough streams for the increasing number of Template ID in the
        Transport Session, the addition of streams must be supported
        according to [SCTP-RESET].  Alternatively, the new Template ID
        and associated Data Records may be added to an existing stream
        at the cost of diluting the granularity of Data Records loss.
        The other alternatives, which is not practical in operational
        networks, is to restart the SCTP association with an increase
        number of streams.
    

A few unclear and nonstandard constructs here, and a little  
terminology confusion. The discussion of alternatives to one-session- 
per-stream and SCTP reset is not a limitation of the approach, it's a  
workaround to limitations in certain SCTP stacks, and is a bit  
detailed for an introduction I think.  Suggest replacement:

This method requires multiple SCTP streams in the association between  
the Exporting and Collecting Process, ideally one per Template. The  
SCTP association should support the addition of streams according to  
[SCTP-RESET] in order to handle the transmission of additional  
Templates during the Transport Session.
Perfect.
  
     3. IPFIX Protocol Specifications Limitations and Improvements
    

I think this section needs some frontmatter explaining its  
organization. From the point of view of the TOC it makes sense, but  
reading the document through end to end it's a little disorienting.
New proposal

For three specific topics (Data Record Loss per Template, Transmission Order within a Stream, No Transmission Order across SCTP Streams), this section explains the IPFIX protocol specifications limitations on one hand, and the advantages of the method specified in this document on the other hand. 

  
     3.2.2. IPFIX Export per SCTP Stream Advantages

        By exporting each Template Record and the corresponding Data
        Records within a single stream and imposing in-order
        transmission, the Template will always arrive before the
        associated Data Records.  Therefore, there is no risk that
        the Collecting Process discards Data Records while waiting
        for the Template to arrive.

        Furthermore, when reusing a Template ID within a stream, the
        Template Withdrawal Message will be guaranteed to arrive
        before the new definition of the Template and therefore the
        Template Record may be sent directly after the Template
        Withdrawal Message.  In other words, the Template Reuse Delay
        restriction (by default, 5 seconds, as specified in [RFC5101]
        is removed for Template ID reuse within the same stream.

        Another advantage with the new specifications in this
        document is that the Collecting Process's job is now easier.
        Indeed, the Collecting Process doesn't have to store the Data
        Records while waiting for the Template Records, as the
        transmission order is always guaranteed.  This way, extra
        reliability of the Data Records is achieved without extra
        burden on the Collecting Process.
    

Prefer "reduces load on the CP" to "the CP's job is now easier"; the  
latter reads quite informally for a specification.
Done.
It might be nice if there were some way for a full-featured CP (i.e.  
one that supports buffering of Data Sets with missing Templates) to  
know whether it had to preallocate buffers for such a thing, but this  
is a very minor technical point.
Since we must have the backwards compatible with other RFC 5101 CPs, I'm not sure if this possible.
  
     3.3.2. IPFIX Export per SCTP Stream Advantages

        By exporting each Template Record and the corresponding Data
        Records within a single stream, imposing in-order
        transmission, and limiting the Template ID to a single
        stream, the issue of ordered transmission across multiple
        streams is avoided.

        By exporting all corresponding Data Records within the same
        ordered stream as the Template Definition, each stream is
        independent and self-contained and the interaction between
        streams is limited to that of Options Data interactions.  This
        has several advantageous consequences, including the order
        preservation that does not result in the blocking of unrelated
        data and the Collector's job simplification (as the Template
        Records are guaranteed to be delivered before the associated
        Data Records).
    

see previous comments about the "collector's job" language.
New text:
This has several advantageous consequences, including the order preservation that does not result in the blocking of unrelated data and load reduction on the Collecting Process (as the Template Records are guaranteed to be delivered before the associated Data Records, there is no need for buffering of Data Sets with missing Templates).
  
     4. Specifications

     4.1. Template Management

        This section introduces modifications compared to the Template
        Management section 8 in [RFC5101].


     <Claise, et. Al>       Expires January 1, 2009          [Page 10]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008



        As specified in [RFC5101], Template Sets and Options Template
        Sets MUST be sent reliably.  In other words, any IPFIX Message
        containing an (Options) Template Set MUST be sent reliably.
    

Verify that all 2119 keywords drawn from 5101 actually do restate the  
point properly; as I recall there was a bit of trouble over this with  
the implementation guidelines.
When I wrote "As specified in [RFC5101]", I always cut and pasted the exact sentence(s) from RFC5101.
If there is something specific to this draft, I would start a new paragraph

  
        Any Data Sets associated with a Template Record MUST be sent  
on
        the same stream on which the Template Record was sent.
    

The use of 2119 MUST language here implies a mandatory modification to  
5101. I know this is not the case given the document's intended  
status, but perhaps there should be some frontmatter in section four  
scoping the 2119 keywords within this section to implementations of  
the specification only.
Proposed new text in section 4

This section introduces improvements compared to the IPFIX specifications in [RFC5101].  These new specifications, which are more specific compared to [RFC5101], are descried with the key words described in [RFC2119].


  
        The Exporter SHOULD send a single Template and associated Data
        Sets within a single stream in order to calculate the  
potential
        Data Record loss for this Template ID.
    

in order to _enable_ calculation (it's the collector doing the loss  
calculation, right, not the exporter?)
Done.
  
 However, the Exporter
        MAY group related Templates and their associated Data Sets
        within a single stream so loss statistics are calculated for  
the
        group.  This may be suitable in cases where there is
        insufficient SCTP streams to send each Template on its own
        stream and/or the case where there are slight variations on a
        single Template to show that some fields were unavailable at  
the
        time of monitoring.
    

This last sentence is kind of confusing. What I think you mean is:

This is suitable in cases where there are only slight variations among  
the templates in a group, e.g. the omission of unavailable fields for  
export efficiency, and may be necessary if the SCTP association does  
not support enough streams to export each Template in its own stream.
Nicely expressed. Done.
Hmm... Actually, I think the specification would be greatly improved  
by the formal introduction of a "template group" concept, and the  
rephrasing of the specification to cover the export of one template  
_group_ per stream. Since the omission of missing fields is not only  
common practice but recommended by the documents, you're often likely  
to get a set of related templates. Exporting these as a group is I  
think what you're really trying to do with this document, since it's  
application-granularity loss you're trying to estimate, yes?
Actually, we're saying: always export one template per SCTP stream, except in some circumstances:
- you don't care about the loss calculation
- you want to export within the same stream the option template record that will help the data record interpretation (example: sampling rate)
- you don't have enough SCTP stream. If this is the case, use "template group"

  
        If a SCTP stream contains a mixture of Data Records defined  
by a
        Template Record and Options Template Record(s), the Data  
Records
        defined by the Options Template Record(s) SHOULD be sent
        reliably within the same stream so that the Collector does not
        consider any loss to be associated with the Options Data.
        Indeed, if the Collector does not have the guarantee that the
        Data Records defined by the Options Template Record are sent
        reliably, the Collector can not determine whether the loss in
        that stream belongs to the Data Records defined by the  
Template
        Record, defined by the Option Template Record, or by both of
        them.  By sending the Options Data reliably (which is usually
        required to interpret the Data Records correctly), any loss  
will
        be limited to the non-option Data Record and loss can still be
        calculated on a per Template basis.

        For each (Options) Template Record, the Exporting Process MUST
        send the Data Record Reliability Option Template using an  
Option
        Template with the following Information Elements:

         SCOPE:     Template ID
         NOT-SCOPE: dataRecordsReliability

        The Data Record Reliability Option Template MUST be sent
        reliably.

    

It's a template, so it must be sent reliably. This is redundant.
Yes. I removed it.
Or do  
you mean the record described by this template?

More seriously, I don't see the point of this Option. Can't the CP  
just deduce from the EP's actions whether it's sending the data for a  
given template reliably or not?
How?
Isn't it a layer violation if the Exporter looks in the SCTP transport to determine the reliability level?
Also, just because the Exporter sent some records reliably there is not a guaranteed indication of future intent, or more specifically an
indication that any lost records won't be associated with this Template ID. 
Also, what additional functionality  
does the CP really gain by deducing this? Doesn't all the stream loss  
estimation stuff still work (well, on a per-group basis, anyway)?
If you're sending with the same SCTP stream, a mix of:
    flows record with sampled data and sampler ID
    option template describing the sampling rate asssociated with a specifier sampler ID
If  the CP sees a gap in the sequence number, and the CP doesn't know that the option data records (for a lack a better term) are sent reliably, what should be the CP deduce?
    1. I lost a flow record -> this is pretty bad from an accuracy point of view
    OR
    2. I lost an option data record -> I can't fully interpret my data.
This mechanism will help the CP to say that the loss comes only from data record, because the option data record were sent reliably.
I understand that this is a different "group" that what you described above, as in this case the group contains data records and associated option data records. Really the options data is considered information that supports the interpretation of the group data, but isn't part of the group. 

  
     <Claise, et. Al>       Expires January 1, 2009          [Page 11]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        The Option Data Record SHOULD be sent before the Data Record
        that needs it so that it arrives first and is available for  
the
        Collector to use.
    

And I presume it should also be sent reliably?
Yes, added.
Note: the "Option Data Record" doesn't exist.
New text:

The Data Record defined by the Data Record Reliability Option Template SHOULD be sent, reliably, before the Data Record that needs it so that it arrives first and is available for the Collector to use.

In some other instances of "Option Data Record", I changed the draft to use option Data Record 
  
     4.2. New Information Element

        dataRecordsReliability

           Description:
                The Data Records reliability associated with this
                Template ID.  The integer value 1 means that the Data
                Records are sent reliably, while the integer value 2
                means that the Data Records are not sent reliably.
           Abstract Data Type: boolean
           Data Type Semantics: identifier
           ElementId: xxx
           Status: current
    

Inconsistent. Is it an integer, or a boolean?
>From RFC5101
6.1.5.  boolean


   The boolean data type is specified according to the TruthValue in
   [RFC2579]: it is an integer with the value 1 for true and a value 2
   for false.  Every other value is undefined.  The boolean data type
   MUST be encoded in a single octet.
However, you're right, let's not confuse the information model with the encoding rule
New proposed text:
Description:
                The Data Records reliability associated with this
                Template ID.  The true value means that the Data
                Records are sent reliably, while the false value
                means that the Data Records are not sent reliably.

  
     4.3. SCTP

        This section introduces modifications compared to the "SCTP"
        section 10.2 (and subsections) in [RFC5101].  More  
specifically
        the "Stream" section 10.2.4.3
    

See above about 2119 language and intended status. This frontmatter  
clearly reads as if it supercedes or updates 5101, which is not the  
case.
This section introduces some more specific specifications compared to the "SCTP" section 10.2 (and subsections) in [RFC5101].  
  
        PR-SCTP [RFC3758] MUST be implemented by all compliant
        implementations.

        All IPFIX Messages MUST be sent in order within a stream.

        Depending on the application requirement, the Exporting  
Process
        MAY send Data Sets with full or partial reliability.   
Unreliable
        data transfer MAY be used where the application does not  
require
        reliable transmission or the use of a retransmission queue is
        impractical due to resource restrictions at the Exporter.


        If the Exporting Process requires to export a new Template but
        there are no more free SCTP streams available, it SHOULD  
attempt
        to increase the number of outbound streams it is able to send
        to, per [SCTP-RESET].  Alternatively, the Exporting Process  
MAY
        add the Template Set and Data Records to an existing stream at
        the cost of diluting the granularity of Data Records loss.





     <Claise, et. Al>       Expires January 1, 2009          [Page 12]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


     4.4. Template Withdrawal Message

        This section introduces Template Withdrawal Message-related
        modifications compared to the Template Management section 8 in
        [RFC5101].
    

As above.

  
        Templates that are not used anymore SHOULD be deleted.  Before
        reusing a Template ID, the Template MUST be deleted.  In order
        to delete an allocated Template, the Template is withdrawn
        through the use of a Template Withdrawal Message.  The  
Template
        Withdrawal Message MUST be sent on the same stream as the
        Template Record.
    

Inconsistent terminology. Template deletion == withdrawal?
The first two sentences are cut and pasted from RFC5101.
I added "as specified in [RFC5101] in front of them
  
        As the Template Withdrawal Message MUST be sent reliably,  
using
        SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
        are sent in order within a stream (per the specifications in
        this document), the IPFIX Message containing the Template
        Withdrawal Message will not arrive at the Collecting Process
        before any associated and previously sent Data Record.  As a
        consequence, no Data Records will be lost due to delayed  
arrival
        at the Collector.

        The Template ID from a withdrawn Template MAY be reused on the
        same stream immediately after the Template Withdrawal  
Message is
        sent.  This case is equivalent to the use of a Template Reuse
        Delay value of 0.

        If the new definition of the Template ID is to be reused on a
        different stream, the Template Withdrawal Message MUST NOT be
        sent before the Template Reuse Delay.

        A Template Withdrawal Message to withdraw all Templates for  
the
        Observation Domain ID specified in the IPFIX Message header  
MUST
        NOT be used.

        Multiple Template IDs MAY be withdrawn with a single Template
        Withdrawal Message at the condition that all the Template  
IDs in
        the Template Withdrawal Message are used on the same SCTP
        stream.


     4.5. The Collecting Process's Side

        This section introduces modifications to the Collection  
Process
        as compared to section 9 in [RFC5101].
    

Modification of Collecting Process behavior is in conflict with the  
statement in the introduction that EPs using this spec interoperate  
with 5101 CPs. Which is it?
New proposal.

This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101].  However, the new specifications are backwards compatible with RFC5101-compliant Collecting Processes.


  
     <Claise, et. Al>       Expires January 1, 2009          [Page 13]

     Internet-Draft      <IPFIX Export per SCTP Stream>       July  
2008


        The Collecting Process SHOULD listen for a new association
        request from the Exporting Process.  The Exporting Process  
will
        request a number of streams to use for export: the number of
        streams SHOULD be equivalent to the number of simultaneous
        Template Records used in the association. Note that the  
Template
        Records don't include the Options Template Records.
    

This statement does not modify 5101 CP behavior and is superfluous.
It might not be obvious for new comers. So we thought about adding that. Anyway, removed.
  
        A Collecting Process SHOULD support the procedure for the
        addition of an SCTP stream [SCTP-RESET].

        The IPFIX protocol has a Sequence Number field in the IPFIX
        Message header that increases with the number of IPFIX Data
        Records in the IPFIX Message.  A Collector may detect out-of-
        sequence, dropped, or duplicate IPFIX Messages by tracking the
        Sequence Number.  As this Sequence Number is per SCTP stream,
        the loss for the Data Records sent in that stream can be
        calculated in case of partially-reliable export.
    

A recommendation for how to do this calculation would be nice here.
New proposal

  When one or more IPFIX Messages are considered lost, the number of lost
  Data Records is equal to the Sequence Number of the first IPFIX Message Header
  following the lost packets (S2) minus the Sequence Number of the
  first lost IPFIX Message (S1).  The Sequence Number of the first lost
  IPFIX Message can be calculated as the Sequence Number of the last
  IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the number
  of Data Records in that IPFIX Message (N0).

    S1   = S0 + N0
    loss = S2 - S1 = S2 - (S0 + N0) 
  
        If the Collecting Process receives a Template Withdrawal  
Message
        on a different stream than the one on which the Template ID is
        used, then the Collecting Process MUST reset the association  
and
        SHOULD log an error message.
    

This is not possible without superceding 5101 and breaking  
interoperability with stock 5101 EPs. Therefore it must be removed.
Good catch.
New text:

 

If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message.

Furthermore (though I know we do it all over the protocol), CP- 
initiated Transport Session shutdown does not follow the general  
protocol design rule of "be conservative in what you send and liberal  
in what you accept". Adding a new condition where we do this would be  
less than ideal. But I accept that I lost this fight a while ago. :)
Actually we have heard some very good arguments against Postel’s robustness
principle. In 2001 Marshall Rose wrote:

    Counter-intuitively, Postel’s robustness principle (“be conservative
    in what you send, liberal in what you accept”) often leads to
    deployment problems. Why? When a new implementation is initially
    fielded, it is likely that it will encounter only a subset of existing
    implementations. If those implementations follow the robustness
    principle, then errors in the new implementation will likely go
    undetected. The new implementation then sees some, but not widespread
    deployment. This process repeats for several new implementations.
    Eventually, the not-quite-correct implementations run into other
    implementations that are less liberal than the initial set of
    implementations. The reader should be able to figure out what happens
    next. 
  
        The following sentences from [RFC5101] are not applicable in
        this specification:

           "The Collecting Process normally receives Template Records
           from the Exporting Process before receiving Data Records.
           The Data Records are then decoded and stored by the
           Collector.  If the Template Records have not been  
received at
           the time Data Records are received, the Collecting Process
           MAY store the Data Records for a short period of time and
           decode them after the Template Records are received."
    

No need to remove this. CPs may still support buffering of template- 
less Data even if the EP doesn't require them to.
Sentences removed.

Regards, Benoit.
Regards,

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

--------------010003000207020803040704-- --===============1144050565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1144050565==-- From ipfix-bounces@ietf.org Thu Oct 16 18:18:25 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78BC3A69CA; Thu, 16 Oct 2008 18:18:25 -0700 (PDT) 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 121DC3A69CA for ; Thu, 16 Oct 2008 18:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 hmvm5ngVqhOj for ; Thu, 16 Oct 2008 18:18:22 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1A09E3A6841 for ; Thu, 16 Oct 2008 18:18:21 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:c938:b552:e16:9607]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9H1JAvE011902; Fri, 17 Oct 2008 10:19:13 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 17 Oct 2008 10:13:25 +0900 From: Atsushi Kobayashi To: muenz@net.in.tum.de In-Reply-To: <48F6040C.5090209@informatik.uni-tuebingen.de> References: <20080308212938.7A9F.AKOBA@nttv6.net> <48F6040C.5090209@informatik.uni-tuebingen.de> Message-Id: <20081017095407.198E.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 17 Oct 2008 10:19:15 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, > You are right that today's router allow configuring IPFIX/Netflow > functions for a given ACL. From the IPFIX point of view, the output of > the ACL should then be regarded as the Observation Point, e.g.: > > linecard => ACL => OP => ... > | > |--> from here, we are in the scope of IPFIX > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow use the given ACL feature. I think that the given ACL feature will be used, even if they become IPFIX/PSAMP. But, the given ACL features are different style among the several vendors. So, it might be hard to standardize them. >From view point of IPFIX configuration, I hope that it would allow some vendor to add on ACL feature as enterprise option. Is it possible? Regards, Atsushi Kobayashi On Wed, 15 Oct 2008 16:54:04 +0200 Gerhard Muenz wrote: > > Hi Kobayashi, > > A late reply to your proposal to add ACL configuration into IPFIX > configuration. > > We (the authors of the draft) think that ACL configuration is out of > scope of IPFIX. The reason is that ACLs in routers are not restricted to > packet filtering for IPFIX/Netflow. They affect other router functions > as well. Therefore, an ACL should not be regarded as a PSAMP Selection > Process. > > You are right that today's router allow configuring IPFIX/Netflow > functions for a given ACL. From the IPFIX point of view, the output of > the ACL should then be regarded as the Observation Point, e.g.: > > linecard => ACL => OP => ... > | > |--> from here, we are in the scope of IPFIX > > > You are also right that ACL configuration would be a nice feature. > However, we think that this is not part of IPFIX standardization. > > Regards, > Gerhard > > > Kobayashi Atsushi wrote: > > Hi Gerhard, Benoit and all, > > > > This draft is almost complete and great work. > > I think that such XML configuration enhances efficiency of the use of > > flexibility of IPFIX. > > > > IMHO, I am afraid that the filtering method is different than current ACL > > implemented in several routers. Therefore, the IPFIX XML cfg might not > > be implemented, because of the gap between current ACL filter and IPFIX > > XML cfg, even if psamp mention "AND" operation only. > > > > I propose the following XML schema added the ACL elements to -03 draft. > > I am not familiar with YANG yet, sorry. > > > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > > > > The following Complex/Simple type elements are added. > > - Complex Type: accessListMatch_type > > - Complex Type: sequenceList_type > > - Simple Type: action_type > > > > In addition, it allows "selectionProcess_type" to include > > "AccessListMatch" element. > > > > What do you think about that? I think that it enhances flexibility as > > optional. > > > > Regards, > > Atsushi KOBAYASHI > > > > On Mon, 25 Feb 2008 17:50:21 +0100 > > Gerhard Muenz wrote: > > > >> Dear all, > >> > >> A new revision of the IPFIX/PSAMP configuration data model has been > >> published: > >> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > >> > >> Apart from smaller changes in the model itself, the big change compared > >> to the previous version concerns the specification language: instead of > >> XML Schema, we now use YANG, a new language for modelling Netconf data > >> models. As a consequence, conformance to Netconf can be guaranteed. > >> > >> We received a lot of valuable feedback and support from Martin Bjorklund > >> who is a Netconf expert and author of the YANG draft. We will try to get > >> some additional feedback from other Netconf experts as well. > >> > >> Regards, > >> Gerhard > >> > >> -- > >> Dipl.-Ing. Gerhard M$B".(Bz > >> Computer Networks and Internet > >> Wilhelm Schickard Institute for Computer Science > >> University of Tuebingen > >> Sand 13 (Room B309), D-72076 Tuebingen, Germany > >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > >> E-mail: muenz@informatik.uni-tuebingen.de > >> WWW: http://net.informatik.uni-tuebingen.de/~muenz > >> > > > > --- > > Atsushi KOBAYASHI > > NTT Information Sharing Platform Lab. > > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, 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 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 16 18:18:25 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78BC3A69CA; Thu, 16 Oct 2008 18:18:25 -0700 (PDT) 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 121DC3A69CA for ; Thu, 16 Oct 2008 18:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 hmvm5ngVqhOj for ; Thu, 16 Oct 2008 18:18:22 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1A09E3A6841 for ; Thu, 16 Oct 2008 18:18:21 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:c938:b552:e16:9607]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9H1JAvE011902; Fri, 17 Oct 2008 10:19:13 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 17 Oct 2008 10:13:25 +0900 From: Atsushi Kobayashi To: muenz@net.in.tum.de In-Reply-To: <48F6040C.5090209@informatik.uni-tuebingen.de> References: <20080308212938.7A9F.AKOBA@nttv6.net> <48F6040C.5090209@informatik.uni-tuebingen.de> Message-Id: <20081017095407.198E.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 17 Oct 2008 10:19:15 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, > You are right that today's router allow configuring IPFIX/Netflow > functions for a given ACL. From the IPFIX point of view, the output of > the ACL should then be regarded as the Observation Point, e.g.: > > linecard => ACL => OP => ... > | > |--> from here, we are in the scope of IPFIX > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow use the given ACL feature. I think that the given ACL feature will be used, even if they become IPFIX/PSAMP. But, the given ACL features are different style among the several vendors. So, it might be hard to standardize them. >From view point of IPFIX configuration, I hope that it would allow some vendor to add on ACL feature as enterprise option. Is it possible? Regards, Atsushi Kobayashi On Wed, 15 Oct 2008 16:54:04 +0200 Gerhard Muenz wrote: > > Hi Kobayashi, > > A late reply to your proposal to add ACL configuration into IPFIX > configuration. > > We (the authors of the draft) think that ACL configuration is out of > scope of IPFIX. The reason is that ACLs in routers are not restricted to > packet filtering for IPFIX/Netflow. They affect other router functions > as well. Therefore, an ACL should not be regarded as a PSAMP Selection > Process. > > You are right that today's router allow configuring IPFIX/Netflow > functions for a given ACL. From the IPFIX point of view, the output of > the ACL should then be regarded as the Observation Point, e.g.: > > linecard => ACL => OP => ... > | > |--> from here, we are in the scope of IPFIX > > > You are also right that ACL configuration would be a nice feature. > However, we think that this is not part of IPFIX standardization. > > Regards, > Gerhard > > > Kobayashi Atsushi wrote: > > Hi Gerhard, Benoit and all, > > > > This draft is almost complete and great work. > > I think that such XML configuration enhances efficiency of the use of > > flexibility of IPFIX. > > > > IMHO, I am afraid that the filtering method is different than current ACL > > implemented in several routers. Therefore, the IPFIX XML cfg might not > > be implemented, because of the gap between current ACL filter and IPFIX > > XML cfg, even if psamp mention "AND" operation only. > > > > I propose the following XML schema added the ACL elements to -03 draft. > > I am not familiar with YANG yet, sorry. > > > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > > > > The following Complex/Simple type elements are added. > > - Complex Type: accessListMatch_type > > - Complex Type: sequenceList_type > > - Simple Type: action_type > > > > In addition, it allows "selectionProcess_type" to include > > "AccessListMatch" element. > > > > What do you think about that? I think that it enhances flexibility as > > optional. > > > > Regards, > > Atsushi KOBAYASHI > > > > On Mon, 25 Feb 2008 17:50:21 +0100 > > Gerhard Muenz wrote: > > > >> Dear all, > >> > >> A new revision of the IPFIX/PSAMP configuration data model has been > >> published: > >> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > >> > >> Apart from smaller changes in the model itself, the big change compared > >> to the previous version concerns the specification language: instead of > >> XML Schema, we now use YANG, a new language for modelling Netconf data > >> models. As a consequence, conformance to Netconf can be guaranteed. > >> > >> We received a lot of valuable feedback and support from Martin Bjorklund > >> who is a Netconf expert and author of the YANG draft. We will try to get > >> some additional feedback from other Netconf experts as well. > >> > >> Regards, > >> Gerhard > >> > >> -- > >> Dipl.-Ing. Gerhard M$B".(Bz > >> Computer Networks and Internet > >> Wilhelm Schickard Institute for Computer Science > >> University of Tuebingen > >> Sand 13 (Room B309), D-72076 Tuebingen, Germany > >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > >> E-mail: muenz@informatik.uni-tuebingen.de > >> WWW: http://net.informatik.uni-tuebingen.de/~muenz > >> > > > > --- > > Atsushi KOBAYASHI > > NTT Information Sharing Platform Lab. > > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, 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 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 17 03:15:27 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EB83A68AB; Fri, 17 Oct 2008 03:15:27 -0700 (PDT) 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 11CB63A68AB for ; Fri, 17 Oct 2008 03:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml0wZtB+gcU9 for ; Fri, 17 Oct 2008 03:15:25 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 3ACE23A682C for ; Fri, 17 Oct 2008 03:15:24 -0700 (PDT) Received: from repulse.net.informatik.tu-muenchen.de ([131.159.14.99]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KqmNc-0002T7-C5; Fri, 17 Oct 2008 12:16:24 +0200 Message-ID: <48F865F1.9060500@informatik.uni-tuebingen.de> Date: Fri, 17 Oct 2008 12:16:17 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080308212938.7A9F.AKOBA@nttv6.net> <48F6040C.5090209@informatik.uni-tuebingen.de> <20081017095407.198E.17391CF2@nttv6.net> In-Reply-To: <20081017095407.198E.17391CF2@nttv6.net> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: muenz@net.in.tum.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Kobayashi, Atsushi Kobayashi wrote: > Hi Gerhard, > >> You are right that today's router allow configuring IPFIX/Netflow >> functions for a given ACL. From the IPFIX point of view, the output of >> the ACL should then be regarded as the Observation Point, e.g.: >> >> linecard => ACL => OP => ... >> | >> |--> from here, we are in the scope of IPFIX >> > > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > use the given ACL feature. I think that the given ACL feature will be > used, even if they become IPFIX/PSAMP. But, the given ACL features are > different style among the several vendors. So, it might be hard to > standardize them. > > From view point of IPFIX configuration, I hope that it would allow some > vendor to add on ACL feature as enterprise option. Is it possible? Yes, vendors can augment the data model with vendor-specific parameters. Yet, I cannot answer if and how they will do this in the case of ACLs. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 17 03:15:27 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EB83A68AB; Fri, 17 Oct 2008 03:15:27 -0700 (PDT) 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 11CB63A68AB for ; Fri, 17 Oct 2008 03:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml0wZtB+gcU9 for ; Fri, 17 Oct 2008 03:15:25 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 3ACE23A682C for ; Fri, 17 Oct 2008 03:15:24 -0700 (PDT) Received: from repulse.net.informatik.tu-muenchen.de ([131.159.14.99]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KqmNc-0002T7-C5; Fri, 17 Oct 2008 12:16:24 +0200 Message-ID: <48F865F1.9060500@informatik.uni-tuebingen.de> Date: Fri, 17 Oct 2008 12:16:17 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080308212938.7A9F.AKOBA@nttv6.net> <48F6040C.5090209@informatik.uni-tuebingen.de> <20081017095407.198E.17391CF2@nttv6.net> In-Reply-To: <20081017095407.198E.17391CF2@nttv6.net> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: muenz@net.in.tum.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Kobayashi, Atsushi Kobayashi wrote: > Hi Gerhard, > >> You are right that today's router allow configuring IPFIX/Netflow >> functions for a given ACL. From the IPFIX point of view, the output of >> the ACL should then be regarded as the Observation Point, e.g.: >> >> linecard => ACL => OP => ... >> | >> |--> from here, we are in the scope of IPFIX >> > > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > use the given ACL feature. I think that the given ACL feature will be > used, even if they become IPFIX/PSAMP. But, the given ACL features are > different style among the several vendors. So, it might be hard to > standardize them. > > From view point of IPFIX configuration, I hope that it would allow some > vendor to add on ACL feature as enterprise option. Is it possible? Yes, vendors can augment the data model with vendor-specific parameters. Yet, I cannot answer if and how they will do this in the case of ACLs. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 23 04:23:23 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AF828C199; Thu, 23 Oct 2008 04:23:23 -0700 (PDT) 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 945163A6C6B for ; Thu, 23 Oct 2008 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, GB_I_LETTER=-2, 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 JCTBeEsIZTEX for ; Thu, 23 Oct 2008 04:23:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 22EA53A6900 for ; Thu, 23 Oct 2008 04:23:13 -0700 (PDT) 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 m9NBO6Z24114; Thu, 23 Oct 2008 13:24:06 +0200 (CEST) Received: from [10.61.80.63] (ams3-vpn-dhcp4160.cisco.com [10.61.80.63]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9NBO3G24047; Thu, 23 Oct 2008 13:24:04 +0200 (CEST) Message-ID: <49005ED3.8050401@cisco.com> Date: Thu, 23 Oct 2008 13:24:03 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080902155307.F9E4.17391CF2@nttv6.net> In-Reply-To: <20080902155307.F9E4.17391CF2@nttv6.net> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: multipart/mixed; boundary="===============0438868675==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0438868675== Content-Type: multipart/alternative; boundary="------------070704050503070207090107" This is a multi-part message in MIME format. --------------070704050503070207090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kobayashi-san, Thank you very much for your review. Note that the draft excerpts are in this email contained already the improvements proposed by Brian. > Dear all, > > I did not have enough time for reviewing for the draft in Aug. > Although the time limit exceeds, I have reviewed the draft. > > Please see my questions and comments and so on in lines. > > Q1) > I think that the following condition is configurable choice. > - One stream treats one Template Record and associated Data Records. > - One stream treats some Template Records and associated Data Records > related to same Observation Domain, or same Observation Points. > It can deduce Data Record Loss per observation domain or observation points. > Does this draft cover the latter pattern ? > Yes, exactly. This is a configurable choice. "The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID. However, the Exporter MAY group related Templates and their corresponFrom ipfix-bounces@ietf.org Thu Oct 23 04:23:23 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AF828C199; Thu, 23 Oct 2008 04:23:23 -0700 (PDT) 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 945163A6C6B for ; Thu, 23 Oct 2008 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, GB_I_LETTER=-2, 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 JCTBeEsIZTEX for ; Thu, 23 Oct 2008 04:23:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 22EA53A6900 for ; Thu, 23 Oct 2008 04:23:13 -0700 (PDT) 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 m9NBO6Z24114; Thu, 23 Oct 2008 13:24:06 +0200 (CEST) Received: from [10.61.80.63] (ams3-vpn-dhcp4160.cisco.com [10.61.80.63]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9NBO3G24047; Thu, 23 Oct 2008 13:24:04 +0200 (CEST) Message-ID: <49005ED3.8050401@cisco.com> Date: Thu, 23 Oct 2008 13:24:03 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080902155307.F9E4.17391CF2@nttv6.net> In-Reply-To: <20080902155307.F9E4.17391CF2@nttv6.net> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: multipart/mixed; boundary="===============0438868675==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0438868675== Content-Type: multipart/alternative; boundary="------------070704050503070207090107" This is a multi-part message in MIME format. --------------070704050503070207090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kobayashi-san, Thank you very much for your review. Note that the draft excerpts are in this email contained already the improvements proposed by Brian. > Dear all, > > I did not have enough time for reviewing for the draft in Aug. > Although the time limit exceeds, I have reviewed the draft. > > Please see my questions and comments and so on in lines. > > Q1) > I think that the following condition is configurable choice. > - One stream treats one Template Record and associated Data Records. > - One stream treats some Template Records and associated Data Records > related to same Observation Domain, or same Observation Points. > It can deduce Data Record Loss per observation domain or observation points. > Does this draft cover the latter pattern ? > Yes, exactly. This is a configurable choice. "The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID. However, the Exporter MAY group related Templates and their correspding Data Sets within a single stream so that loss statistics are calculated for the group. This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream." > Q2) > This draft does not describe how to export some statistics option > template and data. Should they be exported on same stream exporting > associated Template and Data Records ? > Basically, you can choose. To make sure we stress that, I would like to improve the previous sentence "The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID. However, the Exporter MAY group related _(Options) _Templates and their corresponding Data Sets within a single stream so that loss statistics are calculated for the group. This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream." However, if you chose to send them within a single stream, then the following text applies: "If a SCTP stream contains a mixture of Data Records defined by a Template Record and Options Template Record(s), the Data Records defined by the Options Template Record(s) SHOULD be sent reliably within the same stream so that the Collector does not consider any loss to be associated with the options Data Record." >> >> 1. Terminology >> >> IPFIX-specific terminology used in this document is defined >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- >> specific terms have the first letter of a word capitalized >> when used in this document. >> >> Template Reuse Delay >> >> The configurable timeout to allow the Collecting Process >> to receive and process the last Data Record using this >> Template information before which the Template Withdrawal >> Message MUST NOT be sent. [RFC5101] specifies a default >> value of 5 seconds. >> >> > > Q3) > In first reading, I could not understand which process uses this timer, > Collecting process or Exporting Process. > I think that the description of RFC5101 is more easily understandable. > RFC5101 say as follows. > > The Template Withdrawal Message MUST NOT be sent until sufficient > time has elapsed to allow the Collecting Process to receive and > process the last Data Record using this Template information. > Are you fine with Brian's proposal? Template Reuse Delay The time after sending the last Data Set described by a given Template the Exporting Process MUST wait before sending a Template Withdrawal Message for the Template. [RFC5101] specifies a default value of 5 seconds. > >> 2. Introduction >> >> The IPFIX working group has specified a protocol to export IP >> Flow information [RFC5101]. This protocol is designed to >> export information about IP traffic Flows and related >> measurement data, where a Flow is defined by a set of key >> attributes (e.g. source and destination IP address, source >> and destination port, etc.). However, thanks to its template >> mechanism, the IPFIX protocol can export any type of >> information, as long as the relevant Information Element is >> specified in the IPFIX Information Model [RFC5102], >> registered with IANA, or specified as an enterprise-specific >> Information Element. >> >> The IPFIX protocol [RFC5101] specifies that IP traffic >> measurements for Flows are exported usionding Data Sets within a single stream so that loss statistics are calculated for the group. This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream." > Q2) > This draft does not describe how to export some statistics option > template and data. Should they be exported on same stream exporting > associated Template and Data Records ? > Basically, you can choose. To make sure we stress that, I would like to improve the previous sentence "The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID. However, the Exporter MAY group related _(Options) _Templates and their corresponding Data Sets within a single stream so that loss statistics are calculated for the group. This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream." However, if you chose to send them within a single stream, then the following text applies: "If a SCTP stream contains a mixture of Data Records defined by a Template Record and Options Template Record(s), the Data Records defined by the Options Template Record(s) SHOULD be sent reliably within the same stream so that the Collector does not consider any loss to be associated with the options Data Record." >> >> 1. Terminology >> >> IPFIX-specific terminology used in this document is defined >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- >> specific terms have the first letter of a word capitalized >> when used in this document. >> >> Template Reuse Delay >> >> The configurable timeout to allow the Collecting Process >> to receive and process the last Data Record using this >> Template information before which the Template Withdrawal >> Message MUST NOT be sent. [RFC5101] specifies a default >> value of 5 seconds. >> >> > > Q3) > In first reading, I could not understand which process uses this timer, > Collecting process or Exporting Process. > I think that the description of RFC5101 is more easily understandable. > RFC5101 say as follows. > > The Template Withdrawal Message MUST NOT be sent until sufficient > time has elapsed to allow the Collecting Process to receive and > process the last Data Record using this Template information. > Are you fine with Brian's proposal? Template Reuse Delay The time after sending the last Data Set described by a given Template the Exporting Process MUST wait before sending a Template Withdrawal Message for the Template. [RFC5101] specifies a default value of 5 seconds. > >> 2. Introduction >> >> The IPFIX working group has specified a protocol to export IP >> Flow information [RFC5101]. This protocol is designed to >> export information about IP traffic Flows and related >> measurement data, where a Flow is defined by a set of key >> attributes (e.g. source and destination IP address, source >> and destination port, etc.). However, thanks to its template >> mechanism, the IPFIX protocol can export any type of >> information, as long as the relevant Information Element is >> specified in the IPFIX Information Model [RFC5102], >> registered with IANA, or specified as an enterprise-specific >> Information Element. >> >> The IPFIX protocol [RFC5101] specifies that IP traffic >> measurements for Flows are exported ung a TLV (type, >> length, value) format. The information is exported using a >> Template Record that is sent once to export the {type, >> length} pairs that define the data format for the Information >> Elements in a Flow. The Data Records specify values for each >> Flow. >> >> The IPFIX protocol [RFC5101] is flexible: it foresees the usage >> of the multiple SCTP streams per association; it allows the >> transmission of Data Sets, Template Sets, and/or Options >> Template Sets on any stream; it offers the full or partial >> reliability export of Data Sets; it proposes the ordered or out- >> of-order delivery of Data Sets. However, due to bandwidth >> restrictions and packet losses in the network as well as >> resource constraints on the Exporter and Collector (e.g., >> limited buffer sizes), it is not always possible to export all >> Data Sets in a reliable way. >> >> >> Without delving into the details of the specifications described >> later on in this document, the basic idea is to export the >> Template Record and its associated Data Sets into a single >> unique SCTP stream, ideally to limit the Template ID to a single >> stream, while imposing in-order transmission. >> >> The specification in this document offers several advantages >> such as: calculation of Data Record losses in case of partially- >> reliable SCTP export, immediate export of the Template >> Withdrawal Message, immediate reuse of template ID within a >> stream, reduced likelihood of losing Data Record, and the >> Collecting Process's job is easier. >> > > Q4) > This feature seems to be able to be applied to SCTP and PR-SCTP. But, > Introduction emphasizes the usage of PR-SCTP. What is advantages of > PR-SCTP situation over normal SCTP ? > Is it to deduce the loss count related to Template ID ? > This draft only applies to PR-SCTP, because SCTP (without PR), will try to retransmit until it can't anymore and then the SCTP association will be shutdown. I tried to confirm that from RFC4960 but I couldn't find the appropriate text. Furthermore, both SCTP and PR-SCTP are MUST in RFC5101 I propose to improve the abstract, to avoid any confusion OLD: This document specifies an improvement to the export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. NEW: This document specifies an improvement to the _PR-SCTP_ export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. >> 4. Specifications >> >> 4.1. Template Management >> >> This section introduces modifications compared to the Template >> Management section 8 in [RFC5101]. >> As specified in [RFC5101], Template Sets and Options Template >> Sets MUST be sent reliably. In other words, any IPFIX Message >> containing an (Options) Template Set MUST be sent reliably. >> >> Any Data Sets associated with a Template Record MUST be sent on >> the same stream on which the Template Record was sent. >> >> The Exporter SHOULD send a single Template and associated Data >> Sets within a single stream in order to calculate the potential >> Data Record loss for this Template ID. However, the Exporter >> MAY group related Templates and their associated Data Sets >> within a single strsing a TLV (type, >> length, value) format. The information is exported using a >> Template Record that is sent once to export the {type, >> length} pairs that define the data format for the Information >> Elements in a Flow. The Data Records specify values for each >> Flow. >> >> The IPFIX protocol [RFC5101] is flexible: it foresees the usage >> of the multiple SCTP streams per association; it allows the >> transmission of Data Sets, Template Sets, and/or Options >> Template Sets on any stream; it offers the full or partial >> reliability export of Data Sets; it proposes the ordered or out- >> of-order delivery of Data Sets. However, due to bandwidth >> restrictions and packet losses in the network as well as >> resource constraints on the Exporter and Collector (e.g., >> limited buffer sizes), it is not always possible to export all >> Data Sets in a reliable way. >> >> >> Without delving into the details of the specifications described >> later on in this document, the basic idea is to export the >> Template Record and its associated Data Sets into a single >> unique SCTP stream, ideally to limit the Template ID to a single >> stream, while imposing in-order transmission. >> >> The specification in this document offers several advantages >> such as: calculation of Data Record losses in case of partially- >> reliable SCTP export, immediate export of the Template >> Withdrawal Message, immediate reuse of template ID within a >> stream, reduced likelihood of losing Data Record, and the >> Collecting Process's job is easier. >> > > Q4) > This feature seems to be able to be applied to SCTP and PR-SCTP. But, > Introduction emphasizes the usage of PR-SCTP. What is advantages of > PR-SCTP situation over normal SCTP ? > Is it to deduce the loss count related to Template ID ? > This draft only applies to PR-SCTP, because SCTP (without PR), will try to retransmit until it can't anymore and then the SCTP association will be shutdown. I tried to confirm that from RFC4960 but I couldn't find the appropriate text. Furthermore, both SCTP and PR-SCTP are MUST in RFC5101 I propose to improve the abstract, to avoid any confusion OLD: This document specifies an improvement to the export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. NEW: This document specifies an improvement to the _PR-SCTP_ export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. >> 4. Specifications >> >> 4.1. Template Management >> >> This section introduces modifications compared to the Template >> Management section 8 in [RFC5101]. >> As specified in [RFC5101], Template Sets and Options Template >> Sets MUST be sent reliably. In other words, any IPFIX Message >> containing an (Options) Template Set MUST be sent reliably. >> >> Any Data Sets associated with a Template Record MUST be sent on >> the same stream on which the Template Record was sent. >> >> The Exporter SHOULD send a single Template and associated Data >> Sets within a single stream in order to calculate the potential >> Data Record loss for this Template ID. However, the Exporter >> MAY group related Templates and their associated Data Sets >> within a single seam so loss statistics are calculated for the >> group. This may be suitable in cases where there is >> insufficient SCTP streams to send each Template on its own >> stream and/or the case where there are slight variations on a >> single Template to show that some fields were unavailable at the >> time of monitoring. >> >> If a SCTP stream contains a mixture of Data Records defined by a >> Template Record and Options Template Record(s), the Data Records >> defined by the Options Template Record(s) SHOULD be sent >> reliably within the same stream so that the Collector does not >> consider any loss to be associated with the Options Data. >> Indeed, if the Collector does not have the guarantee that the >> > > Q5) > It seems Exporter, not Collector. Is it correct? > > The "Collector" was correct, as the loss is calculated from the Collector >> Data Records defined by the Options Template Record are sent >> reliably, the Collector can not determine whether the loss in >> that stream belongs to the Data Records defined by the Template >> Record, defined by the Option Template Record, or by both of >> them. By sending the Options Data reliably (which is usually >> required to interpret the Data Records correctly), any loss will >> be limited to the non-option Data Record and loss can still be >> calculated on a per Template basis. >> >> For each (Options) Template Record, the Exporting Process MUST >> send the Data Record Reliability Option Template using an Option >> Template with the following Information Elements: >> >> SCOPE: Template ID >> NOT-SCOPE: dataRecordsReliability >> >> The Data Record Reliability Option Template MUST be sent >> reliably. >> >> > > Q6) > I cannot clearly understand how to use this field > "dataRecordsReliability". > "Data Record Reliability Option Template" might be applied to Option > Template only? No, to both Template and Options Template. > How is it handled by Collector for consecutive Data > Record after receiving the option template? > If Collector does not receive this template, what's going to happen? > If the Collector doesn't receive it, it means that the Exporters don't support the specifications in this document and then there is no problem. ;-) If the Exporters do support these specifications, then Data Record Reliability Option Template MUST be exported reliably, so the Collector will receive it. We have improved the text and completed the examples. > >> The Option Data Record SHOULD be sent before the Data Record >> that needs it so that it arrives first and is available for the >> Collector to use. >> >> >> >> >> >> 4.5. The Collecting Process's Side >> >> This section introduces modifications to the Collection Process >> as compared to section 9 in [RFC5101]. >> >> >> The Collecting Process SHOULD listen for a new association >> request from the Exporting Process. The Exporting Process will >> request a number of streams to use for export: the number of >> streams SHOULD be equivalent to the number of simultaneous >> Template Records used in the association. Note that the Template >> Records don't include the Options Template Records. >> >> A Collecting Process SHOULD support the procedure for the >> addition of an SCTP stream [SCTP-RESET]. >> >> The IPFIX protocol has a Sequence Number field in the IPFIX >> Message header that increases with the number of IPFIX Data >> Records in the IPFIX Message. A Collector may detect out-of- >> sequence, dropped, or duplicate IPFIX Messages by tracking the >> Sequence Number. As thtream so loss statistics are calculated for the >> group. This may be suitable in cases where there is >> insufficient SCTP streams to send each Template on its own >> stream and/or the case where there are slight variations on a >> single Template to show that some fields were unavailable at the >> time of monitoring. >> >> If a SCTP stream contains a mixture of Data Records defined by a >> Template Record and Options Template Record(s), the Data Records >> defined by the Options Template Record(s) SHOULD be sent >> reliably within the same stream so that the Collector does not >> consider any loss to be associated with the Options Data. >> Indeed, if the Collector does not have the guarantee that the >> > > Q5) > It seems Exporter, not Collector. Is it correct? > > The "Collector" was correct, as the loss is calculated from the Collector >> Data Records defined by the Options Template Record are sent >> reliably, the Collector can not determine whether the loss in >> that stream belongs to the Data Records defined by the Template >> Record, defined by the Option Template Record, or by both of >> them. By sending the Options Data reliably (which is usually >> required to interpret the Data Records correctly), any loss will >> be limited to the non-option Data Record and loss can still be >> calculated on a per Template basis. >> >> For each (Options) Template Record, the Exporting Process MUST >> send the Data Record Reliability Option Template using an Option >> Template with the following Information Elements: >> >> SCOPE: Template ID >> NOT-SCOPE: dataRecordsReliability >> >> The Data Record Reliability Option Template MUST be sent >> reliably. >> >> > > Q6) > I cannot clearly understand how to use this field > "dataRecordsReliability". > "Data Record Reliability Option Template" might be applied to Option > Template only? No, to both Template and Options Template. > How is it handled by Collector for consecutive Data > Record after receiving the option template? > If Collector does not receive this template, what's going to happen? > If the Collector doesn't receive it, it means that the Exporters don't support the specifications in this document and then there is no problem. ;-) If the Exporters do support these specifications, then Data Record Reliability Option Template MUST be exported reliably, so the Collector will receive it. We have improved the text and completed the examples. > >> The Option Data Record SHOULD be sent before the Data Record >> that needs it so that it arrives first and is available for the >> Collector to use. >> >> >> >> >> >> 4.5. The Collecting Process's Side >> >> This section introduces modifications to the Collection Process >> as compared to section 9 in [RFC5101]. >> >> >> The Collecting Process SHOULD listen for a new association >> request from the Exporting Process. The Exporting Process will >> request a number of streams to use for export: the number of >> streams SHOULD be equivalent to the number of simultaneous >> Template Records used in the association. Note that the Template >> Records don't include the Options Template Records. >> >> A Collecting Process SHOULD support the procedure for the >> addition of an SCTP stream [SCTP-RESET]. >> >> The IPFIX protocol has a Sequence Number field in the IPFIX >> Message header that increases with the number of IPFIX Data >> Records in the IPFIX Message. A Collector may detect out-of- >> sequence, dropped, or duplicate IPFIX Messages by tracking the >> Sequence Number. As is Sequence Number is per SCTP stream, >> the loss for the Data Records sent in that stream can be >> calculated in case of partially-reliable export. >> >> If the Collecting Process receives a Template Withdrawal Message >> on a different stream than the one on which the Template ID is >> used, then the Collecting Process MUST reset the association and >> SHOULD log an error message. >> > > Q7) > I think it is difficult to distinguish the session to use the export > per stream function. Because RFC5101 said the Template Withdrawal > Message may be sent on any SCTP stream. > You're fully right. We covered that one based on Brian's feedback. New text: If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message. > >> >> The following sentences from [RFC5101] are not applicable in >> this specification: >> >> "The Collecting Process normally receives Template Records >> from the Exporting Process before receiving Data Records. >> The Data Records are then decoded and stored by the >> Collector. If the Template Records have not been received at >> the time Data Records are received, the Collecting Process >> MAY store the Data Records for a short period of time and >> decode them after the Template Records are received." >> >> >> 5. Examples >> > > > Q8) > I hope that the examples include "Data Record Reliability Option > Template". > Done. > >> Figure 1 shows an example where the stream 10 carries a Template >> with the Template ID 256 transmitted with full reliability (FR), >> together with associated Data Records transmitted with partial >> reliability (PR). Note that, because all IPFIX Messages are >> sent in order within a stream, the Template 256 will always be >> processed before the Data Records by the Collecting Process. >> Therefore, the Collecting Process job is simplified. >> Furthermore, the Data Record loss for the Template 256 can >> easily be calculated on the Collecting Process. >> >> >> +--------+ +---------+ +----------+ >> | | | | | | >> stream 10 ----| Data | . . . | Data |---| Template |---> >> | 256 | | 256 | | 256 | >> | PR| | PR| | FR| >> +--------+ +---------+ +----------+ >> Figure 1 >> >> If an Option Template is necessary to understand the content of >> a Data Record (i.e. the scope in the Options Template Record is >> an Information Element contained in the Data Record), the >> Options Template Record may be sent in the same stream, as >> displayed in figure 2. >> >> +--------+ +--------+ +----------+ >> | | | | | | >> stream 20 ... ---| Data |...| Data |-----| Template |--- >> | 258 | | 258 | | 258 | >> | PR| | PR| | FR| >> +--------+ +--------+ +----------+ >> >> +--------+ +----------+ >> | | | Options | >> ...---| Data |-------| Template |------> >> | 257 | | 257 | >> | FR| | FR| >> this Sequence Number is per SCTP stream, >> the loss for the Data Records sent in that stream can be >> calculated in case of partially-reliable export. >> >> If the Collecting Process receives a Template Withdrawal Message >> on a different stream than the one on which the Template ID is >> used, then the Collecting Process MUST reset the association and >> SHOULD log an error message. >> > > Q7) > I think it is difficult to distinguish the session to use the export > per stream function. Because RFC5101 said the Template Withdrawal > Message may be sent on any SCTP stream. > You're fully right. We covered that one based on Brian's feedback. New text: If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message. > >> >> The following sentences from [RFC5101] are not applicable in >> this specification: >> >> "The Collecting Process normally receives Template Records >> from the Exporting Process before receiving Data Records. >> The Data Records are then decoded and stored by the >> Collector. If the Template Records have not been received at >> the time Data Records are received, the Collecting Process >> MAY store the Data Records for a short period of time and >> decode them after the Template Records are received." >> >> >> 5. Examples >> > > > Q8) > I hope that the examples include "Data Record Reliability Option > Template". > Done. > >> Figure 1 shows an example where the stream 10 carries a Template >> with the Template ID 256 transmitted with full reliability (FR), >> together with associated Data Records transmitted with partial >> reliability (PR). Note that, because all IPFIX Messages are >> sent in order within a stream, the Template 256 will always be >> processed before the Data Records by the Collecting Process. >> Therefore, the Collecting Process job is simplified. >> Furthermore, the Data Record loss for the Template 256 can >> easily be calculated on the Collecting Process. >> >> >> +--------+ +---------+ +----------+ >> | | | | | | >> stream 10 ----| Data | . . . | Data |---| Template |---> >> | 256 | | 256 | | 256 | >> | PR| | PR| | FR| >> +--------+ +---------+ +----------+ >> Figure 1 >> >> If an Option Template is necessary to understand the content of >> a Data Record (i.e. the scope in the Options Template Record is >> an Information Element contained in the Data Record), the >> Options Template Record may be sent in the same stream, as >> displayed in figure 2. >> >> +--------+ +--------+ +----------+ >> | | | | | | >> stream 20 ... ---| Data |...| Data |-----| Template |--- >> | 258 | | 258 | | 258 | >> | PR| | PR| | FR| >> +--------+ +--------+ +----------+ >> >> +--------+ +----------+ >> | | | Options | >> ...---| Data |-------| Template |------> >> | 257 | | 257 | >> | FR| | FR| >> +--------+ +----------+ >> Figure 2 >> >> Figure 2 shows an example where stream 20 carries an Options >> Template with Template ID 257 transmitted with full reliability >> (FR), an associated Data Record transmitted with full >> reliability (FR), a Template with Template ID 258 transmitted >> with full reliability (FR), and associated Data Records >> transmitted with partial reliability (PR). In this example the >> Option Template Record contains information required to decode >> the latter Data Records, such as Common Properties information >> [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 >> reliably. If some Data Record loss is observed from the >> Sequence Number , the loss can only stem from the Data Sets with >> the Template ID 258, as these are the only Sets not exported >> reliably. Therefore, the calculation of loss per Template ID >> 258 is possible. >> >> >> Note that, because all IPFIX Messages must be sent in order >> within a stream, the Options Template 257 will always arrive >> before its associated Data Records, and that the Template 259 >> > > Q9) > Is it correct, 259 or 258? > 258. Good catch. A new draft version will be posted very soon. Thanks for your feedback. Regards, Benoit. --------------070704050503070207090107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kobayashi-san,

Thank you very much for your review.
Note that the draft excerpts are in this email contained already the improvements proposed by Brian.
Dear all,

I did not have enough time for reviewing for the draft in Aug.
Although the time limit exceeds, I have reviewed the draft.

Please see my questions and comments and so on in lines.

Q1)
I think that the following condition is configurable choice.
- One stream treats one Template Record and associated Data Records.
- One stream treats some Template Records and associated Data Records
related to same Observation Domain, or same Observation Points.
It can deduce Data Record Loss per observation domain or observation points.
Does this draft cover the latter pattern ?
Yes, exactly. This is a configurable choice.

"The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID.  However, the Exporter MAY group related Templates and their corresponding Data Sets within a single stream so that loss statistics are calculated for the group.  This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream."


Q2)
This draft does not describe how to export some statistics option
template and data. Should they be exported on same stream exporting
associated Template and Data Records ?
Basically, you can choose. To make sure we stress that, I would like to improve the previous sentence
"The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID.  However, the Exporter MAY group related (Options) Templates and their corresponding Data Sets within +--------+ +----------+ >> Figure 2 >> >> Figure 2 shows an example where stream 20 carries an Options >> Template with Template ID 257 transmitted with full reliability >> (FR), an associated Data Record transmitted with full >> reliability (FR), a Template with Template ID 258 transmitted >> with full reliability (FR), and associated Data Records >> transmitted with partial reliability (PR). In this example the >> Option Template Record contains information required to decode >> the latter Data Records, such as Common Properties information >> [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 >> reliably. If some Data Record loss is observed from the >> Sequence Number , the loss can only stem from the Data Sets with >> the Template ID 258, as these are the only Sets not exported >> reliably. Therefore, the calculation of loss per Template ID >> 258 is possible. >> >> >> Note that, because all IPFIX Messages must be sent in order >> within a stream, the Options Template 257 will always arrive >> before its associated Data Records, and that the Template 259 >> > > Q9) > Is it correct, 259 or 258? > 258. Good catch. A new draft version will be posted very soon. Thanks for your feedback. Regards, Benoit. --------------070704050503070207090107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kobayashi-san,

Thank you very much for your review.
Note that the draft excerpts are in this email contained already the improvements proposed by Brian.
Dear all,

I did not have enough time for reviewing for the draft in Aug.
Although the time limit exceeds, I have reviewed the draft.

Please see my questions and comments and so on in lines.

Q1)
I think that the following condition is configurable choice.
- One stream treats one Template Record and associated Data Records.
- One stream treats some Template Records and associated Data Records
related to same Observation Domain, or same Observation Points.
It can deduce Data Record Loss per observation domain or observation points.
Does this draft cover the latter pattern ?
Yes, exactly. This is a configurable choice.

"The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID.  However, the Exporter MAY group related Templates and their corresponding Data Sets within a single stream so that loss statistics are calculated for the group.  This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream."


Q2)
This draft does not describe how to export some statistics option
template and data. Should they be exported on same stream exporting
associated Template and Data Records ?
Basically, you can choose. To make sure we stress that, I would like to improve the previous sentence
"The Exporter SHOULD send a single Template and corresponding Data Sets within a single stream in order to enable calculation of the potential Data Record loss for this Template ID.  However, the Exporter MAY group related (Options) Templates and their corresponding Data Sets within a single stream so that loss statistics are calculated for the group.  This is suitable in cases where there are only slight variations among the Templates in a group, e.g. the omission of unavailable fields for export efficiency, and may be necessary if the SCTP association does not support enough streams to export each Template in its own stream."

However, if you chose to send them within a single stream, then the following text applies:
"If a SCTP stream contains a mixture of Data Records defined by a Template Record and Options Template Record(s), the Data Records defined by the Options Template Record(s) SHOULD be sent reliably within the same stream so that the Collector does not consider any loss to be associated with the options Data Record."
      
     1. Terminology 

        IPFIX-specific terminology used in this document is defined 
        in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
        specific terms have the first letter of a word capitalized 
        when used in this document. 
         
        Template Reuse Delay  
         
           The configurable timeout to allow the Collecting Process 
           to receive and process the last Data Record using this 
           Template information before which the Template Withdrawal 
           Message MUST NOT be sent.  [RFC5101] specifies a default 
           value of 5 seconds. 

    

Q3)
In first reading, I could not understand which process uses this timer,
Collecting process or Exporting Process.
I think that the description of RFC5101 is more easily understandable.
RFC5101 say as follows.

   The Template Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.
Are you fine with Brian's proposal?

Template Reuse Delay

The time after sending the last Data Set described by a given Template the Exporting Process MUST wait before sending a Template Withdrawal Message for the Template.  [RFC5101] specifies a default value of 5 seconds.


     2. Introduction 

        The IPFIX working group has specified a protocol to export IP 
        Flow information [RFC5101].  This protocol is designed to 
        export information about IP traffic Flows and related 
        measurement data, where a Flow is defined by a set of key 
        attributes (e.g. source and destination IP address, source 
        and destination port, etc.).  However, thanks to its template 
        mechanism, the IPFIX protocol can export any type of 
        information, as long as the relevant Information Element is 
        specified in the IPFIX Information Model [RFC5102], 
        registered with IANA, or specified as an enterprise-specific 
        Information Element. 
         
        The IPFIX protocol [RFC5101] specifies that IP traffic 
        measurements for Flows are exported using a TLV (type, 
        length, value) format.  The information is exported using a 
        Template Record that is sent once to export the {type, 
        length} pairs that define the data format for the Information 
        Elements in a Flow.  The Data Records specify values for each 
        Flow. 
         
   a single stream so that loss
statistics are calculated for the group. 
This is suitable in cases where there are only slight variations
among the Templates in a group, e.g. the omission of unavailable fields
for export
efficiency, and may be necessary if the SCTP association does not
support
enough streams to export each Template in its own stream."

However, if you chose to send them within a single stream, then the following text applies:
"If a SCTP stream contains a mixture of Data Records defined by a Template Record and Options Template Record(s), the Data Records defined by the Options Template Record(s) SHOULD be sent reliably within the same stream so that the Collector does not consider any loss to be associated with the options Data Record."
      
     1. Terminology 

        IPFIX-specific terminology used in this document is defined 
        in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
        specific terms have the first letter of a word capitalized 
        when used in this document. 
         
        Template Reuse Delay  
         
           The configurable timeout to allow the Collecting Process 
           to receive and process the last Data Record using this 
           Template information before which the Template Withdrawal 
           Message MUST NOT be sent.  [RFC5101] specifies a default 
           value of 5 seconds. 

    

Q3)
In first reading, I could not understand which process uses this timer,
Collecting process or Exporting Process.
I think that the description of RFC5101 is more easily understandable.
RFC5101 say as follows.

   The Template Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.
Are you fine with Brian's proposal?

Template Reuse Delay

The time after sending the last Data Set described by a given Template the Exporting Process MUST wait before sending a Template Withdrawal Message for the Template.  [RFC5101] specifies a default value of 5 seconds.


     2. Introduction 

        The IPFIX working group has specified a protocol to export IP 
        Flow information [RFC5101].  This protocol is designed to 
        export information about IP traffic Flows and related 
        measurement data, where a Flow is defined by a set of key 
        attributes (e.g. source and destination IP address, source 
        and destination port, etc.).  However, thanks to its template 
        mechanism, the IPFIX protocol can export any type of 
        information, as long as the relevant Information Element is 
        specified in the IPFIX Information Model [RFC5102], 
        registered with IANA, or specified as an enterprise-specific 
        Information Element. 
         
        The IPFIX protocol [RFC5101] specifies that IP traffic 
        measurements for Flows are exported using a TLV (type, 
        length, value) format.  The information is exported using a 
        Template Record that is sent once to export the {type, 
        length} pairs that define the data format for the Information 
        Elements in a Flow.  The Data Records specify values for each 
        Flow. 
         
          The IPFIX protocol [RFC5101] is flexible: it foresees the usage 
        of the multiple SCTP streams per association; it allows the 
        transmission of Data Sets, Template Sets, and/or Options 
        Template Sets on any stream; it offers the full or partial 
        reliability export of Data Sets; it proposes the ordered or out-
        of-order delivery of Data Sets.  However, due to bandwidth 
        restrictions and packet losses in the network as well as 
        resource constraints on the Exporter and Collector (e.g., 
        limited buffer sizes), it is not always possible to export all 
        Data Sets in a reliable way. 
         
         
        Without delving into the details of the specifications described 
        later on in this document, the basic idea is to export the 
        Template Record and its associated Data Sets into a single 
        unique SCTP stream, ideally to limit the Template ID to a single 
        stream, while imposing in-order transmission. 
         
        The specification in this document offers several advantages 
        such as: calculation of Data Record losses in case of partially-
        reliable SCTP export, immediate export of the Template 
        Withdrawal Message, immediate reuse of template ID within a 
        stream, reduced likelihood of losing Data Record, and the 
        Collecting Process's job is easier. 
    

Q4) 
This feature seems to be able to be applied to SCTP and PR-SCTP. But,
Introduction emphasizes the usage of PR-SCTP. What is advantages of 
PR-SCTP situation over normal SCTP ? 
Is it to deduce the loss count related to Template ID ?
This draft only applies to PR-SCTP, because SCTP (without PR), will try to retransmit until it can't anymore and then the SCTP association will be shutdown. I tried to confirm that from RFC4960 but I couldn't find the appropriate text.
Furthermore, both SCTP and PR-SCTP are MUST in RFC5101

I propose to improve the abstract, to avoid any confusion
OLD:

This document specifies an improvement to the export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process.


NEW:

This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process.

     4. Specifications 

     4.1. Template Management 

        This section introduces modifications compared to the Template 
        Management section 8 in [RFC5101]. 
        As specified in [RFC5101], Template Sets and Options Template 
        Sets MUST be sent reliably.  In other words, any IPFIX Message 
        containing an (Options) Template Set MUST be sent reliably.   
         
        Any Data Sets associated with a Template Record MUST be sent on 
        the same stream on which the Template Record was sent. 
         
        The Exporter SHOULD send a single Template and associated Data 
        Sets within a single stream in order to calculate the potential 
        Data Record loss for this Template ID.  However, the Exporter 
        MAY group related Templates and their associated Data Sets 
        within a single stream so loss statistics are calculated for the 
        group.  This may be suitable in cases where there is 
        insufficient SCTP streams to send each    The IPFIX protocol [RFC5101] is flexible: it foresees the usage 
        of the multiple SCTP streams per association; it allows the 
        transmission of Data Sets, Template Sets, and/or Options 
        Template Sets on any stream; it offers the full or partial 
        reliability export of Data Sets; it proposes the ordered or out-
        of-order delivery of Data Sets.  However, due to bandwidth 
        restrictions and packet losses in the network as well as 
        resource constraints on the Exporter and Collector (e.g., 
        limited buffer sizes), it is not always possible to export all 
        Data Sets in a reliable way. 
         
         
        Without delving into the details of the specifications described 
        later on in this document, the basic idea is to export the 
        Template Record and its associated Data Sets into a single 
        unique SCTP stream, ideally to limit the Template ID to a single 
        stream, while imposing in-order transmission. 
         
        The specification in this document offers several advantages 
        such as: calculation of Data Record losses in case of partially-
        reliable SCTP export, immediate export of the Template 
        Withdrawal Message, immediate reuse of template ID within a 
        stream, reduced likelihood of losing Data Record, and the 
        Collecting Process's job is easier. 
    

Q4) 
This feature seems to be able to be applied to SCTP and PR-SCTP. But,
Introduction emphasizes the usage of PR-SCTP. What is advantages of 
PR-SCTP situation over normal SCTP ? 
Is it to deduce the loss count related to Template ID ?
This draft only applies to PR-SCTP, because SCTP (without PR), will try to retransmit until it can't anymore and then the SCTP association will be shutdown. I tried to confirm that from RFC4960 but I couldn't find the appropriate text.
Furthermore, both SCTP and PR-SCTP are MUST in RFC5101

I propose to improve the abstract, to avoid any confusion
OLD:

This document specifies an improvement to the export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process.


NEW:

This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process.

     4. Specifications 

     4.1. Template Management 

        This section introduces modifications compared to the Template 
        Management section 8 in [RFC5101]. 
        As specified in [RFC5101], Template Sets and Options Template 
        Sets MUST be sent reliably.  In other words, any IPFIX Message 
        containing an (Options) Template Set MUST be sent reliably.   
         
        Any Data Sets associated with a Template Record MUST be sent on 
        the same stream on which the Template Record was sent. 
         
        The Exporter SHOULD send a single Template and associated Data 
        Sets within a single stream in order to calculate the potential 
        Data Record loss for this Template ID.  However, the Exporter 
        MAY group related Templates and their associated Data Sets 
        within a single stream so loss statistics are calculated for the 
        group.  This may be suitable in cases where there is 
        insufficient SCTP streams to send each TeTemplate on its own 
        stream and/or the case where there are slight variations on a 
        single Template to show that some fields were unavailable at the 
        time of monitoring. 
      
        If a SCTP stream contains a mixture of Data Records defined by a 
        Template Record and Options Template Record(s), the Data Records 
        defined by the Options Template Record(s) SHOULD be sent 
        reliably within the same stream so that the Collector does not 
        consider any loss to be associated with the Options Data.  
        Indeed, if the Collector does not have the guarantee that the 
    

Q5) 
It seems Exporter, not Collector. Is it correct?
The "Collector" was correct, as the loss is calculated from the Collector
        Data Records defined by the Options Template Record are sent 
        reliably, the Collector can not determine whether the loss in 
        that stream belongs to the Data Records defined by the Template 
        Record, defined by the Option Template Record, or by both of 
        them.  By sending the Options Data reliably (which is usually 
        required to interpret the Data Records correctly), any loss will 
        be limited to the non-option Data Record and loss can still be 
        calculated on a per Template basis. 
         
        For each (Options) Template Record, the Exporting Process MUST 
        send the Data Record Reliability Option Template using an Option 
        Template with the following Information Elements:  
          
         SCOPE:     Template ID  
         NOT-SCOPE: dataRecordsReliability 
         
        The Data Record Reliability Option Template MUST be sent 
        reliably. 
         
    

Q6)
I cannot clearly understand  how to use this field
"dataRecordsReliability".
"Data Record Reliability Option Template" might be applied to Option
Template only?
No, to both Template and Options Template.
How is it handled by Collector for consecutive Data
Record after receiving the option template?
If Collector does not receive this template, what's going to happen?
If the Collector doesn't receive it, it means that the Exporters don't support the specifications in this document and then there is no problem. ;-)
If the Exporters do support these specifications, then Data Record Reliability Option Template MUST be exported reliably, so the Collector will receive it.

We have improved the text and completed the examples.

  
        The Option Data Record SHOULD be sent before the Data Record 
        that needs it so that it arrives first and is available for the 
        Collector to use. 
      
         
   
   
         
     4.5. The Collecting Process's Side 

        This section introduces modifications to the Collection Process 
        as compared to section 9 in [RFC5101]. 
         

        The Collecting Process SHOULD listen for a new association 
        request from the Exporting Process.  The Exporting Process will 
        request a number of streams to use for export: the number of 
        streams SHOULD be equivalent to the number of simultaneous 
        Template Records used in the association. Note that the Template 
        Records don't include the Options Template Records. 
         
        A Collecting Process SHOULD support the procedure for the 
        addition of an SCTP stream [SCTP-RESET]. 
                       
        The IPFIX protocol has a Sequence Number field in the IPFIX 
        Message header that increases with the number of Implate on its own 
        stream and/or the case where there are slight variations on a 
        single Template to show that some fields were unavailable at the 
        time of monitoring. 
      
        If a SCTP stream contains a mixture of Data Records defined by a 
        Template Record and Options Template Record(s), the Data Records 
        defined by the Options Template Record(s) SHOULD be sent 
        reliably within the same stream so that the Collector does not 
        consider any loss to be associated with the Options Data.  
        Indeed, if the Collector does not have the guarantee that the 
    

Q5) 
It seems Exporter, not Collector. Is it correct?
The "Collector" was correct, as the loss is calculated from the Collector
        Data Records defined by the Options Template Record are sent 
        reliably, the Collector can not determine whether the loss in 
        that stream belongs to the Data Records defined by the Template 
        Record, defined by the Option Template Record, or by both of 
        them.  By sending the Options Data reliably (which is usually 
        required to interpret the Data Records correctly), any loss will 
        be limited to the non-option Data Record and loss can still be 
        calculated on a per Template basis. 
         
        For each (Options) Template Record, the Exporting Process MUST 
        send the Data Record Reliability Option Template using an Option 
        Template with the following Information Elements:  
          
         SCOPE:     Template ID  
         NOT-SCOPE: dataRecordsReliability 
         
        The Data Record Reliability Option Template MUST be sent 
        reliably. 
         
    

Q6)
I cannot clearly understand  how to use this field
"dataRecordsReliability".
"Data Record Reliability Option Template" might be applied to Option
Template only?
No, to both Template and Options Template.
How is it handled by Collector for consecutive Data
Record after receiving the option template?
If Collector does not receive this template, what's going to happen?
If the Collector doesn't receive it, it means that the Exporters don't support the specifications in this document and then there is no problem. ;-)
If the Exporters do support these specifications, then Data Record Reliability Option Template MUST be exported reliably, so the Collector will receive it.

We have improved the text and completed the examples.

  
        The Option Data Record SHOULD be sent before the Data Record 
        that needs it so that it arrives first and is available for the 
        Collector to use. 
      
         
   
   
         
     4.5. The Collecting Process's Side 

        This section introduces modifications to the Collection Process 
        as compared to section 9 in [RFC5101]. 
         

        The Collecting Process SHOULD listen for a new association 
        request from the Exporting Process.  The Exporting Process will 
        request a number of streams to use for export: the number of 
        streams SHOULD be equivalent to the number of simultaneous 
        Template Records used in the association. Note that the Template 
        Records don't include the Options Template Records. 
         
        A Collecting Process SHOULD support the procedure for the 
        addition of an SCTP stream [SCTP-RESET]. 
                       
        The IPFIX protocol has a Sequence Number field in the IPFIX 
        Message header that increases with the number of IPFPFIX Data 
        Records in the IPFIX Message.  A Collector may detect out-of-
        sequence, dropped, or duplicate IPFIX Messages by tracking the 
        Sequence Number.  As this Sequence Number is per SCTP stream, 
        the loss for the Data Records sent in that stream can be 
        calculated in case of partially-reliable export. 
         
        If the Collecting Process receives a Template Withdrawal Message 
        on a different stream than the one on which the Template ID is 
        used, then the Collecting Process MUST reset the association and 
        SHOULD log an error message. 
    

Q7)
I think it is difficult to distinguish the session to use the export 
per stream function. Because  RFC5101 said the Template Withdrawal
Message may be sent on any SCTP stream.
You're fully right.
We covered that one based on Brian's feedback.
New text:

If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message.


  
         
        The following sentences from [RFC5101] are not applicable in 
        this specification: 
         
           "The Collecting Process normally receives Template Records 
           from the Exporting Process before receiving Data Records.  
           The Data Records are then decoded and stored by the 
           Collector.  If the Template Records have not been received at 
           the time Data Records are received, the Collecting Process 
           MAY store the Data Records for a short period of time and 
           decode them after the Template Records are received."  
      
         
     5. Examples 
    


Q8)
I hope that the examples include "Data Record Reliability Option
Template".
Done.

  
        Figure 1 shows an example where the stream 10 carries a Template 
        with the Template ID 256 transmitted with full reliability (FR), 
        together with associated Data Records transmitted with partial 
        reliability (PR).  Note that, because all IPFIX Messages are 
        sent in order within a stream, the Template 256 will always be 
        processed before the Data Records by the Collecting Process. 
        Therefore, the Collecting Process job is simplified. 
        Furthermore, the Data Record loss for the Template 256 can 
        easily be calculated on the Collecting Process. 

         
                      +--------+       +---------+   +----------+   
                      |        |       |         |   |          |      
        stream 10 ----| Data   | . . . |  Data   |---| Template |---> 
                      |   256  |       |    256  |   |     256  | 
                      |      PR|       |       PR|   |        FR|       
                      +--------+       +---------+   +----------+   
                                     Figure 1     
         
        If an Option Template is necessary to understand the content of 
        a Data Record (i.e. the scope in the Options Template Record is 
        an Information Element contained in the Data Record), the 
        Options Template Record may be sent in the same stream, as 
        displayed in figure 2. 
         
                         +--------+   +--------+     +----------+     
                         |        |   |        |     |          |     
        stream 20 ... ---| Data   |...| Data   |-----| Template |--- 
                         |   258  |   |   258  |     |     258  |    
                         |      PR|   |      PR| IX Data 
        Records in the IPFIX Message.  A Collector may detect out-of-
        sequence, dropped, or duplicate IPFIX Messages by tracking the 
        Sequence Number.  As this Sequence Number is per SCTP stream, 
        the loss for the Data Records sent in that stream can be 
        calculated in case of partially-reliable export. 
         
        If the Collecting Process receives a Template Withdrawal Message 
        on a different stream than the one on which the Template ID is 
        used, then the Collecting Process MUST reset the association and 
        SHOULD log an error message. 
    

Q7)
I think it is difficult to distinguish the session to use the export 
per stream function. Because  RFC5101 said the Template Withdrawal
Message may be sent on any SCTP stream.
You're fully right.
We covered that one based on Brian's feedback.
New text:

If the Collecting Process receives a Template Withdrawal Message on a different stream than the one on which the Template ID is used, then the Collecting Process SHOULD log an error message.


  
         
        The following sentences from [RFC5101] are not applicable in 
        this specification: 
         
           "The Collecting Process normally receives Template Records 
           from the Exporting Process before receiving Data Records.  
           The Data Records are then decoded and stored by the 
           Collector.  If the Template Records have not been received at 
           the time Data Records are received, the Collecting Process 
           MAY store the Data Records for a short period of time and 
           decode them after the Template Records are received."  
      
         
     5. Examples 
    


Q8)
I hope that the examples include "Data Record Reliability Option
Template".
Done.

  
        Figure 1 shows an example where the stream 10 carries a Template 
        with the Template ID 256 transmitted with full reliability (FR), 
        together with associated Data Records transmitted with partial 
        reliability (PR).  Note that, because all IPFIX Messages are 
        sent in order within a stream, the Template 256 will always be 
        processed before the Data Records by the Collecting Process. 
        Therefore, the Collecting Process job is simplified. 
        Furthermore, the Data Record loss for the Template 256 can 
        easily be calculated on the Collecting Process. 

         
                      +--------+       +---------+   +----------+   
                      |        |       |         |   |          |      
        stream 10 ----| Data   | . . . |  Data   |---| Template |---> 
                      |   256  |       |    256  |   |     256  | 
                      |      PR|       |       PR|   |        FR|       
                      +--------+       +---------+   +----------+   
                                     Figure 1     
         
        If an Option Template is necessary to understand the content of 
        a Data Record (i.e. the scope in the Options Template Record is 
        an Information Element contained in the Data Record), the 
        Options Template Record may be sent in the same stream, as 
        displayed in figure 2. 
         
                         +--------+   +--------+     +----------+     
                         |        |   |        |     |          |     
        stream 20 ... ---| Data   |...| Data   |-----| Template |--- 
                         |   258  |   |   258  |     |     258  |    
                         |      PR|   |      PR|       |        FR|    
                         +--------+   +--------+     +----------+   
         
                                +--------+       +----------+       
                                |        |       | Options  |       
                          ...---| Data   |-------| Template |------> 
                                |   257  |       |     257  |       
                                |      FR|       |        FR|       
                                +--------+       +----------+  
                                     Figure 2               
         
        Figure 2 shows an example where stream 20 carries an Options 
        Template with Template ID 257 transmitted with full reliability 
        (FR), an associated Data Record transmitted with full 
        reliability (FR), a Template with Template ID 258 transmitted 
        with full reliability (FR), and associated Data Records 
        transmitted with partial reliability (PR).  In this example the 
        Option Template Record contains information required to decode 
        the latter Data Records, such as Common Properties information 
        [IPFIX-RED-RED].  So it makes sense to export the Data Sets 257 
        reliably.  If some Data Record loss is observed from the 
        Sequence Number , the loss can only stem from the Data Sets with 
        the Template ID 258, as these are the only Sets not exported 
        reliably.  Therefore, the calculation of loss per Template ID 
        258 is possible.  

         
        Note that, because all IPFIX Messages must be sent in order 
        within a stream, the Options Template 257 will always arrive 
        before its associated Data Records, and that the Template 259 
    

Q9)
Is it correct, 259 or 258?
258. Good catch.

A new draft version will be posted very soon.
Thanks for your feedback.

Regards, Benoit.
--------------070704050503070207090107-- --===============0438868675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0438868675==-- | FR| +--------+ +--------+ +----------+ +--------+ +----------+ | | | Options | ...---| Data |-------| Template |------> | 257 | | 257 | | FR| | FR| +--------+ +----------+ Figure 2 Figure 2 shows an example where stream 20 carries an Options Template with Template ID 257 transmitted with full reliability (FR), an associated Data Record transmitted with full reliability (FR), a Template with Template ID 258 transmitted with full reliability (FR), and associated Data Records transmitted with partial reliability (PR). In this example the Option Template Record contains information required to decode the latter Data Records, such as Common Properties information [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 reliably. If some Data Record loss is observed from the Sequence Number , the loss can only stem from the Data Sets with the Template ID 258, as these are the only Sets not exported reliably. Therefore, the calculation of loss per Template ID 258 is possible. Note that, because all IPFIX Messages must be sent in order within a stream, the Options Template 257 will always arrive before its associated Data Records, and that the Template 259 

Q9)
Is it correct, 259 or 258?
258. Good catch.

A new draft version will be posted very soon.
Thanks for your feedback.

Regards, Benoit.
--------------070704050503070207090107-- --===============0438868675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0438868675==-- From ipfix-bounces@ietf.org Thu Oct 23 09:11:51 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164C63A6A7E; Thu, 23 Oct 2008 09:11:51 -0700 (PDT) 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 6ECCF3A69C9 for ; Thu, 23 Oct 2008 09:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtfL1KGba--6 for ; Thu, 23 Oct 2008 09:11:41 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id B04BC3A6AC2 for ; Thu, 23 Oct 2008 09:11:41 -0700 (PDT) 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 8DE2339B35 for ; Thu, 23 Oct 2008 18:12:59 +0200 (CEST) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8451E951 for ; Thu, 23 Oct 2008 18:12:59 +0200 (CEST) Message-ID: <4900A28D.4020505@net.in.tum.de> Date: Thu, 23 Oct 2008 18:13:01 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Type: multipart/mixed; boundary="===============1544002501==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1544002501== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050208080708030606040604" This is a cryptographically signed message in MIME format. --------------ms050208080708030606040604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Are there any people/groups - apart from Brian - how have implemented TLS/DTLS for IPFIX (or other flow export protocols)? Does anybody know any commercial products supporting this feature? If yes, please give feedbackk to the following questions: Does it make sense to include TLS/DTLS parameters into the IPFIX configuration model? If so, which are the most important parameters to be included? Regards, Gerhard --------------ms050208080708030606040604 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTAyMzE2MTMwMVowIwYJKoZIhvcNAQkEMRYEFN+eMnQbiL/C X0Gs1sEvHt04QnTVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBaWXologZQ0NXCbmMHmtwFJiIoDMgnEPMDoqzFk5vegHYmftdEPtW9JWm/ cG/2JkYAQiWGhAJDpjNpKXwjrmYnCsRYwQJj3RKByzrUZKS9ugrr2oF9lY4eedQ9VPO5sbsI QYablXT9ZSXu0U0scSoDKbkfnF8c7NBcvwh7pnHvu36rRCVxjfvQBHi39RrVb4oV41xnGiA2 CzkM6T77rQNFYQ3QWPyUa8Ns7zV/RYJnWOQzMKu86SDZdznUViuTqbXhTirQJeA0PwDxidfW ImKTTr1yXQpFa4HuBJR3thhq272giV/6eB0XmkXwriY4yEd+7GGy/LLD5W7aVhgzKKO3AAAA AAAA --------------ms050208080708030606040604-- --===============1544002501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1544002501==-- From ipfix-bounces@ietf.org Thu Oct 23 09:11:51 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164C63A6A7E; Thu, 23 Oct 2008 09:11:51 -0700 (PDT) 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 6ECCF3A69C9 for ; Thu, 23 Oct 2008 09:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtfL1KGba--6 for ; Thu, 23 Oct 2008 09:11:41 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id B04BC3A6AC2 for ; Thu, 23 Oct 2008 09:11:41 -0700 (PDT) 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 8DE2339B35 for ; Thu, 23 Oct 2008 18:12:59 +0200 (CEST) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8451E951 for ; Thu, 23 Oct 2008 18:12:59 +0200 (CEST) Message-ID: <4900A28D.4020505@net.in.tum.de> Date: Thu, 23 Oct 2008 18:13:01 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Type: multipart/mixed; boundary="===============1544002501==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1544002501== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050208080708030606040604" This is a cryptographically signed message in MIME format. --------------ms050208080708030606040604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Are there any people/groups - apart from Brian - how have implemented TLS/DTLS for IPFIX (or other flow export protocols)? Does anybody know any commercial products supporting this feature? If yes, please give feedbackk to the following questions: Does it make sense to include TLS/DTLS parameters into the IPFIX configuration model? If so, which are the most important parameters to be included? Regards, Gerhard --------------ms050208080708030606040604 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTAyMzE2MTMwMVowIwYJKoZIhvcNAQkEMRYEFN+eMnQbiL/C X0Gs1sEvHt04QnTVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBaWXologZQ0NXCbmMHmtwFJiIoDMgnEPMDoqzFk5vegHYmftdEPtW9JWm/ cG/2JkYAQiWGhAJDpjNpKXwjrmYnCsRYwQJj3RKByzrUZKS9ugrr2oF9lY4eedQ9VPO5sbsI QYablXT9ZSXu0U0scSoDKbkfnF8c7NBcvwh7pnHvu36rRCVxjfvQBHi39RrVb4oV41xnGiA2 CzkM6T77rQNFYQ3QWPyUa8Ns7zV/RYJnWOQzMKu86SDZdznUViuTqbXhTirQJeA0PwDxidfW ImKTTr1yXQpFa4HuBJR3thhq272giV/6eB0XmkXwriY4yEd+7GGy/LLD5W7aVhgzKKO3AAAA AAAA --------------ms050208080708030606040604-- --===============1544002501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1544002501==-- From ipfix-bounces@ietf.org Thu Oct 23 10:47:33 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81E23A6824; Thu, 23 Oct 2008 10:47:33 -0700 (PDT) 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 7684D3A6824 for ; Thu, 23 Oct 2008 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Os4m3ilRSHYG for ; Thu, 23 Oct 2008 10:47:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6A8F3A67D7 for ; Thu, 23 Oct 2008 10:47:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3338C0025; Thu, 23 Oct 2008 19:48:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yh75lcEEegz7; Thu, 23 Oct 2008 19:48:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0A0C000B; Thu, 23 Oct 2008 19:48:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7603B827ADA; Thu, 23 Oct 2008 19:48:42 +0200 (CEST) Date: Thu, 23 Oct 2008 19:48:42 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20081023174842.GB28803@elstar.local> References: <4900A28D.4020505@net.in.tum.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4900A28D.4020505@net.in.tum.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Thu, Oct 23, 2008 at 06:13:01PM +0200, Gerhard Muenz wrote: > Are there any people/groups - apart from Brian - how have implemented > TLS/DTLS for IPFIX (or other flow export protocols)? > Does anybody know any commercial products supporting this feature? > > If yes, please give feedbackk to the following questions: > > Does it make sense to include TLS/DTLS parameters into the IPFIX > configuration model? > If so, which are the most important parameters to be included? I have not implemented any of this. However, I suggest avoiding going into any DTLS/TLS configuration details as this is something that should be worked out by DTLS/TLS WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/From ipfix-bounces@ietf.org Thu Oct 23 10:47:33 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81E23A6824; Thu, 23 Oct 2008 10:47:33 -0700 (PDT) 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 7684D3A6824 for ; Thu, 23 Oct 2008 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Os4m3ilRSHYG for ; Thu, 23 Oct 2008 10:47:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6A8F3A67D7 for ; Thu, 23 Oct 2008 10:47:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3338C0025; Thu, 23 Oct 2008 19:48:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yh75lcEEegz7; Thu, 23 Oct 2008 19:48:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0A0C000B; Thu, 23 Oct 2008 19:48:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7603B827ADA; Thu, 23 Oct 2008 19:48:42 +0200 (CEST) Date: Thu, 23 Oct 2008 19:48:42 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20081023174842.GB28803@elstar.local> References: <4900A28D.4020505@net.in.tum.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4900A28D.4020505@net.in.tum.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Thu, Oct 23, 2008 at 06:13:01PM +0200, Gerhard Muenz wrote: > Are there any people/groups - apart from Brian - how have implemented > TLS/DTLS for IPFIX (or other flow export protocols)? > Does anybody know any commercial products supporting this feature? > > If yes, please give feedbackk to the following questions: > > Does it make sense to include TLS/DTLS parameters into the IPFIX > configuration model? > If so, which are the most important parameters to be included? I have not implemented any of this. However, I suggest avoiding going into any DTLS/TLS configuration details as this is something that should be worked out by DTLS/TLS WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ipfix From ipfix-bounces@ietf.org Thu Oct 23 21:49:37 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0703A68ED; Thu, 23 Oct 2008 21:49:36 -0700 (PDT) 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 A81AE3A690D for ; Thu, 23 Oct 2008 21:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qD4eGOiyG8Et for ; Thu, 23 Oct 2008 21:49:31 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 6C7423A68D2 for ; Thu, 23 Oct 2008 21:49:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 53E359D683 for ; Fri, 24 Oct 2008 17:50:51 +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 (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgnnmb2Xsb65 for ; Fri, 24 Oct 2008 17:50:51 +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 38BEB9D67B for ; Fri, 24 Oct 2008 17:50:50 +1300 (NZDT) Message-ID: <4901542A.7000507@auckland.ac.nz> Date: Fri, 24 Oct 2008 17:50:50 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Getting ready for IETF 73 in Minneapolis 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: The Minneapolis IETF is now only about three weeks away, I'll post a preliminary agenda early next week. Meanwhile, we're hoping to see new versions for several of the IPFIX drafts. For those authors concerned, the cutoff dates for new draft versions is Monday 3 November (PT) ... 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 23 21:49:37 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0703A68ED; Thu, 23 Oct 2008 21:49:36 -0700 (PDT) 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 A81AE3A690D for ; Thu, 23 Oct 2008 21:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qD4eGOiyG8Et for ; Thu, 23 Oct 2008 21:49:31 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 6C7423A68D2 for ; Thu, 23 Oct 2008 21:49:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 53E359D683 for ; Fri, 24 Oct 2008 17:50:51 +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 (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgnnmb2Xsb65 for ; Fri, 24 Oct 2008 17:50:51 +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 38BEB9D67B for ; Fri, 24 Oct 2008 17:50:50 +1300 (NZDT) Message-ID: <4901542A.7000507@auckland.ac.nz> Date: Fri, 24 Oct 2008 17:50:50 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Getting ready for IETF 73 in Minneapolis 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: The Minneapolis IETF is now only about three weeks away, I'll post a preliminary agenda early next week. Meanwhile, we're hoping to see new versions for several of the IPFIX drafts. For those authors concerned, the cutoff dates for new draft versions is Monday 3 November (PT) ... 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 24 01:45:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C397528C12E; Fri, 24 Oct 2008 01:45:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7992228C0E6; Fri, 24 Oct 2008 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081024084501.7992228C0E6@core3.amsl.com> Date: Fri, 24 Oct 2008 01:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-03.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: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --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 : Specification of the IPFIX File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-03.txt Pages : 57 Date : 2008-10-24 This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.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-file-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-24013325.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Fri Oct 24 01:45:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C397528C12E; Fri, 24 Oct 2008 01:45:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7992228C0E6; Fri, 24 Oct 2008 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081024084501.7992228C0E6@core3.amsl.com> Date: Fri, 24 Oct 2008 01:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-03.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: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --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 : Specification of the IPFIX File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-03.txt Pages : 57 Date : 2008-10-24 This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.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-file-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-24013325.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Sun Oct 26 09:17:28 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DC23A6A7F; Sun, 26 Oct 2008 09:17:28 -0700 (PDT) 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 6B5713A6A03 for ; Sun, 26 Oct 2008 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-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 7gzkZLRZWhpL for ; Sun, 26 Oct 2008 09:17:25 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 196283A6A7F for ; Sun, 26 Oct 2008 09:17:23 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:74ae:80c2:c31e:5a31]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9QGIbDE087200; Mon, 27 Oct 2008 01:18:37 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 01:12:23 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <49005ED3.8050401@cisco.com> References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> Message-Id: <20081026232018.05C1.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 01:18:37 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Please see in-line. On Thu, 23 Oct 2008 13:24:03 +0200 Benoit Claise wrote: > Kobayashi-san, > > Thank you very much for your review. > Note that the draft excerpts are in this email contained already the > improvements proposed by Brian. > > Dear all, > > > > I did not have enough time for reviewing for the draft in Aug. > > Although the time limit exceeds, I have reviewed the draft. > > > > Please see my questions and comments and so on in lines. > > > > Q1) > > I think that the following condition is configurable choice. > > - One stream treats one Template Record and associated Data Records. > > - One stream treats some Template Records and associated Data Records > > related to same Observation Domain, or same Observation Points. > > It can deduce Data Record Loss per observation domain or observation points. > > Does this draft cover the latter pattern ? > > > Yes, exactly. This is a configurable choice. > > "The Exporter SHOULD send a single Template and corresponding Data Sets > within a single stream in order to enable calculation of the potential > Data Record loss for this Template ID. However, the Exporter MAY group > related Templates and their corresponding Data Sets within a single > stream so that loss statistics are calculated for the group. This is > suitable in cases where there are only slight variations among the > Templates in a group, e.g. the omiFrom ipfix-bounces@ietf.org Sun Oct 26 09:17:28 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DC23A6A7F; Sun, 26 Oct 2008 09:17:28 -0700 (PDT) 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 6B5713A6A03 for ; Sun, 26 Oct 2008 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-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 7gzkZLRZWhpL for ; Sun, 26 Oct 2008 09:17:25 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 196283A6A7F for ; Sun, 26 Oct 2008 09:17:23 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:74ae:80c2:c31e:5a31]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9QGIbDE087200; Mon, 27 Oct 2008 01:18:37 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 01:12:23 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <49005ED3.8050401@cisco.com> References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> Message-Id: <20081026232018.05C1.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 01:18:37 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Please see in-line. On Thu, 23 Oct 2008 13:24:03 +0200 Benoit Claise wrote: > Kobayashi-san, > > Thank you very much for your review. > Note that the draft excerpts are in this email contained already the > improvements proposed by Brian. > > Dear all, > > > > I did not have enough time for reviewing for the draft in Aug. > > Although the time limit exceeds, I have reviewed the draft. > > > > Please see my questions and comments and so on in lines. > > > > Q1) > > I think that the following condition is configurable choice. > > - One stream treats one Template Record and associated Data Records. > > - One stream treats some Template Records and associated Data Records > > related to same Observation Domain, or same Observation Points. > > It can deduce Data Record Loss per observation domain or observation points. > > Does this draft cover the latter pattern ? > > > Yes, exactly. This is a configurable choice. > > "The Exporter SHOULD send a single Template and corresponding Data Sets > within a single stream in order to enable calculation of the potential > Data Record loss for this Template ID. However, the Exporter MAY group > related Templates and their corresponding Data Sets within a single > stream so that loss statistics are calculated for the group. This is > suitable in cases where there are only slight variations among the > Templates in a group, e.g. the ossion of unavailable fields for export > efficiency, and may be necessary if the SCTP association does not > support enough streams to export each Template in its own stream." > I can image following case. In general purposes, IPv4/IPv6 templates and data captured by same metering process and same sampling rate are exported on same sctp stream. On the other hand, specified application data and template which contain additional fields, for different purpose e.g. QoS measurement, are exported on different sctp stream. Templates and data will be grouped according to the purposes or scope of measurement which depend on loss sensitivity. > > > Q2) > > This draft does not describe how to export some statistics option > > template and data. Should they be exported on same stream exporting > > associated Template and Data Records ? > > > Basically, you can choose. To make sure we stress that, I would like to > improve the previous sentence > > "The Exporter SHOULD send a single Template and corresponding Data > Sets within a single stream in order to enable calculation of the > potential Data Record loss for this Template ID. However, the > Exporter MAY group related _(Options) _Templates and their > corresponding Data Sets within a single stream so that loss > statistics are calculated for the group. This is suitable in cases > where there are only slight variations among the Templates in a > group, e.g. the omission of unavailable fields for export > efficiency, and may be necessary if the SCTP association does not > support enough streams to export each Template in its own stream." > > Actually, I meant that statistics reports mentioned on section 4 in RFC5101 are not based on per template. In order to count total loss from observation point to collecting process, some statistics templates in RFC5101 seem to be improved. But, it seems be out of scope of this document.. > However, if you chose to send them within a single stream, then the > following text applies: > > "If a SCTP stream contains a mixture of Data Records defined by a > Template Record and Options Template Record(s), the Data Records > defined by the Options Template Record(s) SHOULD be sent reliably > within the same stream so that the Collector does not consider any > loss to be associated with the options Data Record." > > >> > >> 1. Terminology > >> > >> IPFIX-specific terminology used in this document is defined > >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- > >> specific terms have the first letter of a word capitalized > >> when used in this document. > >> > >> Template Reuse Delay > >> > >> The configurable timeout to allow the Collecting Process > >> to receive and process the last Data Record using this > >> Template information before which the Template Withdrawal > >> Message MUST NOT be sent. [RFC5101] specifies a default > >> value of 5 seconds. > >> > >> > > > > Q3) > > In first reading, I could not understand which process uses this timer, > > Collecting process or Exporting Process. > > I think that the description of RFC5101 is more easily understandable. > > RFC5101 say as follows. > > > > The Template Withdrawal Message MUST NOT be sent until sufficient > > time has elapsed to allow the Collecting Process to receive and > > process the last Data Record using this Template information. > > > Are you fine with Brian's proposal? > > Template Reuse Delay > > The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template. [RFC5101] specifies a default > value of 5 seconds. > Fine. > > > >> 2. Introduction > >> > >> The IPFIX working group has specified a protocol to export IP > >> Flow information [RFC5101]. This protocol is designed to > >mission of unavailable fields for export > efficiency, and may be necessary if the SCTP association does not > support enough streams to export each Template in its own stream." > I can image following case. In general purposes, IPv4/IPv6 templates and data captured by same metering process and same sampling rate are exported on same sctp stream. On the other hand, specified application data and template which contain additional fields, for different purpose e.g. QoS measurement, are exported on different sctp stream. Templates and data will be grouped according to the purposes or scope of measurement which depend on loss sensitivity. > > > Q2) > > This draft does not describe how to export some statistics option > > template and data. Should they be exported on same stream exporting > > associated Template and Data Records ? > > > Basically, you can choose. To make sure we stress that, I would like to > improve the previous sentence > > "The Exporter SHOULD send a single Template and corresponding Data > Sets within a single stream in order to enable calculation of the > potential Data Record loss for this Template ID. However, the > Exporter MAY group related _(Options) _Templates and their > corresponding Data Sets within a single stream so that loss > statistics are calculated for the group. This is suitable in cases > where there are only slight variations among the Templates in a > group, e.g. the omission of unavailable fields for export > efficiency, and may be necessary if the SCTP association does not > support enough streams to export each Template in its own stream." > > Actually, I meant that statistics reports mentioned on section 4 in RFC5101 are not based on per template. In order to count total loss from observation point to collecting process, some statistics templates in RFC5101 seem to be improved. But, it seems be out of scope of this document.. > However, if you chose to send them within a single stream, then the > following text applies: > > "If a SCTP stream contains a mixture of Data Records defined by a > Template Record and Options Template Record(s), the Data Records > defined by the Options Template Record(s) SHOULD be sent reliably > within the same stream so that the Collector does not consider any > loss to be associated with the options Data Record." > > >> > >> 1. Terminology > >> > >> IPFIX-specific terminology used in this document is defined > >> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- > >> specific terms have the first letter of a word capitalized > >> when used in this document. > >> > >> Template Reuse Delay > >> > >> The configurable timeout to allow the Collecting Process > >> to receive and process the last Data Record using this > >> Template information before which the Template Withdrawal > >> Message MUST NOT be sent. [RFC5101] specifies a default > >> value of 5 seconds. > >> > >> > > > > Q3) > > In first reading, I could not understand which process uses this timer, > > Collecting process or Exporting Process. > > I think that the description of RFC5101 is more easily understandable. > > RFC5101 say as follows. > > > > The Template Withdrawal Message MUST NOT be sent until sufficient > > time has elapsed to allow the Collecting Process to receive and > > process the last Data Record using this Template information. > > > Are you fine with Brian's proposal? > > Template Reuse Delay > > The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template. [RFC5101] specifies a default > value of 5 seconds. > Fine. > > > >> 2. Introduction > >> > >> The IPFIX working group has specified a protocol to export IP > >> Flow information [RFC5101]. This protocol is designed to >> export information about IP traffic Flows and related > >> measurement data, where a Flow is defined by a set of key > >> attributes (e.g. source and destination IP address, source > >> and destination port, etc.). However, thanks to its template > >> mechanism, the IPFIX protocol can export any type of > >> information, as long as the relevant Information Element is > >> specified in the IPFIX Information Model [RFC5102], > >> registered with IANA, or specified as an enterprise-specific > >> Information Element. > >> > >> The IPFIX protocol [RFC5101] specifies that IP traffic > >> measurements for Flows are exported using a TLV (type, > >> length, value) format. The information is exported using a > >> Template Record that is sent once to export the {type, > >> length} pairs that define the data format for the Information > >> Elements in a Flow. The Data Records specify values for each > >> Flow. > >> > >> The IPFIX protocol [RFC5101] is flexible: it foresees the usage > >> of the multiple SCTP streams per association; it allows the > >> transmission of Data Sets, Template Sets, and/or Options > >> Template Sets on any stream; it offers the full or partial > >> reliability export of Data Sets; it proposes the ordered or out- > >> of-order delivery of Data Sets. However, due to bandwidth > >> restrictions and packet losses in the network as well as > >> resource constraints on the Exporter and Collector (e.g., > >> limited buffer sizes), it is not always possible to export all > >> Data Sets in a reliable way. > >> > >> > >> Without delving into the details of the specifications described > >> later on in this document, the basic idea is to export the > >> Template Record and its associated Data Sets into a single > >> unique SCTP stream, ideally to limit the Template ID to a single > >> stream, while imposing in-order transmission. > >> > >> The specification in this document offers several advantages > >> such as: calculation of Data Record losses in case of partially- > >> reliable SCTP export, immediate export of the Template > >> Withdrawal Message, immediate reuse of template ID within a > >> stream, reduced likelihood of losing Data Record, and the > >> Collecting Process's job is easier. > >> > > > > Q4) > > This feature seems to be able to be applied to SCTP and PR-SCTP. But, > > Introduction emphasizes the usage of PR-SCTP. What is advantages of > > PR-SCTP situation over normal SCTP ? > > Is it to deduce the loss count related to Template ID ? > > > This draft only applies to PR-SCTP, because SCTP (without PR), will try > to retransmit until it can't anymore and then the SCTP association will > be shutdown. I tried to confirm that from RFC4960 but I couldn't find > the appropriate text. > Furthermore, both SCTP and PR-SCTP are MUST in RFC5101 > Fine. > I propose to improve the abstract, to avoid any confusion > OLD: > > This document specifies an improvement to the export specified in the > IPFIX specifications in RFC5101. > This method offers several advantages such as the ability to calculate > Data Record losses for PR-SCTP, immediate export of Template Withdrawal > Messages, immediate reuse of Template IDs within an SCTP stream, and > reduced demands on the Collecting Process. > > > NEW: > > This document specifies an improvement to the _PR-SCTP_ export specified > in the IPFIX specifications in RFC5101. > This method offers several advantages such as the ability to calculate > Data Record losses for PR-SCTP, immediate export of Template Withdrawal > Messages, immediate reuse of Template IDs within an SCTP stream, and > reduced demands on the Collecting Process. > > >> 4. Specifications > > >> export information about IP traffic Flows and related > >> measurement data, where a Flow is defined by a set of key > >> attributes (e.g. source and destination IP address, source > >> and destination port, etc.). However, thanks to its template > >> mechanism, the IPFIX protocol can export any type of > >> information, as long as the relevant Information Element is > >> specified in the IPFIX Information Model [RFC5102], > >> registered with IANA, or specified as an enterprise-specific > >> Information Element. > >> > >> The IPFIX protocol [RFC5101] specifies that IP traffic > >> measurements for Flows are exported using a TLV (type, > >> length, value) format. The information is exported using a > >> Template Record that is sent once to export the {type, > >> length} pairs that define the data format for the Information > >> Elements in a Flow. The Data Records specify values for each > >> Flow. > >> > >> The IPFIX protocol [RFC5101] is flexible: it foresees the usage > >> of the multiple SCTP streams per association; it allows the > >> transmission of Data Sets, Template Sets, and/or Options > >> Template Sets on any stream; it offers the full or partial > >> reliability export of Data Sets; it proposes the ordered or out- > >> of-order delivery of Data Sets. However, due to bandwidth > >> restrictions and packet losses in the network as well as > >> resource constraints on the Exporter and Collector (e.g., > >> limited buffer sizes), it is not always possible to export all > >> Data Sets in a reliable way. > >> > >> > >> Without delving into the details of the specifications described > >> later on in this document, the basic idea is to export the > >> Template Record and its associated Data Sets into a single > >> unique SCTP stream, ideally to limit the Template ID to a single > >> stream, while imposing in-order transmission. > >> > >> The specification in this document offers several advantages > >> such as: calculation of Data Record losses in case of partially- > >> reliable SCTP export, immediate export of the Template > >> Withdrawal Message, immediate reuse of template ID within a > >> stream, reduced likelihood of losing Data Record, and the > >> Collecting Process's job is easier. > >> > > > > Q4) > > This feature seems to be able to be applied to SCTP and PR-SCTP. But, > > Introduction emphasizes the usage of PR-SCTP. What is advantages of > > PR-SCTP situation over normal SCTP ? > > Is it to deduce the loss count related to Template ID ? > > > This draft only applies to PR-SCTP, because SCTP (without PR), will try > to retransmit until it can't anymore and then the SCTP association will > be shutdown. I tried to confirm that from RFC4960 but I couldn't find > the appropriate text. > Furthermore, both SCTP and PR-SCTP are MUST in RFC5101 > Fine. > I propose to improve the abstract, to avoid any confusion > OLD: > > This document specifies an improvement to the export specified in the > IPFIX specifications in RFC5101. > This method offers several advantages such as the ability to calculate > Data Record losses for PR-SCTP, immediate export of Template Withdrawal > Messages, immediate reuse of Template IDs within an SCTP stream, and > reduced demands on the Collecting Process. > > > NEW: > > This document specifies an improvement to the _PR-SCTP_ export specified > in the IPFIX specifications in RFC5101. > This method offers several advantages such as the ability to calculate > Data Record losses for PR-SCTP, immediate export of Template Withdrawal > Messages, immediate reuse of Template IDs within an SCTP stream, and > reduced demands on the Collecting Process. > > >> 4. Specifications >> > >> 4.1. Template Management > >> > >> This section introduces modifications compared to the Template > >> Management section 8 in [RFC5101]. > >> As specified in [RFC5101], Template Sets and Options Template > >> Sets MUST be sent reliably. In other words, any IPFIX Message > >> containing an (Options) Template Set MUST be sent reliably. > >> > >> Any Data Sets associated with a Template Record MUST be sent on > >> the same stream on which the Template Record was sent. > >> > >> The Exporter SHOULD send a single Template and associated Data > >> Sets within a single stream in order to calculate the potential > >> Data Record loss for this Template ID. However, the Exporter > >> MAY group related Templates and their associated Data Sets > >> within a single stream so loss statistics are calculated for the > >> group. This may be suitable in cases where there is > >> insufficient SCTP streams to send each Template on its own > >> stream and/or the case where there are slight variations on a > >> single Template to show that some fields were unavailable at the > >> time of monitoring. > >> > >> If a SCTP stream contains a mixture of Data Records defined by a > >> Template Record and Options Template Record(s), the Data Records > >> defined by the Options Template Record(s) SHOULD be sent > >> reliably within the same stream so that the Collector does not > >> consider any loss to be associated with the Options Data. > >> Indeed, if the Collector does not have the guarantee that the > >> > > > > Q5) > > It seems Exporter, not Collector. Is it correct? > > > > > The "Collector" was correct, as the loss is calculated from the Collector Reading more, I understood. > >> Data Records defined by the Options Template Record are sent > >> reliably, the Collector can not determine whether the loss in > >> that stream belongs to the Data Records defined by the Template > >> Record, defined by the Option Template Record, or by both of > >> them. By sending the Options Data reliably (which is usually > >> required to interpret the Data Records correctly), any loss will > >> be limited to the non-option Data Record and loss can still be > >> calculated on a per Template basis. > >> > >> For each (Options) Template Record, the Exporting Process MUST > >> send the Data Record Reliability Option Template using an Option > >> Template with the following Information Elements: > >> > >> SCOPE: Template ID > >> NOT-SCOPE: dataRecordsReliability > >> > >> The Data Record Reliability Option Template MUST be sent > >> reliably. > >> > >> > > > > Q6) > > I cannot clearly understand how to use this field > > "dataRecordsReliability". > > "Data Record Reliability Option Template" might be applied to Option > > Template only? > No, to both Template and Options Template. OK. I understood that "Data Record Reliability Option Template" can be applied to both templates, and "dataRecordsReliability" are limited to use only in "Data Record Reliability Option Template". > > How is it handled by Collector for consecutive Data > > Record after receiving the option template? > > If Collector does not receive this template, what's going to happen? > > > If the Collector doesn't receive it, it means that the Exporters don't > support the specifications in this document and then there is no > problem. ;-) > If the Exporters do support these specifications, then Data Record > Reliability Option Template MUST be exported reliably, so the Collector > will receive it. > > We have improved the text and completed the examples. I understood you mentioned. This indicates the notification method of Exporters capabil >> > >> 4.1. Template Management > >> > >> This section introduces modifications compared to the Template > >> Management section 8 in [RFC5101]. > >> As specified in [RFC5101], Template Sets and Options Template > >> Sets MUST be sent reliably. In other words, any IPFIX Message > >> containing an (Options) Template Set MUST be sent reliably. > >> > >> Any Data Sets associated with a Template Record MUST be sent on > >> the same stream on which the Template Record was sent. > >> > >> The Exporter SHOULD send a single Template and associated Data > >> Sets within a single stream in order to calculate the potential > >> Data Record loss for this Template ID. However, the Exporter > >> MAY group related Templates and their associated Data Sets > >> within a single stream so loss statistics are calculated for the > >> group. This may be suitable in cases where there is > >> insufficient SCTP streams to send each Template on its own > >> stream and/or the case where there are slight variations on a > >> single Template to show that some fields were unavailable at the > >> time of monitoring. > >> > >> If a SCTP stream contains a mixture of Data Records defined by a > >> Template Record and Options Template Record(s), the Data Records > >> defined by the Options Template Record(s) SHOULD be sent > >> reliably within the same stream so that the Collector does not > >> consider any loss to be associated with the Options Data. > >> Indeed, if the Collector does not have the guarantee that the > >> > > > > Q5) > > It seems Exporter, not Collector. Is it correct? > > > > > The "Collector" was correct, as the loss is calculated from the Collector Reading more, I understood. > >> Data Records defined by the Options Template Record are sent > >> reliably, the Collector can not determine whether the loss in > >> that stream belongs to the Data Records defined by the Template > >> Record, defined by the Option Template Record, or by both of > >> them. By sending the Options Data reliably (which is usually > >> required to interpret the Data Records correctly), any loss will > >> be limited to the non-option Data Record and loss can still be > >> calculated on a per Template basis. > >> > >> For each (Options) Template Record, the Exporting Process MUST > >> send the Data Record Reliability Option Template using an Option > >> Template with the following Information Elements: > >> > >> SCOPE: Template ID > >> NOT-SCOPE: dataRecordsReliability > >> > >> The Data Record Reliability Option Template MUST be sent > >> reliably. > >> > >> > > > > Q6) > > I cannot clearly understand how to use this field > > "dataRecordsReliability". > > "Data Record Reliability Option Template" might be applied to Option > > Template only? > No, to both Template and Options Template. OK. I understood that "Data Record Reliability Option Template" can be applied to both templates, and "dataRecordsReliability" are limited to use only in "Data Record Reliability Option Template". > > How is it handled by Collector for consecutive Data > > Record after receiving the option template? > > If Collector does not receive this template, what's going to happen? > > > If the Collector doesn't receive it, it means that the Exporters don't > support the specifications in this document and then there is no > problem. ;-) > If the Exporters do support these specifications, then Data Record > Reliability Option Template MUST be exported reliably, so the Collector > will receive it. > > We have improved the text and completed the examples. I understood you mentioned. This indicates the notification method of Exporters capabities. This method can be more generalized for upcoming new features. > > > > >> The Option Data Record SHOULD be sent before the Data Record > >> that needs it so that it arrives first and is available for the > >> Collector to use. > >> > >> > >> > >> > >> > >> 4.5. The Collecting Process's Side > >> > >> This section introduces modifications to the Collection Process > >> as compared to section 9 in [RFC5101]. > >> > >> > >> The Collecting Process SHOULD listen for a new association > >> request from the Exporting Process. The Exporting Process will > >> request a number of streams to use for export: the number of > >> streams SHOULD be equivalent to the number of simultaneous > >> Template Records used in the association. Note that the Template > >> Records don't include the Options Template Records. > >> > >> A Collecting Process SHOULD support the procedure for the > >> addition of an SCTP stream [SCTP-RESET]. > >> > >> The IPFIX protocol has a Sequence Number field in the IPFIX > >> Message header that increases with the number of IPFIX Data > >> Records in the IPFIX Message. A Collector may detect out-of- > >> sequence, dropped, or duplicate IPFIX Messages by tracking the > >> Sequence Number. As this Sequence Number is per SCTP stream, > >> the loss for the Data Records sent in that stream can be > >> calculated in case of partially-reliable export. > >> > >> If the Collecting Process receives a Template Withdrawal Message > >> on a different stream than the one on which the Template ID is > >> used, then the Collecting Process MUST reset the association and > >> SHOULD log an error message. > >> > > > > Q7) > > I think it is difficult to distinguish the session to use the export > > per stream function. Because RFC5101 said the Template Withdrawal > > Message may be sent on any SCTP stream. > > > You're fully right. > We covered that one based on Brian's feedback. > New text: > > If the Collecting Process receives a Template Withdrawal Message on > a different stream than the one on which the Template ID is used, > then the Collecting Process SHOULD log an error message. > Fine. > > > >> > >> The following sentences from [RFC5101] are not applicable in > >> this specification: > >> > >> "The Collecting Process normally receives Template Records > >> from the Exporting Process before receiving Data Records. > >> The Data Records are then decoded and stored by the > >> Collector. If the Template Records have not been received at > >> the time Data Records are received, the Collecting Process > >> MAY store the Data Records for a short period of time and > >> decode them after the Template Records are received." > >> > >> > >> 5. Examples > >> > > > > > > Q8) > > I hope that the examples include "Data Record Reliability Option > > Template". > > > Done. > > > > >> Figure 1 shows an example where the stream 10 carries a Template > >> with the Template ID 256 transmitted with full reliability (FR), > >> together with associated Data Records transmitted with partial > >> reliability (PR). Note that, because all IPFIX Messages are > >> sent in order within a stream, the Template 256 will always be > >> processed before the Data Records by the Collecting Process. > >> Therefore, the Collecting Process job is simplified. > >> Furthermore, the Data Record loss for the Template 256 can > >> easily be calculated on the Collecting Process. > >> > >> > >> +--------+ +---------+ +----------+ > >> ilities. This method can be more generalized for upcoming new features. > > > > >> The Option Data Record SHOULD be sent before the Data Record > >> that needs it so that it arrives first and is available for the > >> Collector to use. > >> > >> > >> > >> > >> > >> 4.5. The Collecting Process's Side > >> > >> This section introduces modifications to the Collection Process > >> as compared to section 9 in [RFC5101]. > >> > >> > >> The Collecting Process SHOULD listen for a new association > >> request from the Exporting Process. The Exporting Process will > >> request a number of streams to use for export: the number of > >> streams SHOULD be equivalent to the number of simultaneous > >> Template Records used in the association. Note that the Template > >> Records don't include the Options Template Records. > >> > >> A Collecting Process SHOULD support the procedure for the > >> addition of an SCTP stream [SCTP-RESET]. > >> > >> The IPFIX protocol has a Sequence Number field in the IPFIX > >> Message header that increases with the number of IPFIX Data > >> Records in the IPFIX Message. A Collector may detect out-of- > >> sequence, dropped, or duplicate IPFIX Messages by tracking the > >> Sequence Number. As this Sequence Number is per SCTP stream, > >> the loss for the Data Records sent in that stream can be > >> calculated in case of partially-reliable export. > >> > >> If the Collecting Process receives a Template Withdrawal Message > >> on a different stream than the one on which the Template ID is > >> used, then the Collecting Process MUST reset the association and > >> SHOULD log an error message. > >> > > > > Q7) > > I think it is difficult to distinguish the session to use the export > > per stream function. Because RFC5101 said the Template Withdrawal > > Message may be sent on any SCTP stream. > > > You're fully right. > We covered that one based on Brian's feedback. > New text: > > If the Collecting Process receives a Template Withdrawal Message on > a different stream than the one on which the Template ID is used, > then the Collecting Process SHOULD log an error message. > Fine. > > > >> > >> The following sentences from [RFC5101] are not applicable in > >> this specification: > >> > >> "The Collecting Process normally receives Template Records > >> from the Exporting Process before receiving Data Records. > >> The Data Records are then decoded and stored by the > >> Collector. If the Template Records have not been received at > >> the time Data Records are received, the Collecting Process > >> MAY store the Data Records for a short period of time and > >> decode them after the Template Records are received." > >> > >> > >> 5. Examples > >> > > > > > > Q8) > > I hope that the examples include "Data Record Reliability Option > > Template". > > > Done. > > > > >> Figure 1 shows an example where the stream 10 carries a Template > >> with the Template ID 256 transmitted with full reliability (FR), > >> together with associated Data Records transmitted with partial > >> reliability (PR). Note that, because all IPFIX Messages are > >> sent in order within a stream, the Template 256 will always be > >> processed before the Data Records by the Collecting Process. > >> Therefore, the Collecting Process job is simplified. > >> Furthermore, the Data Record loss for the Template 256 can > >> easily be calculated on the Collecting Process. > >> > >> > >> +--------+ +---------+ +----------+ > >> | | | | | | > >> stream 10 ----| Data | . . . | Data |---| Template |---> > >> | 256 | | 256 | | 256 | > >> | PR| | PR| | FR| > >> +--------+ +---------+ +----------+ > >> Figure 1 > >> > >> If an Option Template is necessary to understand the content of > >> a Data Record (i.e. the scope in the Options Template Record is > >> an Information Element contained in the Data Record), the > >> Options Template Record may be sent in the same stream, as > >> displayed in figure 2. > >> > >> +--------+ +--------+ +----------+ > >> | | | | | | > >> stream 20 ... ---| Data |...| Data |-----| Template |--- > >> | 258 | | 258 | | 258 | > >> | PR| | PR| | FR| > >> +--------+ +--------+ +----------+ > >> > >> +--------+ +----------+ > >> | | | Options | > >> ...---| Data |-------| Template |------> > >> | 257 | | 257 | > >> | FR| | FR| > >> +--------+ +----------+ > >> Figure 2 > >> > >> Figure 2 shows an example where stream 20 carries an Options > >> Template with Template ID 257 transmitted with full reliability > >> (FR), an associated Data Record transmitted with full > >> reliability (FR), a Template with Template ID 258 transmitted > >> with full reliability (FR), and associated Data Records > >> transmitted with partial reliability (PR). In this example the > >> Option Template Record contains information required to decode > >> the latter Data Records, such as Common Properties information > >> [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 > >> reliably. If some Data Record loss is observed from the > >> Sequence Number , the loss can only stem from the Data Sets with > >> the Template ID 258, as these are the only Sets not exported > >> reliably. Therefore, the calculation of loss per Template ID > >> 258 is possible. > >> > >> > >> Note that, because all IPFIX Messages must be sent in order > >> within a stream, the Options Template 257 will always arrive > >> before its associated Data Records, and that the Template 259 > >> > > > > Q9) > > Is it correct, 259 or 258? > > > 258. Good catch. > > A new draft version will be posted very soon. > Thanks for your feedback. > Thanks, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix | | | | | | > >> stream 10 ----| Data | . . . | Data |---| Template |---> > >> | 256 | | 256 | | 256 | > >> | PR| | PR| | FR| > >> +--------+ +---------+ +----------+ > >> Figure 1 > >> > >> If an Option Template is necessary to understand the content of > >> a Data Record (i.e. the scope in the Options Template Record is > >> an Information Element contained in the Data Record), the > >> Options Template Record may be sent in the same stream, as > >> displayed in figure 2. > >> > >> +--------+ +--------+ +----------+ > >> | | | | | | > >> stream 20 ... ---| Data |...| Data |-----| Template |--- > >> | 258 | | 258 | | 258 | > >> | PR| | PR| | FR| > >> +--------+ +--------+ +----------+ > >> > >> +--------+ +----------+ > >> | | | Options | > >> ...---| Data |-------| Template |------> > >> | 257 | | 257 | > >> | FR| | FR| > >> +--------+ +----------+ > >> Figure 2 > >> > >> Figure 2 shows an example where stream 20 carries an Options > >> Template with Template ID 257 transmitted with full reliability > >> (FR), an associated Data Record transmitted with full > >> reliability (FR), a Template with Template ID 258 transmitted > >> with full reliability (FR), and associated Data Records > >> transmitted with partial reliability (PR). In this example the > >> Option Template Record contains information required to decode > >> the latter Data Records, such as Common Properties information > >> [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 > >> reliably. If some Data Record loss is observed from the > >> Sequence Number , the loss can only stem from the Data Sets with > >> the Template ID 258, as these are the only Sets not exported > >> reliably. Therefore, the calculation of loss per Template ID > >> 258 is possible. > >> > >> > >> Note that, because all IPFIX Messages must be sent in order > >> within a stream, the Options Template 257 will always arrive > >> before its associated Data Records, and that the Template 259 > >> > > > > Q9) > > Is it correct, 259 or 258? > > > 258. Good catch. > > A new draft version will be posted very soon. > Thanks for your feedback. > Thanks, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Oct 26 09:51:22 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A865F3A69F3; Sun, 26 Oct 2008 09:51:22 -0700 (PDT) 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 864253A6A57 for ; Sun, 26 Oct 2008 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, NO_RELAYS=-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 gP+sgXXRPApc for ; Sun, 26 Oct 2008 09:51:20 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 39DCA3A69F3 for ; Sun, 26 Oct 2008 09:51:19 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:74ae:80c2:c31e:5a31]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9QGqe8r087294; Mon, 27 Oct 2008 01:52:45 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 01:46:31 +0900 From: Atsushi Kobayashi To: muenz@net.in.tum.de In-Reply-To: <48F865F1.9060500@informatik.uni-tuebingen.de> References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> Message-Id: <20081027011242.05C4.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 01:52:45 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, > >> linecard => ACL => OP => ... > >> | > >> |--> from here, we are in the scope of IPFIX > >> On second thought, I would not like to limit the scope of IPFIX. It is better that observation point indicates the physical entity e.g. line card, even if ACL applied. Above figure seems more complicated for vendors and operators. > > > > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > > use the given ACL feature. I think that the given ACL feature will be > > used, even if they become IPFIX/PSAMP. But, the given ACL features are > > different style among the several vendors. So, it might be hard to > > standardize them. > > > > From view point of IPFIX configuration, I hope that it would allow some > > vendor to add on ACL feature as enterprise option. Is it possible? > > Yes, vendors can augment the data model with vendor-specific parameters. > Yet, I cannot answer if and how they will do this in the case of ACLs. I prefer that your configuration scheme can include entry point which indicates vendor specific configuration, just like ipfixSelectorFunctions in IPFIX-MIB. Does your configuration allow them? Thanks, Atsushi > > Regards, > Gerhard > > > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Oct 26 09:51:22 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A865F3A69F3; Sun, 26 Oct 2008 09:51:22 -0700 (PDT) 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 864253A6A57 for ; Sun, 26 Oct 2008 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, NO_RELAYS=-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 gP+sgXXRPApc for ; Sun, 26 Oct 2008 09:51:20 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 39DCA3A69F3 for ; Sun, 26 Oct 2008 09:51:19 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:74ae:80c2:c31e:5a31]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9QGqe8r087294; Mon, 27 Oct 2008 01:52:45 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 01:46:31 +0900 From: Atsushi Kobayashi To: muenz@net.in.tum.de In-Reply-To: <48F865F1.9060500@informatik.uni-tuebingen.de> References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> Message-Id: <20081027011242.05C4.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 01:52:45 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, > >> linecard => ACL => OP => ... > >> | > >> |--> from here, we are in the scope of IPFIX > >> On second thought, I would not like to limit the scope of IPFIX. It is better that observation point indicates the physical entity e.g. line card, even if ACL applied. Above figure seems more complicated for vendors and operators. > > > > Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > > use the given ACL feature. I think that the given ACL feature will be > > used, even if they become IPFIX/PSAMP. But, the given ACL features are > > different style among the several vendors. So, it might be hard to > > standardize them. > > > > From view point of IPFIX configuration, I hope that it would allow some > > vendor to add on ACL feature as enterprise option. Is it possible? > > Yes, vendors can augment the data model with vendor-specific parameters. > Yet, I cannot answer if and how they will do this in the case of ACLs. I prefer that your configuration scheme can include entry point which indicates vendor specific configuration, just like ipfixSelectorFunctions in IPFIX-MIB. Does your configuration allow them? Thanks, Atsushi > > Regards, > Gerhard > > > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 27 04:33:03 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2F53A693E; Mon, 27 Oct 2008 04:33:03 -0700 (PDT) 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 0FBC73A693E for ; Mon, 27 Oct 2008 04:33:02 -0700 (PDT) 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=[BAYES_50=0.001, 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 1IfRJk96lOw9 for ; Mon, 27 Oct 2008 04:33:01 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id C7D803A67A3 for ; Mon, 27 Oct 2008 04:33:00 -0700 (PDT) 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 12090DB3; Mon, 27 Oct 2008 12:32:58 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id EEBAE29A4; Mon, 27 Oct 2008 12:32:57 +0100 (CET) Message-ID: <4905A6EF.4080103@net.in.tum.de> Date: Mon, 27 Oct 2008 12:33:03 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> <20081027011242.05C4.17391CF2@nttv6.net> In-Reply-To: <20081027011242.05C4.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: multipart/mixed; boundary="===============1065385403==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1065385403== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080709030503030607060300" This is a cryptographically signed message in MIME format. --------------ms080709030503030607060300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: >>>> linecard =3D> ACL =3D> OP =3D> ... >>>> | >>>> |--> from here, we are in the scope of IPFIX >>>> >=20 > On second thought, I would not like to limit the scope of IPFIX. > It is better that observation point indicates the physical entity e.g. > line card, even if ACL applied. >=20 > Above figure seems more complicated for vendors and operators. >=20 >>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow= >>> use the given ACL feature. I think that the given ACL feature will be= >>> used, even if they become IPFIX/PSAMP. But, the given ACL features ar= e >>> different style among the several vendors. So, it might be hard to >>> standardize them. >>> >>> From view point of IPFIX configuration, I hope that it would allow so= me >>> vendor to add on ACL feature as enterprise option. Is it possible? >> Yes, vendors can augment the data model with vendor-specific parameter= s. >> Yet, I cannot answer if and how they will do this in the case of ACLs.= >=20 > I prefer that your configuration scheme can include entry point which > indicates vendor specific configuration, just like > ipfixSelectorFunctions in IPFIX-MIB. >=20 > Does your configuration allow them? How to extend a standard configuration module with vendor-specific parameters depends on the "world" in which the module is defined. Therefore, we should follow the rules of the world in which we define the configuration model. In the SNMP/MIB world, it is necessary to provide such explicit entry points in the standard MIB modules to enable a linkage to the vendor-specific parameters. In the Netconf/XML world, this is not necessary and not common practice. The NETMOD WG is currently discussing how vendor-specific extensions of and deviations from standard XML modules are realized in the best way using YANG. Regardless of how the solution will finally look like, it very probably will not require any explicit entry points in the standard XML modules. So, I propose to wait for the results of the NETMOD WG regarding this issue. I assume that we finally do not have to modify the IPFIX module because the treatment of vendor-specific changes is solved by the NETMOD = WG. 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 --------------ms080709030503030607060300 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTAyNzExMzMwM1owIwYJKoZIhvcNAQkEMRYEFK4iLE6xuGHB Jv9jay60z6jEsh73MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQA+AG56pzh43pgKMncir1HkIZKxYLEz8wXOKHj/160TKtG+bO0PmGAi85DT PLLiI38MhsJMBKMuDWmQJ+oZniE0Tp5hk93ExwY+YPd7g1GwnyB2mHEyEWt9qu2XRADukpoG q85MZXGFaHyqs0paUfQrXNJqw+WwLyX4wR8UvCpylQvySdci7fXzQaF3nV5urMm44nxfpnV+ CHX+ghdqogqNuvhH8q2sjqHr3//n51ty4pmgKiGXofJF2SbLtYz3v/Q2nRXcV6obcunAn09F AzNWOPpf6lqAWRfM9mr1N6bcsMqqpCQa9AG8ve2PBf7kDDlyFyMCX6mzKEwxyAdCCXiKAAAA AAAA --------------ms080709030503030607060300-- --===============1065385403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1065385403==-- From ipfix-bounces@ietf.org Mon Oct 27 04:33:03 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2F53A693E; Mon, 27 Oct 2008 04:33:03 -0700 (PDT) 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 0FBC73A693E for ; Mon, 27 Oct 2008 04:33:02 -0700 (PDT) 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=[BAYES_50=0.001, 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 1IfRJk96lOw9 for ; Mon, 27 Oct 2008 04:33:01 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id C7D803A67A3 for ; Mon, 27 Oct 2008 04:33:00 -0700 (PDT) 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 12090DB3; Mon, 27 Oct 2008 12:32:58 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id EEBAE29A4; Mon, 27 Oct 2008 12:32:57 +0100 (CET) Message-ID: <4905A6EF.4080103@net.in.tum.de> Date: Mon, 27 Oct 2008 12:33:03 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> <20081027011242.05C4.17391CF2@nttv6.net> In-Reply-To: <20081027011242.05C4.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: multipart/mixed; boundary="===============1065385403==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1065385403== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080709030503030607060300" This is a cryptographically signed message in MIME format. --------------ms080709030503030607060300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: >>>> linecard =3D> ACL =3D> OP =3D> ... >>>> | >>>> |--> from here, we are in the scope of IPFIX >>>> >=20 > On second thought, I would not like to limit the scope of IPFIX. > It is better that observation point indicates the physical entity e.g. > line card, even if ACL applied. >=20 > Above figure seems more complicated for vendors and operators. >=20 >>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow= >>> use the given ACL feature. I think that the given ACL feature will be= >>> used, even if they become IPFIX/PSAMP. But, the given ACL features ar= e >>> different style among the several vendors. So, it might be hard to >>> standardize them. >>> >>> From view point of IPFIX configuration, I hope that it would allow so= me >>> vendor to add on ACL feature as enterprise option. Is it possible? >> Yes, vendors can augment the data model with vendor-specific parameter= s. >> Yet, I cannot answer if and how they will do this in the case of ACLs.= >=20 > I prefer that your configuration scheme can include entry point which > indicates vendor specific configuration, just like > ipfixSelectorFunctions in IPFIX-MIB. >=20 > Does your configuration allow them? How to extend a standard configuration module with vendor-specific parameters depends on the "world" in which the module is defined. Therefore, we should follow the rules of the world in which we define the configuration model. In the SNMP/MIB world, it is necessary to provide such explicit entry points in the standard MIB modules to enable a linkage to the vendor-specific parameters. In the Netconf/XML world, this is not necessary and not common practice. The NETMOD WG is currently discussing how vendor-specific extensions of and deviations from standard XML modules are realized in the best way using YANG. Regardless of how the solution will finally look like, it very probably will not require any explicit entry points in the standard XML modules. So, I propose to wait for the results of the NETMOD WG regarding this issue. I assume that we finally do not have to modify the IPFIX module because the treatment of vendor-specific changes is solved by the NETMOD = WG. 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 --------------ms080709030503030607060300 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTAyNzExMzMwM1owIwYJKoZIhvcNAQkEMRYEFK4iLE6xuGHB Jv9jay60z6jEsh73MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQA+AG56pzh43pgKMncir1HkIZKxYLEz8wXOKHj/160TKtG+bO0PmGAi85DT PLLiI38MhsJMBKMuDWmQJ+oZniE0Tp5hk93ExwY+YPd7g1GwnyB2mHEyEWt9qu2XRADukpoG q85MZXGFaHyqs0paUfQrXNJqw+WwLyX4wR8UvCpylQvySdci7fXzQaF3nV5urMm44nxfpnV+ CHX+ghdqogqNuvhH8q2sjqHr3//n51ty4pmgKiGXofJF2SbLtYz3v/Q2nRXcV6obcunAn09F AzNWOPpf6lqAWRfM9mr1N6bcsMqqpCQa9AG8ve2PBf7kDDlyFyMCX6mzKEwxyAdCCXiKAAAA AAAA --------------ms080709030503030607060300-- --===============1065385403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1065385403==-- From ipfix-bounces@ietf.org Mon Oct 27 05:49:23 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4223A6A7B; Mon, 27 Oct 2008 05:49:23 -0700 (PDT) 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 841CB3A6A7C for ; Mon, 27 Oct 2008 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 2qRebrRuqkRs for ; Mon, 27 Oct 2008 05:49:21 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 07DBD3A6A78 for ; Mon, 27 Oct 2008 05:49:20 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:89af:8b9a:529e:4209]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9RCnJX8005205; Mon, 27 Oct 2008 21:49:19 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 21:43:03 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4905A6EF.4080103@net.in.tum.de> References: <20081027011242.05C4.17391CF2@nttv6.net> <4905A6EF.4080103@net.in.tum.de> Message-Id: <20081027212304.A9A3.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 21:49:19 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Thank you for reply. I understood what you want to say. It will take long term to find some solution, as you mentioned. I regret that we must wait them, although some commercial products will release the acl based flow product more and more. Because your configuration scheme can be utilized in the Flow world immediately. Regards, Atsushi On Mon, 27 Oct 2008 12:33:03 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > >>>> linecard => ACL => OP => ... > >>>> | > >>>> |--> from here, we are in the scope of IPFIX > >>>> > > > > On second thought, I would not like to limit the scope of IPFIX. > > It is better that observation point indicates the physical entity e.g. > > line card, even if ACL applied. > > > > Above figure seems more complicated for vendors and operators. > > > >>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > >>> use the given ACL feature. I think that the given ACL feature will be > >>> used, even if they become IPFIX/PSAMP. But, the given ACL features are > >>> different style among the several vendors. So, it might be hard to > >>> standardize them. > >>> > >>> From view point of IPFIX configuration, I hope that it would allow some > >>> vendor to add on ACL feature as enterprise option. Is it possible? > >> Yes, vendors can augment the data model with vendor-specific parameters. > >> Yet, I cannot answer if and how tFrom ipfix-bounces@ietf.org Mon Oct 27 05:49:23 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4223A6A7B; Mon, 27 Oct 2008 05:49:23 -0700 (PDT) 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 841CB3A6A7C for ; Mon, 27 Oct 2008 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 2qRebrRuqkRs for ; Mon, 27 Oct 2008 05:49:21 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 07DBD3A6A78 for ; Mon, 27 Oct 2008 05:49:20 -0700 (PDT) Received: from localhost ([IPv6:2001:fa8:1000:0:89af:8b9a:529e:4209]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9RCnJX8005205; Mon, 27 Oct 2008 21:49:19 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Oct 2008 21:43:03 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4905A6EF.4080103@net.in.tum.de> References: <20081027011242.05C4.17391CF2@nttv6.net> <4905A6EF.4080103@net.in.tum.de> Message-Id: <20081027212304.A9A3.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 27 Oct 2008 21:49:19 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Thank you for reply. I understood what you want to say. It will take long term to find some solution, as you mentioned. I regret that we must wait them, although some commercial products will release the acl based flow product more and more. Because your configuration scheme can be utilized in the Flow world immediately. Regards, Atsushi On Mon, 27 Oct 2008 12:33:03 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > >>>> linecard => ACL => OP => ... > >>>> | > >>>> |--> from here, we are in the scope of IPFIX > >>>> > > > > On second thought, I would not like to limit the scope of IPFIX. > > It is better that observation point indicates the physical entity e.g. > > line card, even if ACL applied. > > > > Above figure seems more complicated for vendors and operators. > > > >>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow > >>> use the given ACL feature. I think that the given ACL feature will be > >>> used, even if they become IPFIX/PSAMP. But, the given ACL features are > >>> different style among the several vendors. So, it might be hard to > >>> standardize them. > >>> > >>> From view point of IPFIX configuration, I hope that it would allow some > >>> vendor to add on ACL feature as enterprise option. Is it possible? > >> Yes, vendors can augment the data model with vendor-specific parameters. > >> Yet, I cannot answer if and howhey will do this in the case of ACLs. > > > > I prefer that your configuration scheme can include entry point which > > indicates vendor specific configuration, just like > > ipfixSelectorFunctions in IPFIX-MIB. > > > > Does your configuration allow them? > > How to extend a standard configuration module with vendor-specific > parameters depends on the "world" in which the module is defined. > Therefore, we should follow the rules of the world in which we define > the configuration model. > > In the SNMP/MIB world, it is necessary to provide such explicit entry > points in the standard MIB modules to enable a linkage to the > vendor-specific parameters. > > In the Netconf/XML world, this is not necessary and not common practice. > The NETMOD WG is currently discussing how vendor-specific extensions of > and deviations from standard XML modules are realized in the best way > using YANG. Regardless of how the solution will finally look like, it > very probably will not require any explicit entry points in the standard > XML modules. > > So, I propose to wait for the results of the NETMOD WG regarding this > issue. I assume that we finally do not have to modify the IPFIX module > because the treatment of vendor-specific changes is solved by the NETMOD WG. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, 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 > > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix they will do this in the case of ACLs. > > > > I prefer that your configuration scheme can include entry point which > > indicates vendor specific configuration, just like > > ipfixSelectorFunctions in IPFIX-MIB. > > > > Does your configuration allow them? > > How to extend a standard configuration module with vendor-specific > parameters depends on the "world" in which the module is defined. > Therefore, we should follow the rules of the world in which we define > the configuration model. > > In the SNMP/MIB world, it is necessary to provide such explicit entry > points in the standard MIB modules to enable a linkage to the > vendor-specific parameters. > > In the Netconf/XML world, this is not necessary and not common practice. > The NETMOD WG is currently discussing how vendor-specific extensions of > and deviations from standard XML modules are realized in the best way > using YANG. Regardless of how the solution will finally look like, it > very probably will not require any explicit entry points in the standard > XML modules. > > So, I propose to wait for the results of the NETMOD WG regarding this > issue. I assume that we finally do not have to modify the IPFIX module > because the treatment of vendor-specific changes is solved by the NETMOD WG. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, 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 > > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 27 08:31:37 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADED33A6A7B; Mon, 27 Oct 2008 08:31:37 -0700 (PDT) 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 3E87C3A6A34 for ; Mon, 27 Oct 2008 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 7tkvwQl9i5Ce for ; Mon, 27 Oct 2008 08:31:35 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 769113A69FC for ; Mon, 27 Oct 2008 08:31:35 -0700 (PDT) Received: (qmail 94052 invoked from network); 27 Oct 2008 15:31:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 27 Oct 2008 15:31:11 -0000 X-YMail-OSG: HJ8fHYUVM1nkMtHocT1DyURXJP.T9ikYWwZ_kL1w.JUCmMyddW4wfAvWFygGWEZDFDCU2eIrkSNm82ob96jS13iM0wUHvVT2Gq6VrAV4AaaR8tyZzMefEPo4nFp3XN7dtb4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4905DEBC.1040807@netconfcentral.com> Date: Mon, 27 Oct 2008 08:31:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Gerhard Muenz References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> <20081027011242.05C4.17391CF2@nttv6.net> <4905A6EF.4080103@net.in.tum.de> In-Reply-To: <4905A6EF.4080103@net.in.tum.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard Muenz wrote: > Hi Atsushi, > > Atsushi Kobayashi wrote: >>>>> linecard => ACL => OP => ... >>>>> | >>>>> |--> from here, we are in the scope of IPFIX >>>>> >> On second thought, I would not like to limit the scope of IPFIX. >> It is better that observation point indicates the physical entity e.g. >> line card, even if ACL applied. >> >> Above figure seems more complicated for vendors and operators. >> >>>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow >>>> use the given ACL feature. I think that the given ACL feature will be >>>> used, even if they become IPFIX/PSAMP. But, the given ACL features are >>>> different style among the several vendors. So, it might be hard to >>>> standardize them. >>>> >>>> From view point of IPFIX configuration, I hope that it would allow some >>>> vendor to add on ACL feature as enterprise option. Is it possible? >>> Yes, vendors can augment the data model with vendor-specific parameters. >>> Yet, I cannot answer if and how they will do this in the case of ACLs. >> I prefer that your configuration scheme can include entry point which >> indicates vendor specific configuration, just like >> ipfixSelectorFunctions in IPFIX-MIB. >> >> Does your configuratioFrom ipfix-bounces@ietf.org Mon Oct 27 08:31:37 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADED33A6A7B; Mon, 27 Oct 2008 08:31:37 -0700 (PDT) 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 3E87C3A6A34 for ; Mon, 27 Oct 2008 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 7tkvwQl9i5Ce for ; Mon, 27 Oct 2008 08:31:35 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 769113A69FC for ; Mon, 27 Oct 2008 08:31:35 -0700 (PDT) Received: (qmail 94052 invoked from network); 27 Oct 2008 15:31:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 27 Oct 2008 15:31:11 -0000 X-YMail-OSG: HJ8fHYUVM1nkMtHocT1DyURXJP.T9ikYWwZ_kL1w.JUCmMyddW4wfAvWFygGWEZDFDCU2eIrkSNm82ob96jS13iM0wUHvVT2Gq6VrAV4AaaR8tyZzMefEPo4nFp3XN7dtb4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4905DEBC.1040807@netconfcentral.com> Date: Mon, 27 Oct 2008 08:31:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Gerhard Muenz References: <20081017095407.198E.17391CF2@nttv6.net> <48F865F1.9060500@informatik.uni-tuebingen.de> <20081027011242.05C4.17391CF2@nttv6.net> <4905A6EF.4080103@net.in.tum.de> In-Reply-To: <4905A6EF.4080103@net.in.tum.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard Muenz wrote: > Hi Atsushi, > > Atsushi Kobayashi wrote: >>>>> linecard => ACL => OP => ... >>>>> | >>>>> |--> from here, we are in the scope of IPFIX >>>>> >> On second thought, I would not like to limit the scope of IPFIX. >> It is better that observation point indicates the physical entity e.g. >> line card, even if ACL applied. >> >> Above figure seems more complicated for vendors and operators. >> >>>> Yes. Actually, Cisco NetFlow input filter and Foundry ACL based sFlow >>>> use the given ACL feature. I think that the given ACL feature will be >>>> used, even if they become IPFIX/PSAMP. But, the given ACL features are >>>> different style among the several vendors. So, it might be hard to >>>> standardize them. >>>> >>>> From view point of IPFIX configuration, I hope that it would allow some >>>> vendor to add on ACL feature as enterprise option. Is it possible? >>> Yes, vendors can augment the data model with vendor-specific parameters. >>> Yet, I cannot answer if and how they will do this in the case of ACLs. >> I prefer that your configuration scheme can include entry point which >> indicates vendor specific configuration, just like >> ipfixSelectorFunctions in IPFIX-MIB. >> >> Does your configuratn allow them? > > How to extend a standard configuration module with vendor-specific > parameters depends on the "world" in which the module is defined. > Therefore, we should follow the rules of the world in which we define > the configuration model. > > In the SNMP/MIB world, it is necessary to provide such explicit entry > points in the standard MIB modules to enable a linkage to the > vendor-specific parameters. > This is not correct. If the standard MIB module has a 'fooEntry', then any vendor module can AUGMENT fooEntry. There are no changes to the original module needed at all for this to work. The same will be true for YANG. > In the Netconf/XML world, this is not necessary and not common practice. > The NETMOD WG is currently discussing how vendor-specific extensions of > and deviations from standard XML modules are realized in the best way > using YANG. Regardless of how the solution will finally look like, it > very probably will not require any explicit entry points in the standard > XML modules. > > So, I propose to wait for the results of the NETMOD WG regarding this > issue. I assume that we finally do not have to modify the IPFIX module > because the treatment of vendor-specific changes is solved by the NETMOD WG. > > Regards, > Gerhard > > Andy _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ion allow them? > > How to extend a standard configuration module with vendor-specific > parameters depends on the "world" in which the module is defined. > Therefore, we should follow the rules of the world in which we define > the configuration model. > > In the SNMP/MIB world, it is necessary to provide such explicit entry > points in the standard MIB modules to enable a linkage to the > vendor-specific parameters. > This is not correct. If the standard MIB module has a 'fooEntry', then any vendor module can AUGMENT fooEntry. There are no changes to the original module needed at all for this to work. The same will be true for YANG. > In the Netconf/XML world, this is not necessary and not common practice. > The NETMOD WG is currently discussing how vendor-specific extensions of > and deviations from standard XML modules are realized in the best way > using YANG. Regardless of how the solution will finally look like, it > very probably will not require any explicit entry points in the standard > XML modules. > > So, I propose to wait for the results of the NETMOD WG regarding this > issue. I assume that we finally do not have to modify the IPFIX module > because the treatment of vendor-specific changes is solved by the NETMOD WG. > > Regards, > Gerhard > > Andy _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Oct 28 20:16:42 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E3D3A69FE; Tue, 28 Oct 2008 20:16:42 -0700 (PDT) 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 9AB4D3A6966 for ; Tue, 28 Oct 2008 20:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iivPy08ORVIx for ; Tue, 28 Oct 2008 20:16:40 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 7EC2B3A6880 for ; Tue, 28 Oct 2008 20:16:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4AE024821B9 for ; Wed, 29 Oct 2008 16:16:37 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9kkd9+kcQ36 for ; Wed, 29 Oct 2008 16:16:37 +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 254A24821B6 for ; Wed, 29 Oct 2008 16:16:36 +1300 (NZDT) Message-ID: <4907D593.3040008@auckland.ac.nz> Date: Wed, 29 Oct 2008 16:16:35 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] First Draft of agenda for Minneaoplis 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Here's a draft agenda for or WG session in Minneapolis. Please send me any comments/suggestions/corrections. You'll note that we have a 2.5h time slot, so there's time for some more drafts to discuss ... 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 #73, Minneapolis Wednesday, 19 Nov 08 at 0900-1130 ====================================================== Chairs: Nevil Brownlee Juergen Quittek 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 [Paul Aitken] Oct 08 3. Information Element Registry status = 5 min IANA are working on an XML page for this, it will have the IEs from RFC 5102 and draft-aitken-ipfix-new-infos-01.txt 3. Drafts from the old charter .. = 10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-04.txt Jul 08 4. New WG drafts = 60 min a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-03.txt Oct 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt Jul 08 ( 5 min) c) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-00.txt d) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-00.txt e) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) - draft-ietf-ipfix-mediators-problem-statement-01.txt - draft-ietf-ipfix-mediators-framework-00.txt (35 min) 5. Milestone review =10 min 6. Any Other Drafts ??? =25 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=73 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Oct 28 20:16:42 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E3D3A69FE; Tue, 28 Oct 2008 20:16:42 -0700 (PDT) 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 9AB4D3A6966 for ; Tue, 28 Oct 2008 20:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iivPy08ORVIx for ; Tue, 28 Oct 2008 20:16:40 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 7EC2B3A6880 for ; Tue, 28 Oct 2008 20:16:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4AE024821B9 for ; Wed, 29 Oct 2008 16:16:37 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9kkd9+kcQ36 for ; Wed, 29 Oct 2008 16:16:37 +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 254A24821B6 for ; Wed, 29 Oct 2008 16:16:36 +1300 (NZDT) Message-ID: <4907D593.3040008@auckland.ac.nz> Date: Wed, 29 Oct 2008 16:16:35 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] First Draft of agenda for Minneaoplis 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Here's a draft agenda for or WG session in Minneapolis. Please send me any comments/suggestions/corrections. You'll note that we have a 2.5h time slot, so there's time for some more drafts to discuss ... 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 #73, Minneapolis Wednesday, 19 Nov 08 at 0900-1130 ====================================================== Chairs: Nevil Brownlee Juergen Quittek 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 [Paul Aitken] Oct 08 3. Information Element Registry status = 5 min IANA are working on an XML page for this, it will have the IEs from RFC 5102 and draft-aitken-ipfix-new-infos-01.txt 3. Drafts from the old charter .. = 10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-04.txt Jul 08 4. New WG drafts = 60 min a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-03.txt Oct 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt Jul 08 ( 5 min) c) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-00.txt d) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-00.txt e) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) - draft-ietf-ipfix-mediators-problem-statement-01.txt - draft-ietf-ipfix-mediators-framework-00.txt (35 min) 5. Milestone review =10 min 6. Any Other Drafts ??? =25 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=73 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 31 05:59:06 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3943A6BEB; Fri, 31 Oct 2008 05:59:06 -0700 (PDT) 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 4F2B63A6BEA for ; Fri, 31 Oct 2008 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4inFyOTaEjrP for ; Fri, 31 Oct 2008 05:59:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B95443A6AFD for ; Fri, 31 Oct 2008 05:59:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 256512C0008DF; Fri, 31 Oct 2008 13:58:52 +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 L72CiXfwE9Tp; Fri, 31 Oct 2008 13:58:52 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id ECD682C0004DA; Fri, 31 Oct 2008 13:58:26 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 31 Oct 2008 13:58:21 +0100 Message-ID: <547F018265F92642B577B986577D671C441471@VENUS.office> In-Reply-To: <48B7C105.8070708@informatik.uni-tuebingen.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 Thread-Index: AckJuY4MXkc8ewWeSQCFZlpJ+dtAZgxhKqww References: <48B7C105.8070708@informatik.uni-tuebingen.de> From: "Thomas Dietz" To: "Gerhard Muenz" , Cc: Nevil Brownlee , Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 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: , Content-Type: multipart/mixed; boundary="===============1111889455==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============1111889455== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0098_01C93B60.BBB1CA20" This is a multipart message in MIME format. ------=_NextPart_000_0098_01C93B60.BBB1CA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gerhard, sorry for the late reply. See my comments inline... --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bouncesFrom ipfix-bounces@ietf.org Fri Oct 31 05:59:06 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3943A6BEB; Fri, 31 Oct 2008 05:59:06 -0700 (PDT) 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 4F2B63A6BEA for ; Fri, 31 Oct 2008 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4inFyOTaEjrP for ; Fri, 31 Oct 2008 05:59:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B95443A6AFD for ; Fri, 31 Oct 2008 05:59:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 256512C0008DF; Fri, 31 Oct 2008 13:58:52 +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 L72CiXfwE9Tp; Fri, 31 Oct 2008 13:58:52 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id ECD682C0004DA; Fri, 31 Oct 2008 13:58:26 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 31 Oct 2008 13:58:21 +0100 Message-ID: <547F018265F92642B577B986577D671C441471@VENUS.office> In-Reply-To: <48B7C105.8070708@informatik.uni-tuebingen.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 Thread-Index: AckJuY4MXkc8ewWeSQCFZlpJ+dtAZgxhKqww References: <48B7C105.8070708@informatik.uni-tuebingen.de> From: "Thomas Dietz" To: "Gerhard Muenz" , Cc: Nevil Brownlee , Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 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: , Content-Type: multipart/mixed; boundary="===============1111889455==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============1111889455== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0098_01C93B60.BBB1CA20" This is a multipart message in MIME format. ------=_NextPart_000_0098_01C93B60.BBB1CA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gerhard, sorry for the late reply. See my comments inline... --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounc@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Gerhard Muenz > Sent: Freitag, 29. August 2008 11:28 > To: ipfix@ietf.org > Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 >=20 >=20 > Dear all, >=20 > Please find comments on draft-ietf-ipfix-mib-04 below. >=20 > Currently, we have ipfixTransportSessionTable which does not provide > any > information about the role of the given device within the transport > session. We do not know if the device is exporter or collector. >=20 > On the other hand, you define "directional" tables for the Templates: > ipfixExportedTemplateTable > ipfixExportedTemplateDefinitionTable > ipfixCollectedTemplateTable > ipfixCollectedTemplateDefinitionTable >=20 > Is there any specific reason? >=20 Yes there is... see below > There are two alternatives which require fewer tables: > 1) One could add an entry about the role of the device to the > ipfixTransportSessionTable, for example in form of a field with values > "exporter" and "collector". As the Templates are scoped to a given > Transport Session, it is clear which Templates are exported and which > Templates are collected. So we would have only three tables instead of > five: > ipfixTransportSessionTable > ipfixTemplateTable > ipfixTemplateDefinitionTable >=20 That the way we had it before, more or less. The problem is that a = device potentially can be a collector and an exporter at the same time. We = could collect a template with a Observation domain x and a template id y which = is not necessarily the same as the template with observation domain x and template id y that we export. The template Ids are only unique at the exporting device. The same is true for the observation domain ids. So = having one table for the templates (ipfixTemplateTable) und in consequence for = the template definitions (ipfixTemplateDefinitionTable) does not work. > 2) Or, one could split the ipfixTransportSessionTable into: > - ipfixOutgoingTransportSessionTable for Transport Sessions where the > given device is exporter. > - ipfixIncomingTransportSessionTable for Transport Sessions where the > given device is collector. > Again, we only need two tables for the Templates: > ipfixTemplateTable > ipfixTemplateDefinitionTable >=20 We could split the transport session table into 2 but for the reason explained above we still cannot collapse the template and template definition table into one. But I don't see the point why to split the transport session table without gaining anything. > Reducing the number of tables is certainly not a design goal for MIBs. > However, I think that it is more logical to have the information of = the > device role (exporter and collector) together with the data about the > Transport Session. >=20 > > 5.3. The Template Tables > > > > There are two Template tables, the Exported Template > > (ipfixExportedTemplateTable) table and the Collected Template > table > > (ipfixCollectedTemplateTable). Those Template tables list all > > Templates (including Option Templates) that are sent (by an > Exporter) > > or received (by a Collector). The (Option) Templates are unique > per > > Transport Session and Observation Domain, thus the table is > indexed > > by the Transport Session Index (ipfixTransportSessionIndex) and > the > > Observation Domain Id (ipfixExportedObservationDomainId or > > ipfixCollectedObservationDomainId). It contains the Set Id and = an >=20 > I propose to list the indices in a clearer way one below the other: >=20 > The (Option) Templates are unique per > Transport Session and Observation Domain, thus the table is = indexed > by the following indices: > - Transport Session Index (ipfixTransportSessionIndex) > - Observation Domain Id (ipfixExportedObservationDomainId or > ipfixCollectedObservationDomainId). >=20 > With two indices, explaining them in the text may still be ok. But you > have much longer lists of indices for the other Tables. >=20 I will try to do that where applicable. > > Access Time denoting the time when the (Option) Template was last > > sent or received. > > > > To resume the above example the Exporter may want to export the a >=20 > remove "the" or "a" >=20 > > Template and an Option Template for each Transport Session = defined > > above. This leads to the following Template Table defining > Template > > and Option Template: > > > > ipfixExportedTemplateTable (3) > > | > > +- ipfixExportedTemplateEntry (1) > > | > > +- index (5) > > | +- index (3) > > | + index (257) >=20 > It is difficult to deduce the meaning of the indices. Maybe add in > brackets which index refers to what: >=20 > +- index (5) (ipfixTransportSessionIndex) > | +- index (3) (ipfixExportedObservationDomainId) > | + index (257) (ipfixExportedTemplateId) >=20 >=20 Good idea, I will add this. > > | | +- ipfixExportedObservationDomainId (1) =3D 3 > > | | +- ipfixExportedTemplateId (2) =3D 257 > > | | +- ipfixExportedTemplateSetId (3) =3D 2 > > | | +- ipfixExportedTemplateAccessTime (4) > > | | =3D = 2008-7-1,12:49:11.2,+2:0 > > | | > > | + index (264) > > | +- ipfixExportedObservationDomainId (1) =3D 3 > > | +- ipfixExportedTemplateId (2) =3D 264 > > | +- ipfixExportedTemplateSetId (3) =3D 3 > > | +- ipfixExportedTemplateAccessTime (4) > > . =3D = 2008-7-1,12:47:04.8,+2:0 > > . > > . > > . > > +- index (11) > > +- index (3) > > + index (273) > > | +- ipfixExportedObservationDomainId (1) =3D 3 > > | +- ipfixExportedTemplateId (2) =3D 273 > > | +- ipfixExportedTemplateSetId (3) =3D 2 > > | +- ipfixExportedTemplateAccessTime (4) > > | =3D = 2008-7-1,12:49:11.2,+2:0 > > | > > + index (289) > > +- ipfixExportedObservationDomainId (1) =3D 3 > > +- ipfixExportedTemplateId (2) =3D 289 > > +- ipfixExportedTemplateSetId (3) =3D 3 > > +- ipfixExportedTemplateAccessTime (4) > > =3D = 2008-7-1,12:47:04.8,+2:0 > > > > We assume that the Collector with index 5 in the Transport = Session > > table of the Exporter has stored the connection to the Exporter > with > > the Transport Session index of 17 then its Template table would > look > > as follows: >=20 > The sentence is confusing. The Transport Session tables does not > contain > any entry called Collector, only > ipfixTransportSessionDestinationAddress > and ipfixTransportSessionDestinationPort. >=20 > Maybe: > We assume that the Transport Session that is stored with index 5 in = the > Transport Session table of the Exporter is stored with index 17 in the > Transport Session table of the (corresponding) Collector. Then, the > Template table would look as follows: >=20 Good point again here. >=20 > > 5.4. The Template Definition Tables > > > > As with the Template tables there are two Template Definition > tables, > > the Exported Template Definition table > > (ipfixExportedTemplateDefinitionTable) and the Collected Template > > Definition table (ipfixCollectedTemplateDefinitionTable). Those > > tables list all the Information Elements contained in a Template > or > > Option Template. Therefore it has the same indexes as the > > corresponding Template table plus the Template Id. Its own index > > denotes the order of the Information Element inside the Template > if > > necessary. Besides the Information Element Id and the length of > the > > encoded value the table contains flags for each Information > Element. > > The flags indicate if the Information Element is used for scoping > or > > as a Flow key. >=20 > What about enterprise-specific IEs? Don't we need an enterprise number > entry? >=20 Wow, you are right! Nobody noticed that before. It's a quick fix that = I'll do. > > 5.5. The Export Table > > > > On Exporters, the Export table (ipfixExportTable) can be used to > > support features like failover, load-balancing, duplicate export > to > > several Collectors etc. The table has 5 indexes that link an > entry > > with the Metering Process table (ipfixMeteringProcessCacheId, see > > below), the Exported Template table > (ipfixExportedObservationDomainId > > and ipfixExportedTemplateId) and the Transport Session table > > (ipfixTransportSessionIndex). Those entries with the same >=20 > Is there a reason for not ordering the indexes as they appear in the > MIB? >=20 No, but I shifted the forward and backward but it seems that I forgot to correct it in the text. > > ipfixExportIndex, the same ipfixMeteringProcessCacheId and the > same > > ipfixExportedObservationDomainId define a Transport Session = group. > > This also The member type for each group member describes its >=20 > remove "This also" >=20 > > functionality. >=20 > Why is a Transport Session group restricted to the output of a single > cache? Because that's what a transport session group is for. Export from a = single cache to different destinations in different configurations. Primary/Secondary for failover, in Parallel, ... >=20 > > If the Exporter does not use Transport Session grouping then each > > ipfixExportIndex contains a single ipfixMeteringProcessCacheId = and >=20 > ipfixTransportSessionIndex? I can add that, but Transport Session implies ipfixTransportSessionIndex >=20 > > thus a singe Transport Session and this session MUST have the > member >=20 > single >=20 > > type primary(1). >=20 > > To continue the example we assume that the Exporter uses the 2 >=20 > two >=20 > > connections shown in the examples above as the primary export for > a > > session protected by a secondary backup connection. The Exporter > > then has the following entries in the ipfixExportTable: > > > > ipfixExportTable (3) > > | > > +- ipfixExportEntry (1) > > | > > +- index (7) > > | +- index (9) > > | +- index (3) > > | +- index (257) > > | | +- index (5) > > | | +- ipfixExportIndex (1) =3D 7 > > | | +- ipfixExportMemberType (2) =3D 1 (primary) > > | | > > | +- index (273) > > | +- index (11) > > | +- ipfixExportIndex (1) =3D 7 > > | +- ipfixExportMemberType (2) =3D 2 (secondary) > > | > > +- index (8) > > +- index (9) > > +- index (3) > > +- index (264) > > | +- index (5) > > | +- ipfixExportIndex (1) =3D 8 > > | +- ipfixExportMemberType (2) =3D 2 (secondary) > > +- index (289) > > +- index (11) > > +- ipfixExportIndex (1) =3D 7 >=20 > 8? >=20 > > +- ipfixExportMemberType (2) =3D 1 (primary) >=20 > Can you explain this example? >=20 > There are two Metering Processes? And the output is sent to different > primary collectors? And in case of a failure, each collector serves as > backup for the other? Absolutely right. So what do I need to explain??? Sure that = configuration may not be really useful but you have the possibility to do it. >=20 > > 5.6. The Metering Process Table > > > > The Metering Process as defined in [RFC5101] consists of a set of > > function. Maintaining the Flow Records is one of them. This > > function is responsible for passing the Flow Records to the > Exporting > > Process but also for detecting Flow expiration. The Flow Records >=20 > "but also" =3D> "and also" >=20 > > that are maintained by the Metering Process can be grouped by the > > Observation Points they are observed. The instance that = maintains > > such a group of Flow Records is a kind of cache. For this reason > the > > Metering Process table (ipfixMeteringProcessTable) is grouped by > > cache IDs (ipfixMeteringProcessCacheId). Each cache can be > > maintained by a separate instance of the Metering Process which = is > > represented by the Metering Process ID (ipfixMeteringProcessId). > To > > specify the Observation Point(s) where the Flow Records are > gathered > > the ipfixObservationPointGroupReference may contain the an >=20 > "the" or "an"? >=20 > > ipfixObservationPointGroupId from the Observation Point table > > (ipfixObservationPointTable) described in the next section. If = an > > Observation Point cannot be given the >=20 > What do you mean by "cannot be given"? If you think of a concentrator that merges things you may not be able to specify a observation domain. Then you cannot tell the observation point = is this or that. Regards, Thomas >=20 > > ipfixObservationPointGroupReference MUST be zero(0). The = timeouts > > (ipfixMeteringProcessCacheActiveTimeout and > > ipfixMeteringProcessCacheInactiveTimeout) specify when Flow > Records > > are passed to the Exporting Process. > > > > ipfixMeteringProcessTable(8) > > | > > +- ipfixMeteringProcessEntry(1) > > | > > +- index(9) > > +- ipfixMeteringProcessCacheId(1) =3D 9 > > +- ipfixMeteringProcessId(2) =3D 287 > > +- ipfixObservationPointGroupReference(3) =3D 17 > > +- ipfixMeteringProcessCacheActiveTimeout(4) =3D 100 > > +- ipfixMeteringProcessCacheInactiveTimeout(5) =3D 100 >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz ------=_NextPart_000_0098_01C93B60.BBB1CA20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMDMxMTI1ODIwWjAjBgkqhkiG9w0BCQQxFgQU0dGDw0DW3CuCT/sNgH1lL48og4cwgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGATjxdyc/M8RAy nhJGwxmx8FqDH6HaoXmu4BfDHbQLkIovMvZuYHsD8+p1gR9h6RDZpPdXOkO3cqdFkgj8Yikx4Enu bILLVsFe5ymtOK4sMHxbGBNI1nx4EBvx+WRIkaSKWUfKUBAW9LbhYcEGzaAbFtnzDZ9aLZCYOC5m 9CdiMVAAAAAAAAA= ------=_NextPart_000_0098_01C93B60.BBB1CA20-- --===============1111889455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1111889455==-- es@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Gerhard Muenz > Sent: Freitag, 29. August 2008 11:28 > To: ipfix@ietf.org > Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 >=20 >=20 > Dear all, >=20 > Please find comments on draft-ietf-ipfix-mib-04 below. >=20 > Currently, we have ipfixTransportSessionTable which does not provide > any > information about the role of the given device within the transport > session. We do not know if the device is exporter or collector. >=20 > On the other hand, you define "directional" tables for the Templates: > ipfixExportedTemplateTable > ipfixExportedTemplateDefinitionTable > ipfixCollectedTemplateTable > ipfixCollectedTemplateDefinitionTable >=20 > Is there any specific reason? >=20 Yes there is... see below > There are two alternatives which require fewer tables: > 1) One could add an entry about the role of the device to the > ipfixTransportSessionTable, for example in form of a field with values > "exporter" and "collector". As the Templates are scoped to a given > Transport Session, it is clear which Templates are exported and which > Templates are collected. So we would have only three tables instead of > five: > ipfixTransportSessionTable > ipfixTemplateTable > ipfixTemplateDefinitionTable >=20 That the way we had it before, more or less. The problem is that a = device potentially can be a collector and an exporter at the same time. We = could collect a template with a Observation domain x and a template id y which = is not necessarily the same as the template with observation domain x and template id y that we export. The template Ids are only unique at the exporting device. The same is true for the observation domain ids. So = having one table for the templates (ipfixTemplateTable) und in consequence for = the template definitions (ipfixTemplateDefinitionTable) does not work. > 2) Or, one could split the ipfixTransportSessionTable into: > - ipfixOutgoingTransportSessionTable for Transport Sessions where the > given device is exporter. > - ipfixIncomingTransportSessionTable for Transport Sessions where the > given device is collector. > Again, we only need two tables for the Templates: > ipfixTemplateTable > ipfixTemplateDefinitionTable >=20 We could split the transport session table into 2 but for the reason explained above we still cannot collapse the template and template definition table into one. But I don't see the point why to split the transport session table without gaining anything. > Reducing the number of tables is certainly not a design goal for MIBs. > However, I think that it is more logical to have the information of = the > device role (exporter and collector) together with the data about the > Transport Session. >=20 > > 5.3. The Template Tables > > > > There are two Template tables, the Exported Template > > (ipfixExportedTemplateTable) table and the Collected Template > table > > (ipfixCollectedTemplateTable). Those Template tables list all > > Templates (including Option Templates) that are sent (by an > Exporter) > > or received (by a Collector). The (Option) Templates are unique > per > > Transport Session and Observation Domain, thus the table is > indexed > > by the Transport Session Index (ipfixTransportSessionIndex) and > the > > Observation Domain Id (ipfixExportedObservationDomainId or > > ipfixCollectedObservationDomainId). It contains the Set Id and = an >=20 > I propose to list the indices in a clearer way one below the other: >=20 > The (Option) Templates are unique per > Transport Session and Observation Domain, thus the table is = indexed > by the following indices: > - Transport Session Index (ipfixTransportSessionIndex) > - Observation Domain Id (ipfixExportedObservationDomainId or > ipfixCollectedObservationDomainId). >=20 > With two indices, explaining them in the text may still be ok. But you > have much longer lists of indices for the other Tables. >=20 I will try to do that where applicable. > > Access Time denoting the time when the (Option) Template was last > > sent or received. > > > > To resume the above example the Exporter may want to export the a >=20 > remove "the" or "a" >=20 > > Template and an Option Template for each Transport Session = defined > > above. This leads to the following Template Table defining > Template > > and Option Template: > > > > ipfixExportedTemplateTable (3) > > | > > +- ipfixExportedTemplateEntry (1) > > | > > +- index (5) > > | +- index (3) > > | + index (257) >=20 > It is difficult to deduce the meaning of the indices. Maybe add in > brackets which index refers to what: >=20 > +- index (5) (ipfixTransportSessionIndex) > | +- index (3) (ipfixExportedObservationDomainId) > | + index (257) (ipfixExportedTemplateId) >=20 >=20 Good idea, I will add this. > > | | +- ipfixExportedObservationDomainId (1) =3D 3 > > | | +- ipfixExportedTemplateId (2) =3D 257 > > | | +- ipfixExportedTemplateSetId (3) =3D 2 > > | | +- ipfixExportedTemplateAccessTime (4) > > | | =3D = 2008-7-1,12:49:11.2,+2:0 > > | | > > | + index (264) > > | +- ipfixExportedObservationDomainId (1) =3D 3 > > | +- ipfixExportedTemplateId (2) =3D 264 > > | +- ipfixExportedTemplateSetId (3) =3D 3 > > | +- ipfixExportedTemplateAccessTime (4) > > . =3D = 2008-7-1,12:47:04.8,+2:0 > > . > > . > > . > > +- index (11) > > +- index (3) > > + index (273) > > | +- ipfixExportedObservationDomainId (1) =3D 3 > > | +- ipfixExportedTemplateId (2) =3D 273 > > | +- ipfixExportedTemplateSetId (3) =3D 2 > > | +- ipfixExportedTemplateAccessTime (4) > > | =3D = 2008-7-1,12:49:11.2,+2:0 > > | > > + index (289) > > +- ipfixExportedObservationDomainId (1) =3D 3 > > +- ipfixExportedTemplateId (2) =3D 289 > > +- ipfixExportedTemplateSetId (3) =3D 3 > > +- ipfixExportedTemplateAccessTime (4) > > =3D = 2008-7-1,12:47:04.8,+2:0 > > > > We assume that the Collector with index 5 in the Transport = Session > > table of the Exporter has stored the connection to the Exporter > with > > the Transport Session index of 17 then its Template table would > look > > as follows: >=20 > The sentence is confusing. The Transport Session tables does not > contain > any entry called Collector, only > ipfixTransportSessionDestinationAddress > and ipfixTransportSessionDestinationPort. >=20 > Maybe: > We assume that the Transport Session that is stored with index 5 in = the > Transport Session table of the Exporter is stored with index 17 in the > Transport Session table of the (corresponding) Collector. Then, the > Template table would look as follows: >=20 Good point again here. >=20 > > 5.4. The Template Definition Tables > > > > As with the Template tables there are two Template Definition > tables, > > the Exported Template Definition table > > (ipfixExportedTemplateDefinitionTable) and the Collected Template > > Definition table (ipfixCollectedTemplateDefinitionTable). Those > > tables list all the Information Elements contained in a Template > or > > Option Template. Therefore it has the same indexes as the > > corresponding Template table plus the Template Id. Its own index > > denotes the order of the Information Element inside the Template > if > > necessary. Besides the Information Element Id and the length of > the > > encoded value the table contains flags for each Information > Element. > > The flags indicate if the Information Element is used for scoping > or > > as a Flow key. >=20 > What about enterprise-specific IEs? Don't we need an enterprise number > entry? >=20 Wow, you are right! Nobody noticed that before. It's a quick fix that = I'll do. > > 5.5. The Export Table > > > > On Exporters, the Export table (ipfixExportTable) can be used to > > support features like failover, load-balancing, duplicate export > to > > several Collectors etc. The table has 5 indexes that link an > entry > > with the Metering Process table (ipfixMeteringProcessCacheId, see > > below), the Exported Template table > (ipfixExportedObservationDomainId > > and ipfixExportedTemplateId) and the Transport Session table > > (ipfixTransportSessionIndex). Those entries with the same >=20 > Is there a reason for not ordering the indexes as they appear in the > MIB? >=20 No, but I shifted the forward and backward but it seems that I forgot to correct it in the text. > > ipfixExportIndex, the same ipfixMeteringProcessCacheId and the > same > > ipfixExportedObservationDomainId define a Transport Session = group. > > This also The member type for each group member describes its >=20 > remove "This also" >=20 > > functionality. >=20 > Why is a Transport Session group restricted to the output of a single > cache? Because that's what a transport session group is for. Export from a = single cache to different destinations in different configurations. Primary/Secondary for failover, in Parallel, ... >=20 > > If the Exporter does not use Transport Session grouping then each > > ipfixExportIndex contains a single ipfixMeteringProcessCacheId = and >=20 > ipfixTransportSessionIndex? I can add that, but Transport Session implies ipfixTransportSessionIndex >=20 > > thus a singe Transport Session and this session MUST have the > member >=20 > single >=20 > > type primary(1). >=20 > > To continue the example we assume that the Exporter uses the 2 >=20 > two >=20 > > connections shown in the examples above as the primary export for > a > > session protected by a secondary backup connection. The Exporter > > then has the following entries in the ipfixExportTable: > > > > ipfixExportTable (3) > > | > > +- ipfixExportEntry (1) > > | > > +- index (7) > > | +- index (9) > > | +- index (3) > > | +- index (257) > > | | +- index (5) > > | | +- ipfixExportIndex (1) =3D 7 > > | | +- ipfixExportMemberType (2) =3D 1 (primary) > > | | > > | +- index (273) > > | +- index (11) > > | +- ipfixExportIndex (1) =3D 7 > > | +- ipfixExportMemberType (2) =3D 2 (secondary) > > | > > +- index (8) > > +- index (9) > > +- index (3) > > +- index (264) > > | +- index (5) > > | +- ipfixExportIndex (1) =3D 8 > > | +- ipfixExportMemberType (2) =3D 2 (secondary) > > +- index (289) > > +- index (11) > > +- ipfixExportIndex (1) =3D 7 >=20 > 8? >=20 > > +- ipfixExportMemberType (2) =3D 1 (primary) >=20 > Can you explain this example? >=20 > There are two Metering Processes? And the output is sent to different > primary collectors? And in case of a failure, each collector serves as > backup for the other? Absolutely right. So what do I need to explain??? Sure that = configuration may not be really useful but you have the possibility to do it. >=20 > > 5.6. The Metering Process Table > > > > The Metering Process as defined in [RFC5101] consists of a set of > > function. Maintaining the Flow Records is one of them. This > > function is responsible for passing the Flow Records to the > Exporting > > Process but also for detecting Flow expiration. The Flow Records >=20 > "but also" =3D> "and also" >=20 > > that are maintained by the Metering Process can be grouped by the > > Observation Points they are observed. The instance that = maintains > > such a group of Flow Records is a kind of cache. For this reason > the > > Metering Process table (ipfixMeteringProcessTable) is grouped by > > cache IDs (ipfixMeteringProcessCacheId). Each cache can be > > maintained by a separate instance of the Metering Process which = is > > represented by the Metering Process ID (ipfixMeteringProcessId). > To > > specify the Observation Point(s) where the Flow Records are > gathered > > the ipfixObservationPointGroupReference may contain the an >=20 > "the" or "an"? >=20 > > ipfixObservationPointGroupId from the Observation Point table > > (ipfixObservationPointTable) described in the next section. If = an > > Observation Point cannot be given the >=20 > What do you mean by "cannot be given"? If you think of a concentrator that merges things you may not be able to specify a observation domain. Then you cannot tell the observation point = is this or that. Regards, Thomas >=20 > > ipfixObservationPointGroupReference MUST be zero(0). The = timeouts > > (ipfixMeteringProcessCacheActiveTimeout and > > ipfixMeteringProcessCacheInactiveTimeout) specify when Flow > Records > > are passed to the Exporting Process. > > > > ipfixMeteringProcessTable(8) > > | > > +- ipfixMeteringProcessEntry(1) > > | > > +- index(9) > > +- ipfixMeteringProcessCacheId(1) =3D 9 > > +- ipfixMeteringProcessId(2) =3D 287 > > +- ipfixObservationPointGroupReference(3) =3D 17 > > +- ipfixMeteringProcessCacheActiveTimeout(4) =3D 100 > > +- ipfixMeteringProcessCacheInactiveTimeout(5) =3D 100 >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz ------=_NextPart_000_0098_01C93B60.BBB1CA20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMDMxMTI1ODIwWjAjBgkqhkiG9w0BCQQxFgQU0dGDw0DW3CuCT/sNgH1lL48og4cwgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGATjxdyc/M8RAy nhJGwxmx8FqDH6HaoXmu4BfDHbQLkIovMvZuYHsD8+p1gR9h6RDZpPdXOkO3cqdFkgj8Yikx4Enu bILLVsFe5ymtOK4sMHxbGBNI1nx4EBvx+WRIkaSKWUfKUBAW9LbhYcEGzaAbFtnzDZ9aLZCYOC5m 9CdiMVAAAAAAAAA= ------=_NextPart_000_0098_01C93B60.BBB1CA20-- --===============1111889455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1111889455==-- From ipfix-bounces@ietf.org Fri Oct 31 07:59:50 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13383A6BE5; Fri, 31 Oct 2008 07:59:50 -0700 (PDT) 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 A6E803A6BE5 for ; Fri, 31 Oct 2008 07:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1ABYxPxsN6N for ; Fri, 31 Oct 2008 07:59:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 689DE3A6A20 for ; Fri, 31 Oct 2008 07:59:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,523,1220227200"; d="scan'208";a="24327061" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2008 14:59:46 +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 m9VExkrY006511; Fri, 31 Oct 2008 15:59:46 +0100 Received: from [10.61.84.64] (ams3-vpn-dhcp5185.cisco.com [10.61.84.64]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VExjU7012494; Fri, 31 Oct 2008 14:59:45 GMT Message-ID: <490B1D61.2060202@cisco.com> Date: Fri, 31 Oct 2008 14:59:45 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Gerhard Muenz References: <4900A28D.4020505@net.in.tum.de> <20081023174842.GB28803@elstar.local> In-Reply-To: <20081023174842.GB28803@elstar.local> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=854; t=1225465186; x=1226329186; 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[IPFIX]=20IPFIX=20configuration=3A=20Ca ll=20for=20TLS/DTLS=20parameters |Sender:=20; bh=e/C6/U8zu+HrHbCatjjSWpX6Sn5ORbqv+GtUMaTVUGQ=; b=YkYl3V2mSSah6lubwq5NofzFiKBJWvrceuVolJZ/VfKHbHguqPLOhAdgTk oANxBb9XYBi8u9z2LSunJz1FVIMWEPNZLfjQKMl3AXpolj8pLS0kinHRr6Yf pms+U0yaLV; 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] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Juergen Schoenwaelder wrote: >> Are there any people/groups - apart from Brian - how have implemented >> TLS/DTLS for IPFIX (or other flow export protocols)? >> Does anybody know any commercial products supporting this feature? >> >> If yes, please give feedbackk to the following questions: >> >> Does it make sense to include TLS/DTLS parameters into the IPFIX >> configuration model? >> If so, which are the most important parameters to be included? > > I have not implementFrom ipfix-bounces@ietf.org Fri Oct 31 07:59:50 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13383A6BE5; Fri, 31 Oct 2008 07:59:50 -0700 (PDT) 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 A6E803A6BE5 for ; Fri, 31 Oct 2008 07:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1ABYxPxsN6N for ; Fri, 31 Oct 2008 07:59:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 689DE3A6A20 for ; Fri, 31 Oct 2008 07:59:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,523,1220227200"; d="scan'208";a="24327061" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2008 14:59:46 +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 m9VExkrY006511; Fri, 31 Oct 2008 15:59:46 +0100 Received: from [10.61.84.64] (ams3-vpn-dhcp5185.cisco.com [10.61.84.64]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VExjU7012494; Fri, 31 Oct 2008 14:59:45 GMT Message-ID: <490B1D61.2060202@cisco.com> Date: Fri, 31 Oct 2008 14:59:45 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Gerhard Muenz References: <4900A28D.4020505@net.in.tum.de> <20081023174842.GB28803@elstar.local> In-Reply-To: <20081023174842.GB28803@elstar.local> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=854; t=1225465186; x=1226329186; 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[IPFIX]=20IPFIX=20configuration=3A=20Ca ll=20for=20TLS/DTLS=20parameters |Sender:=20; bh=e/C6/U8zu+HrHbCatjjSWpX6Sn5ORbqv+GtUMaTVUGQ=; b=YkYl3V2mSSah6lubwq5NofzFiKBJWvrceuVolJZ/VfKHbHguqPLOhAdgTk oANxBb9XYBi8u9z2LSunJz1FVIMWEPNZLfjQKMl3AXpolj8pLS0kinHRr6Yf pms+U0yaLV; 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] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Juergen Schoenwaelder wrote: >> Are there any people/groups - apart from Brian - how have implemented >> TLS/DTLS for IPFIX (or other flow export protocols)? >> Does anybody know any commercial products supporting this feature? >> >> If yes, please give feedbackk to the following questions: >> >> Does it make sense to include TLS/DTLS parameters into the IPFIX >> configuration model? >> If so, which are the most important parameters to be included? > > I have not implementeded any of this. However, I suggest avoiding going > into any DTLS/TLS configuration details as this is something that > should be worked out by DTLS/TLS WGs. Perhaps these should addressed by vendor-specific parameters in a similar way to ACLs, per the discussion with Atsushi-san? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix any of this. However, I suggest avoiding going > into any DTLS/TLS configuration details as this is something that > should be worked out by DTLS/TLS WGs. Perhaps these should addressed by vendor-specific parameters in a similar way to ACLs, per the discussion with Atsushi-san? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 31 08:06:54 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4713A6C02; Fri, 31 Oct 2008 08:06:54 -0700 (PDT) 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 CBAD53A6BDE for ; Fri, 31 Oct 2008 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQBe8v92HHZb for ; Fri, 31 Oct 2008 08:06:52 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id E84D23A6C0C for ; Fri, 31 Oct 2008 08:06:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0B3AAD93CA; Fri, 31 Oct 2008 16:06:49 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zEk31N2UarvL; Fri, 31 Oct 2008 16:06:48 +0100 (MET) Received: from [42.90.5.2] (unknown [129.174.78.5]) (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 35B33D93A7; Fri, 31 Oct 2008 16:06:48 +0100 (MET) Message-Id: <116088BE-9141-4325-8E65-794B78C90FF1@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <490B1D61.2060202@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 11:06:46 -0400 References: <4900A28D.4020505@net.in.tum.de> <20081023174842.GB28803@elstar.local> <490B1D61.2060202@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org All, Certain TLS/DTLS parameters should of course be vendor-specific. But many of these (e.g. X.509 certificate authorities and subject certificates, PKCS#12 "client" (EP) certs, and so on) should be commonly represented among all implementations, especially given the fairly stringent requirements on mutual identification in 5101. So I would suggest that _at least_ the EP/CP identity, the authorized-CP identity for EPs, and authorized-EP or authorized-EP-cert-authority for CPs, be addressed in the configuration data model. Cheers, Brian On Oct 31, 2008, at 10:59 AM, Paul Aitken wrote: > Gerhard, > > Juergen Schoenwaelder wrote: > >>> Are there any people/groups - apart from Brian - how have >>> implemented >>> TLS/DTLS for IPFIX (or other flow export protocols)? >>> Does anybody know any commercial products supporting this feature? >>> >>> If yes, please give feedbackk to the following questions: >>> >>> Does it make sense to include TLS/DTLS parameters into the IPFIX >>> configuration model? >>> If so, which are the most important parameters to be included? >> I have not implemented any of this. However, I suggest avoiding going >> into any DTLS/TLS configuration details as this is something that >> should be worked out by DTLS/TLS WGs. > > Perhaps these should addressed by vendor-specific parameters in a > similar way to ACLs, per the discussion with Atsushi-san? > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > 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 ipfix-bounces@ietf.org Fri Oct 31 08:06:54 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4713A6C02; Fri, 31 Oct 2008 08:06:54 -0700 (PDT) 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 CBAD53A6BDE for ; Fri, 31 Oct 2008 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQBe8v92HHZb for ; Fri, 31 Oct 2008 08:06:52 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id E84D23A6C0C for ; Fri, 31 Oct 2008 08:06:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0B3AAD93CA; Fri, 31 Oct 2008 16:06:49 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zEk31N2UarvL; Fri, 31 Oct 2008 16:06:48 +0100 (MET) Received: from [42.90.5.2] (unknown [129.174.78.5]) (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 35B33D93A7; Fri, 31 Oct 2008 16:06:48 +0100 (MET) Message-Id: <116088BE-9141-4325-8E65-794B78C90FF1@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <490B1D61.2060202@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 11:06:46 -0400 References: <4900A28D.4020505@net.in.tum.de> <20081023174842.GB28803@elstar.local> <490B1D61.2060202@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX configuration: Call for TLS/DTLS parameters 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org All, Certain TLS/DTLS parameters should of course be vendor-specific. But many of these (e.g. X.509 certificate authorities and subject certificates, PKCS#12 "client" (EP) certs, and so on) should be commonly represented among all implementations, especially given the fairly stringent requirements on mutual identification in 5101. So I would suggest that _at least_ the EP/CP identity, the authorized-CP identity for EPs, and authorized-EP or authorized-EP-cert-authority for CPs, be addressed in the configuration data model. Cheers, Brian On Oct 31, 2008, at 10:59 AM, Paul Aitken wrote: > Gerhard, > > Juergen Schoenwaelder wrote: > >>> Are there any people/groups - apart from Brian - how have >>> implemented >>> TLS/DTLS for IPFIX (or other flow export protocols)? >>> Does anybody know any commercial products supporting this feature? >>> >>> If yes, please give feedbackk to the following questions: >>> >>> Does it make sense to include TLS/DTLS parameters into the IPFIX >>> configuration model? >>> If so, which are the most important parameters to be included? >> I have not implemented any of this. However, I suggest avoiding going >> into any DTLS/TLS configuration details as this is something that >> should be worked out by DTLS/TLS WGs. > > Perhaps these should addressed by vendor-specific parameters in a > similar way to ACLs, per the discussion with Atsushi-san? > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > 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 ipfix-bounces@ietf.org Fri Oct 31 10:01:14 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9593A6BFC; Fri, 31 Oct 2008 10:01:14 -0700 (PDT) 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 281963A6C55 for ; Fri, 31 Oct 2008 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, 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 4ZZ2-rJvHKLR for ; Fri, 31 Oct 2008 10:01:08 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id ACCA83A6C52 for ; Fri, 31 Oct 2008 10:01:08 -0700 (PDT) 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 77BB040BB4; Fri, 31 Oct 2008 18:00:00 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 672EB92D; Fri, 31 Oct 2008 18:00:00 +0100 (CET) Message-ID: <490B3993.1040504@net.in.tum.de> Date: Fri, 31 Oct 2008 18:00:03 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Thomas Dietz References: <48B7C105.8070708@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C441471@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C441471@VENUS.office> X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Thomas, Thomas Dietz wrote: > sorry for the late reply. See my comments inline... >> Dear all, >> = >> Please find comments on draft-ietf-ipfix-mib-04 below. >> = >> Currently, we have ipfixTransportSessionTable which does not provide >> any >> information about the role of the given device within the transport >> session. We do not know if the device is exporter or collector. >> = >> On the other hand, you define "directional" tables for the Templates: >> ipfixExportedTemplateTable >> ipfixExportedTemplateDefinitionTable >> ipfixCollectedTemplateTable >> ipfixCollectedTemplateDefinitionTable >> = >> Is there any specific reason? >> = > = > Yes there is... see below > = >> There are two alternatives which require fewer tables: >> 1) One could add an entry about the role of the device to the >> ipfixTransportSessionTable, for example in form of a field with values >> "exporter" and "collector". As the Templates are scoped to a given >> Transport Session, it is clear which Templates are exported and which >> Templates are collected. So we would have only three tables instead of >> five: >> ipfixTransportSessionTable >> ipfixTemplateTable >> ipfixTemplateDefinitionTable >> = > = > That the way we had it before, more or less. = No, it is not the same as you had before. In the previous version, the entries in the Transport Session table did not include any information about at which endpoint of the Transport Session the device is located. That's why it could not work. I propose to add a column to the Transport Session table that says "collector endpoint" or "exporter endpoint". > The problem is that a device > potentially can be a collector and an exporter at the same time. We could > collect a template with a Observation domain x and a template id y which = is > not necessarily the same as the template with observation domain x and > template id y that we export. The template Ids are only unique at the > exporting device. The same is true for the observation domain ids. So hav= ing > one table for the templates (ipfixTemplateTable) und in consequence for t= he > template definitions (ipfixTemplateDefinitionTable) does not work. There should not be a problem with the additional column I propose because the Transport Session entry provides the necessary separation between "exporter" and "collector". The ipfixTemplateTable has the following indexes: ipfixTransportSessionIndex, ipfixObservationDomainId and the ipfixTemplateDefinitionTable has: ipfixTransportSessionIndex, ipfixObservationDomainId, ipfixTemplateId In both tables, ipfixTransportSessionIndex is index. So, as far as I understand, this means that there is no problem to use identical values for ODID and the same Template ID for different Transport Sessions. And there is another disadvantage with your proposal: It is not possible to know from the Transport Session table if the device is Exporter or Collector for a given Transport Session. You must first search the ipfixExportedTemplateTable and the ipfixCollectedTemplateTable to know that. If there are no Templates received or exported at all, you will never know. In this case, the only solution is too match the IP addresses of the Transport Session table with known IP addresses of the device. I do not think that this is a good solution. With the proposed column, you get the information directly. >> 2) Or, one could split the ipfixTransportSessionTable into: >> - ipfixOutgoingTransportSessionTable for Transport Sessions where the >> given device is exporter. >> - ipfixIncomingTransportSessionTable for Transport Sessions where the >> given device is collector. >> Again, we only need two tables for the Templates: >> ipfixTemplateTable >> ipfixTemplateDefinitionTable >> = > = > We could split the transport session table into 2 but for the reason > explained above we still cannot collapse the template and template > definition table into one. But I don't see the point why to split the > transport session table without gaining anything. You are right that this does not work. The reason is that we would need different sets of indexes for incoming and outgoing Templates in the ipfixTemplateTable: - ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for incoming, and - ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for outgoing. >> Why is a Transport Session group restricted to the output of a single >> cache? > = > Because that's what a transport session group is for. Export from a single > cache to different destinations in different configurations. > Primary/Secondary for failover, in Parallel, ... Ok. When I asked the question, I thought that there was a one-to-one mapping between an entry in the Export table and an Exporting Process. But this is not the case. >> Can you explain this example? >> = >> There are two Metering Processes? And the output is sent to different >> primary collectors? And in case of a failure, each collector serves as >> backup for the other? > = > = > Absolutely right. So what do I need to explain??? = You need to explain what I had to guess from the context because it was not clear. In the example appear ipfixMeteringProcessCacheId values and nobody knows where From ipfix-bounces@ietf.org Fri Oct 31 10:01:14 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9593A6BFC; Fri, 31 Oct 2008 10:01:14 -0700 (PDT) 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 281963A6C55 for ; Fri, 31 Oct 2008 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, 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 4ZZ2-rJvHKLR for ; Fri, 31 Oct 2008 10:01:08 -0700 (PDT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id ACCA83A6C52 for ; Fri, 31 Oct 2008 10:01:08 -0700 (PDT) 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 77BB040BB4; Fri, 31 Oct 2008 18:00:00 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 672EB92D; Fri, 31 Oct 2008 18:00:00 +0100 (CET) Message-ID: <490B3993.1040504@net.in.tum.de> Date: Fri, 31 Oct 2008 18:00:03 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Thomas Dietz References: <48B7C105.8070708@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C441471@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C441471@VENUS.office> X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Thomas, Thomas Dietz wrote: > sorry for the late reply. See my comments inline... >> Dear all, >> = >> Please find comments on draft-ietf-ipfix-mib-04 below. >> = >> Currently, we have ipfixTransportSessionTable which does not provide >> any >> information about the role of the given device within the transport >> session. We do not know if the device is exporter or collector. >> = >> On the other hand, you define "directional" tables for the Templates: >> ipfixExportedTemplateTable >> ipfixExportedTemplateDefinitionTable >> ipfixCollectedTemplateTable >> ipfixCollectedTemplateDefinitionTable >> = >> Is there any specific reason? >> = > = > Yes there is... see below > = >> There are two alternatives which require fewer tables: >> 1) One could add an entry about the role of the device to the >> ipfixTransportSessionTable, for example in form of a field with values >> "exporter" and "collector". As the Templates are scoped to a given >> Transport Session, it is clear which Templates are exported and which >> Templates are collected. So we would have only three tables instead of >> five: >> ipfixTransportSessionTable >> ipfixTemplateTable >> ipfixTemplateDefinitionTable >> = > = they come from. I had to guess that there are two Metering Processes. This should be explained somewhere. >>> (ipfixObservationPointTable) described in the next section. If an >>> Observation Point cannot be given the >> = >> What do you mean by "cannot be given"? > = > If you think of a concentrator that merges things you may not be able to > specify a observation domain. Then you cannot tell the observation point = is > this or that. "cannot be given" leaves open why the Observation Point cannot be identified, and I wondered what the reasons could be. If you think of information that is not available, then consider: "If the Observations Points are unknown, the ipfixObservationPointGroupReference MUST be zero(0)." or "If the Observations Points are unspecified, the ipfixObservationPointGroupReference MUST be zero(0)." Regards, Gerhard -- = 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix > That the way we had it before, more or less. = No, it is not the same as you had before. In the previous version, the entries in the Transport Session table did not include any information about at which endpoint of the Transport Session the device is located. That's why it could not work. I propose to add a column to the Transport Session table that says "collector endpoint" or "exporter endpoint". > The problem is that a device > potentially can be a collector and an exporter at the same time. We could > collect a template with a Observation domain x and a template id y which = is > not necessarily the same as the template with observation domain x and > template id y that we export. The template Ids are only unique at the > exporting device. The same is true for the observation domain ids. So hav= ing > one table for the templates (ipfixTemplateTable) und in consequence for t= he > template definitions (ipfixTemplateDefinitionTable) does not work. There should not be a problem with the additional column I propose because the Transport Session entry provides the necessary separation between "exporter" and "collector". The ipfixTemplateTable has the following indexes: ipfixTransportSessionIndex, ipfixObservationDomainId and the ipfixTemplateDefinitionTable has: ipfixTransportSessionIndex, ipfixObservationDomainId, ipfixTemplateId In both tables, ipfixTransportSessionIndex is index. So, as far as I understand, this means that there is no problem to use identical values for ODID and the same Template ID for different Transport Sessions. And there is another disadvantage with your proposal: It is not possible to know from the Transport Session table if the device is Exporter or Collector for a given Transport Session. You must first search the ipfixExportedTemplateTable and the ipfixCollectedTemplateTable to know that. If there are no Templates received or exported at all, you will never know. In this case, the only solution is too match the IP addresses of the Transport Session table with known IP addresses of the device. I do not think that this is a good solution. With the proposed column, you get the information directly. >> 2) Or, one could split the ipfixTransportSessionTable into: >> - ipfixOutgoingTransportSessionTable for Transport Sessions where the >> given device is exporter. >> - ipfixIncomingTransportSessionTable for Transport Sessions where the >> given device is collector. >> Again, we only need two tables for the Templates: >> ipfixTemplateTable >> ipfixTemplateDefinitionTable >> = > = > We could split the transport session table into 2 but for the reason > explained above we still cannot collapse the template and template > definition table into one. But I don't see the point why to split the > transport session table without gaining anything. You are right that this does not work. The reason is that we would need different sets of indexes for incoming and outgoing Templates in the ipfixTemplateTable: - ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for incoming, and - ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for outgoing. >> Why is a Transport Session group restricted to the output of a single >> cache? > = > Because that's what a transport session group is for. Export from a single > cache to different destinations in different configurations. > Primary/Secondary for failover, in Parallel, ... Ok. When I asked the question, I thought that there was a one-to-one mapping between an entry in the Export table and an Exporting Process. But this is not the case. >> Can you explain this example? >> = >> There are two Metering Processes? And the output is sent to different >> primary collectors? And in case of a failure, each collector serves as >> backup for the other? > = > = > Absolutely right. So what do I need to explain??? = You need to explain what I had to guess from the context because it was not clear. In the example appear ipfixMeteringProcessCacheId values and nobody knows where they come from. I had to guess that there are two Metering Processes. This should be explained somewhere. >>> (ipfixObservationPointTable) described in the next section. If an >>> Observation Point cannot be given the >> = >> What do you mean by "cannot be given"? > = > If you think of a concentrator that merges things you may not be able to > specify a observation domain. Then you cannot tell the observation point = is > this or that. "cannot be given" leaves open why the Observation Point cannot be identified, and I wondered what the reasons could be. If you think of information that is not available, then consider: "If the Observations Points are unknown, the ipfixObservationPointGroupReference MUST be zero(0)." or "If the Observations Points are unspecified, the ipfixObservationPointGroupReference MUST be zero(0)." Regards, Gerhard -- = 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 31 10:41:44 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF9328C27C; Fri, 31 Oct 2008 10:41:44 -0700 (PDT) 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 0F40828C26D for ; Fri, 31 Oct 2008 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 OcJfAQ6SW9Se for ; Fri, 31 Oct 2008 10:41:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 7E96E28C207 for ; Fri, 31 Oct 2008 10:41:41 -0700 (PDT) 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 m9VHfdw20553; Fri, 31 Oct 2008 18:41:39 +0100 (CET) Received: from [10.61.100.183] (dhcp-10-61-100-183.cisco.com [10.61.100.183]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9VHfbG20549; Fri, 31 Oct 2008 18:41:38 +0100 (CET) Message-ID: <490B4351.6000706@cisco.com> Date: Fri, 31 Oct 2008 18:41:37 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> <20081026232018.05C1.17391CF2@nttv6.net> In-Reply-To: <20081026232018.05C1.17391CF2@nttv6.net> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: multipart/mixed; boundary="===============0928912414==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0928912414== Content-Type: multipart/alternative; boundary="------------060100020209060203000402" This is a multi-part message in MIME format. --------------060100020209060203000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kobayashi-san > Hi Benoit, > > Please see in-line. > > On Thu, 23 Oct 2008 13:24:03 +0200 > Benoit Claise wrote: > > >> Kobayashi-san, >> >> Thank you very much for your review. >> Note that the draft excerpts are in this email contained already the >> improvements proposed by Brian. >> >>> Dear all, >>> >>> I did not have enough time for reviewing for the draft in Aug. >>> Although the time limit exceeds, I have reviewed the draft. >>> >>> Please see my questions and comments and so on in lines. >>> >>> Q1) >>> I think that the following condition is configurable choice. >>> - One stream treats one Template Record and associated Data Records. >>> - One stream treats some Template Records and associated Data Records >>> related to same Observation Domain, or same Observation Points. >>> It can deduce Data Record Loss per observation domain or observation points. >>> Does this draft cover the latter pattern ? >>> >>> >> Yes, exactly. This is a configurable choice.From ipfix-bounces@ietf.org Fri Oct 31 10:41:44 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF9328C27C; Fri, 31 Oct 2008 10:41:44 -0700 (PDT) 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 0F40828C26D for ; Fri, 31 Oct 2008 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 OcJfAQ6SW9Se for ; Fri, 31 Oct 2008 10:41:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 7E96E28C207 for ; Fri, 31 Oct 2008 10:41:41 -0700 (PDT) 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 m9VHfdw20553; Fri, 31 Oct 2008 18:41:39 +0100 (CET) Received: from [10.61.100.183] (dhcp-10-61-100-183.cisco.com [10.61.100.183]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9VHfbG20549; Fri, 31 Oct 2008 18:41:38 +0100 (CET) Message-ID: <490B4351.6000706@cisco.com> Date: Fri, 31 Oct 2008 18:41:37 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> <20081026232018.05C1.17391CF2@nttv6.net> In-Reply-To: <20081026232018.05C1.17391CF2@nttv6.net> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Type: multipart/mixed; boundary="===============0928912414==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0928912414== Content-Type: multipart/alternative; boundary="------------060100020209060203000402" This is a multi-part message in MIME format. --------------060100020209060203000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kobayashi-san > Hi Benoit, > > Please see in-line. > > On Thu, 23 Oct 2008 13:24:03 +0200 > Benoit Claise wrote: > > >> Kobayashi-san, >> >> Thank you very much for your review. >> Note that the draft excerpts are in this email contained already the >> improvements proposed by Brian. >> >>> Dear all, >>> >>> I did not have enough time for reviewing for the draft in Aug. >>> Although the time limit exceeds, I have reviewed the draft. >>> >>> Please see my questions and comments and so on in lines. >>> >>> Q1) >>> I think that the following condition is configurable choice. >>> - One stream treats one Template Record and associated Data Records. >>> - One stream treats some Template Records and associated Data Records >>> related to same Observation Domain, or same Observation Points. >>> It can deduce Data Record Loss per observation domain or observation points. >>> Does this draft cover the latter pattern ? >>> >>> >> Yes, exactly. This is a configurable choice. >> >> "The Exporter SHOULD send a single Template and corresponding Data Sets >> within a single stream in order to enable calculation of the potential >> Data Record loss for this Template ID. However, the Exporter MAY group >> related Templates and their corresponding Data Sets within a single >> stream so that loss statistics are calculated for the group. This is >> suitable in cases where there are only slight variations among the >> Templates in a group, e.g. the omission of unavailable fields for export >> efficiency, and may be necessary if the SCTP association does not >> support enough streams to export each Template in its own stream." >> >> > > I can image following case. > In general purposes, IPv4/IPv6 templates and data captured by same > metering process and same sampling rate are exported on same sctp stream. > On the other hand, specified application data and template which contain > additional fields, for different purpose e.g. QoS measurement, are > exported on different sctp stream. > > Templates and data will be grouped according to the purposes or scope of > measurement which depend on loss sensitivity. > Exactly. > >>> Q2) >>> This draft does not describe how to export some statistics option >>> template and data. Should they be exported on same stream exporting >>> associated Template and Data Records ? >>> >>> >> Basically, you can choose. To make sure we stress that, I would like to >> improve the previous sentence >> >> "The Exporter SHOULD send a single Template and corresponding Data >> Sets within a single stream in order to enable calculation of the >> potential Data Record loss for this Template ID. However, the >> Exporter MAY group related _(Options) _Templates and their >> corresponding Data Sets within a single stream so that loss >> statistics are calculated for the group. This is suitable in cases >> where there are only slight variations among the Templates in a >> group, e.g. the omission of unavailable fields for export >> efficiency, and may be necessary if the SCTP association does not >> support enough streams to export each Template in its own stream." >> >> >> > > Actually, I meant that statistics reports mentioned on section 4 in > RFC5101 are not based on per template. > In order to count total loss from observation point to collecting process, > some statistics templates in RFC5101 seem to be improved. > > But, it seems be out of scope of this document.. > Actually, the loss must be deduced at the Collector. I guess that you have in mind the Mediator that could relay the information to another Collector. Regards, Benoit. --------------060100020209060203000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kobayashi-san
Hi Benoit,

Please see in-line.

On Thu, 23 Oct 2008 13:24:03 +0200
Benoit Claise <bclaise@cisco.com> wrote:

  
Kobayashi-san,

Thank you very much for your review.
Note that the draft excerpts are in this email contained already the 
improvements proposed by Brian.
    
Dear all,

I did not have enough time for reviewing for the draft in Aug.
Although the time limit exceeds, I have reviewed the draft.

Please see my questions and comments and so on in lines.

Q1)
I think that the following condition is configurable choice.
- One stream treats one Template Record and associated Data Records.
- One stream treats some Template Records and associated Data Records
related to same Observation Domain, or same Observation Points.
It can deduce Data Record Loss per observation domai
>>
>> "The Exporter SHOULD send a single Template and corresponding Data Sets 
>> within a single stream in order to enable calculation of the potential 
>> Data Record loss for this Template ID.  However, the Exporter MAY group 
>> related Templates and their corresponding Data Sets within a single 
>> stream so that loss statistics are calculated for the group.  This is 
>> suitable in cases where there are only slight variations among the 
>> Templates in a group, e.g. the omission of unavailable fields for export 
>> efficiency, and may be necessary if the SCTP association does not 
>> support enough streams to export each Template in its own stream."
>>
>>     
>
> I can image following case.
> In general purposes, IPv4/IPv6 templates and data captured by same
> metering process and same sampling rate are exported on same sctp stream.
> On the other hand, specified application data and template which contain
> additional fields, for different purpose e.g. QoS measurement, are
> exported on different sctp stream. 
>
> Templates and data will be grouped according to the purposes or scope of
> measurement which depend on loss sensitivity. 
>   
Exactly.
>   
>>> Q2)
>>> This draft does not describe how to export some statistics option
>>> template and data. Should they be exported on same stream exporting
>>> associated Template and Data Records ?
>>>   
>>>       
>> Basically, you can choose. To make sure we stress that, I would like to 
>> improve the previous sentence
>>
>>     "The Exporter SHOULD send a single Template and corresponding Data
>>     Sets within a single stream in order to enable calculation of the
>>     potential Data Record loss for this Template ID.  However, the
>>     Exporter MAY group related _(Options) _Templates and their
>>     corresponding Data Sets within a single stream so that loss
>>     statistics are calculated for the group.  This is suitable in cases
>>     where there are only slight variations among the Templates in a
>>     group, e.g. the omission of unavailable fields for export
>>     efficiency, and may be necessary if the SCTP association does not
>>     support enough streams to export each Template in its own stream."
>>
>>
>>     
>
> Actually, I meant that statistics reports mentioned on section 4 in
> RFC5101 are not based on per template.
> In order to count total loss from observation point to collecting process, 
> some statistics templates in RFC5101 seem to be improved.
>
> But, it seems be out of scope of this document..
>   
Actually, the loss must be deduced at the Collector.
I guess that you have in mind the Mediator that could relay the 
information to another Collector.

Regards, Benoit.

--------------060100020209060203000402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Kobayashi-san



  
Hi Benoit,

Please see in-line.

On Thu, 23 Oct 2008 13:24:03 +0200
Benoit Claise <bclaise@cisco.com> wrote:

  

  

    
Kobayashi-san,

Thank you very much for your review.
Note that the draft excerpts are in this email contained already the 
improvements proposed by Brian.
    

    

      
Dear all,

I did not have enough time for reviewing for the draft in Aug.
Although the time limit exceeds, I have reviewed the draft.

Please see my questions and comments and so on in lines.

Q1)
I think that the following condition is configurable choice.
- One stream treats one Template Record and associated Data Records.
- One stream treats some Template Records and associated Data Records
related to same Observation Domain, or same Observation Points.
It can deduce Data Record Loss per observation domn or observation points.
Does this draft cover the latter pattern ?
  
      

    

    
Yes, exactly. This is a configurable choice.

"The Exporter SHOULD send a single Template and corresponding Data Sets 
within a single stream in order to enable calculation of the potential 
Data Record loss for this Template ID.  However, the Exporter MAY group 
related Templates and their corresponding Data Sets within a single 
stream so that loss statistics are calculated for the group.  This is 
suitable in cases where there are only slight variations among the 
Templates in a group, e.g. the omission of unavailable fields for export 
efficiency, and may be necessary if the SCTP association does not 
support enough streams to export each Template in its own stream."

    

  

  

I can image following case.
In general purposes, IPv4/IPv6 templates and data captured by same
metering process and same sampling rate are exported on same sctp stream.
On the other hand, specified application data and template which contain
additional fields, for different purpose e.g. QoS measurement, are
exported on different sctp stream. 

Templates and data will be grouped according to the purposes or scope of
measurement which depend on loss sensitivity. 
  



Exactly.



  
  

  

    

      
Q2)
This draft does not describe how to export some statistics option
template and data. Should they be exported on same stream exporting
associated Template and Data Records ?
  
      

    

    
Basically, you can choose. To make sure we stress that, I would like to 
improve the previous sentence

    "The Exporter SHOULD send a single Template and corresponding Data
    Sets within a single stream in order to enable calculation of the
    potential Data Record loss for this Template ID.  However, the
    Exporter MAY group related _(Options) _Templates and their
    corresponding Data Sets within a single stream so that loss
    statistics are calculated for the group.  This is suitable in cases
    where there are only slight variations among the Templates in a
    group, e.g. the omission of unavailable fields for export
    efficiency, and may be necessary if the SCTP association does not
    support enough streams to export each Template in its own stream."


    

  

  

Actually, I meant that statistics reports mentioned on section 4 in
RFC5101 are not based on per template.
In order to count total loss from observation point to collecting process, 
some statistics templates in RFC5101 seem to be improved.

But, it seems be out of scope of this document..
  



Actually, the loss must be deduced at the Collector.

I guess that you have in mind the Mediator that could relay the
information to another Collector.



Regards, Benoit.




--------------060100020209060203000402--

--===============0928912414==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0928912414==--


ain or observation points.
Does this draft cover the latter pattern ?
  
      
Yes, exactly. This is a configurable choice.

"The Exporter SHOULD send a single Template and corresponding Data Sets 
within a single stream in order to enable calculation of the potential 
Data Record loss for this Template ID.  However, the Exporter MAY group 
related Templates and their corresponding Data Sets within a single 
stream so that loss statistics are calculated for the group.  This is 
suitable in cases where there are only slight variations among the 
Templates in a group, e.g. the omission of unavailable fields for export 
efficiency, and may be necessary if the SCTP association does not 
support enough streams to export each Template in its own stream."

    

I can image following case.
In general purposes, IPv4/IPv6 templates and data captured by same
metering process and same sampling rate are exported on same sctp stream.
On the other hand, specified application data and template which contain
additional fields, for different purpose e.g. QoS measurement, are
exported on different sctp stream. 

Templates and data will be grouped according to the purposes or scope of
measurement which depend on loss sensitivity.
Exactly.
  
Q2)
This draft does not describe how to export some statistics option
template and data. Should they be exported on same stream exporting
associated Template and Data Records ?
  
      
Basically, you can choose. To make sure we stress that, I would like to 
improve the previous sentence

    "The Exporter SHOULD send a single Template and corresponding Data
    Sets within a single stream in order to enable calculation of the
    potential Data Record loss for this Template ID.  However, the
    Exporter MAY group related _(Options) _Templates and their
    corresponding Data Sets within a single stream so that loss
    statistics are calculated for the group.  This is suitable in cases
    where there are only slight variations among the Templates in a
    group, e.g. the omission of unavailable fields for export
    efficiency, and may be necessary if the SCTP association does not
    support enough streams to export each Template in its own stream."


    

Actually, I meant that statistics reports mentioned on section 4 in
RFC5101 are not based on per template.
In order to count total loss from observation point to collecting process, 
some statistics templates in RFC5101 seem to be improved.

But, it seems be out of scope of this document..
Actually, the loss must be deduced at the Collector.
I guess that you have in mind the Mediator that could relay the information to another Collector.

Regards, Benoit.
--------------060100020209060203000402-- --===============0928912414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0928912414==-- From ipfix-bounces@ietf.org Fri Oct 31 10:55:54 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE93B28C2B9; Fri, 31 Oct 2008 10:55:54 -0700 (PDT) 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 1698228C2AD for ; Fri, 31 Oct 2008 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4htOMpEZUghj for ; Fri, 31 Oct 2008 10:55:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1D39F3A6B90 for ; Fri, 31 Oct 2008 10:55:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,523,1220227200"; d="scan'208";a="24345637" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2008 17:55:28 +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 m9VHtSjX022227; Fri, 31 Oct 2008 18:55:28 +0100 Received: from [10.61.84.64] (ams3-vpn-dhcp5185.cisco.com [10.61.84.64]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VHtSWO000144; Fri, 31 Oct 2008 17:55:28 GMT Message-ID: <490B468F.2070808@cisco.com> Date: Fri, 31 Oct 2008 17:55:27 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Benoit Claise , "ipfix@ietf.org" References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> <490B2735.8030607@cisco.com> In-Reply-To: <490B2735.8030607@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=690; t=1225475728; x=1226339728; 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]=20WG=20last=20call=20on=20draft -ietf-ipfix-export-per-sctp-stream-00 |Sender:=20; bh=O6A2Vki01sULG59KWWwZuHDonTtBKHppo7zwD+jCaKs=; b=eV0fD893thUHci7ZgklpFl2SYyU2Oe8CSpf+gNUmjr5Y3kcQe4qA84QlVq jlZb/dEscoraV/nCqVyNfrxrim06xjLTN2QEXD7LkEQoip1nz4+Uphiwoh+G 7OZwqauCu5; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Benoit, > Are you fine with Brian's proposal? > > Template Reuse Delay > > The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template. [RFC5101] specifies a default > value of 5 seconds. Please rephrase that in better English, eg: The time the Exporting Process MUST wait after sending the last Data Set describFrom ipfix-bounces@ietf.org Fri Oct 31 10:55:54 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE93B28C2B9; Fri, 31 Oct 2008 10:55:54 -0700 (PDT) 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 1698228C2AD for ; Fri, 31 Oct 2008 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4htOMpEZUghj for ; Fri, 31 Oct 2008 10:55:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1D39F3A6B90 for ; Fri, 31 Oct 2008 10:55:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,523,1220227200"; d="scan'208";a="24345637" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2008 17:55:28 +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 m9VHtSjX022227; Fri, 31 Oct 2008 18:55:28 +0100 Received: from [10.61.84.64] (ams3-vpn-dhcp5185.cisco.com [10.61.84.64]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VHtSWO000144; Fri, 31 Oct 2008 17:55:28 GMT Message-ID: <490B468F.2070808@cisco.com> Date: Fri, 31 Oct 2008 17:55:27 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Benoit Claise , "ipfix@ietf.org" References: <20080902155307.F9E4.17391CF2@nttv6.net> <49005ED3.8050401@cisco.com> <490B2735.8030607@cisco.com> In-Reply-To: <490B2735.8030607@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=690; t=1225475728; x=1226339728; 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]=20WG=20last=20call=20on=20draft -ietf-ipfix-export-per-sctp-stream-00 |Sender:=20; bh=O6A2Vki01sULG59KWWwZuHDonTtBKHppo7zwD+jCaKs=; b=eV0fD893thUHci7ZgklpFl2SYyU2Oe8CSpf+gNUmjr5Y3kcQe4qA84QlVq jlZb/dEscoraV/nCqVyNfrxrim06xjLTN2QEXD7LkEQoip1nz4+Uphiwoh+G 7OZwqauCu5; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Benoit, > Are you fine with Brian's proposal? > > Template Reuse Delay > > The time after sending the last Data Set described by a given > Template the Exporting Process MUST wait before sending a Template > Withdrawal Message for the Template. [RFC5101] specifies a default > value of 5 seconds. Please rephrase that in better English, eg: The time the Exporting Process MUST wait after sending the last Data Set described by a given Template before sending a Template Withdrawal Message for the Template. [RFC5101] specifies a default value of 5 seconds. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ed by a given Template before sending a Template Withdrawal Message for the Template. [RFC5101] specifies a default value of 5 seconds. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix