From ipfix-bounces@ietf.org Sun Oct 01 11:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3FR-0003FM-Me; Sun, 01 Oct 2006 11:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3FQ-0003Dz-Hc for ipfix@ietf.org; Sun, 01 Oct 2006 11:28:56 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU3FO-0005Wl-NJ for ipfix@ietf.org; Sun, 01 Oct 2006 11:28:56 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5FE26125 for ; Sun, 1 Oct 2006 17:28:53 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28832-04 for ; Sun, 1 Oct 2006 17:28:50 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id A367211B for ; Sun, 1 Oct 2006 17:28:49 +0200 (MST) Message-ID: <451FDEF8.8090306@informatik.uni-tuebingen.de> Date: Sun, 01 Oct 2006 17:30:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> In-Reply-To: <451BFA80.8070206@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, So we are back to the same problem again concerning the double function of OD ID as stated in: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03400.html Last time, if I remember correctly, we more or less agreed on what is written in the current draft version in order to avoid bigger changes. Some remarks about the current discussion: Andrew Johnson wrote: > IPFIX INFO rev 12 the OD IDs were considered unique per Exporting > Process. That means that each Exporting Process could export > using it's own set of Observation Domain IDs and that the number > space is not common between them. > > Now we don't use the OD ID as an Exporting Process Identifier. We could actually use the Exporting Process ID in the IPFIX header instead, but than we have to assigne unique exporter IDs on a device. > In short, it is agreed that the EP of a connection cannot be > identified with the mandatory information. So Brain and I are > suggesting that the OD ID is considered unique per connection > session. Then we should call it session ID. > The alternative is to scope the Observation Domain ID to be > entire IPFIX device. This means that different Exporting > Processes will have to negotiate (or be configured) to use the > Observation Domains correctly. Furthermore, since template IDs > and other IEs are scoped to the OD ID, then if you wanted two > Exporters to report on the same Observation Domain (with the > same ID) then you would have to negotiate (or configure) use > of Template IDs, flow IDs, common properties IDs, ... This is maybe a stupid question: Can't we distinguish different Exporting Processes on a single device based on the source port number? > Part of the problem here is that the Observation Domain ID seems > to be seen as something useful. Imagine two flows that had > different common properties IDs. You wouldn't expect that to > be useful information without the options to explain what that > ID means. You can't even be assured that the two different IDs > actually map to different properties. The same is true for the > Observation Domain IDs. > > Originally the Observation Domain ID was called the Source ID. > This only changed in version 12 of the INFO draft. It's main > purpose is and always has been (see NetFlow version 9) to be > used to differentiate between templates seen on different Line > Cards of a distributed system. > > Let's examine the c7500 router from Cisco. In this example > we have a system of three line cards and we configure it to > monitor flows that are egressing from a single interface on > one of the Line Cards. > > Now the interface being monitored is present on Line Card 3, > however all the line cards and the Routing Processor could > observe and generate flows that are destined for that Interface. > That is because on a c7500 the output features are run on the > input Line Card. > > This means that the collector will see flow records from up > to four different sources: > > +----------------------------------------------------------+ > | Routing Processor | > +----------------------------------------------------------+ > | | | | > | +---------+ +---------+ +---------+ > | | LC 1 | | LC 2 | | LC 3 | > | +---------+ +---------+ +---------+ > | | | | > v v v v > +----------------------------------------------------------+ > | Collector | > +----------------------------------------------------------+ > > The collector will see a single UDP "session" from a single > Exporting Process, using 4 different source IDs (i.e. Observation > Domain IDs). > > It has been said that you need to know what Observation Domain > a flow was observed in order to aggregate the information > together. In the above case a single flow that has been load > balanced across interfaces on LCs 1 and 2 will generate two > flow records from different Observation Domains. Can you > aggregate? Of course you can! I assume that the administrator has to know the configuration of the monitoring device in this case. I think that we can suppose that this context information is available to him. > What is important is getting the right set of flow keys. In > this case the index of the output interface is important to > the user, so that must be included in the flow. > > If the Line Card that the flow was observed on is important > then put it in the flow (element 141). Agreed. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Oct 01 11:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3FR-0003FM-Me; Sun, 01 Oct 2006 11:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3FQ-0003Dz-Hc for ipfix@ietf.org; Sun, 01 Oct 2006 11:28:56 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU3FO-0005Wl-NJ for ipfix@ietf.org; Sun, 01 Oct 2006 11:28:56 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5FE26125 for ; Sun, 1 Oct 2006 17:28:53 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28832-04 for ; Sun, 1 Oct 2006 17:28:50 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id A367211B for ; Sun, 1 Oct 2006 17:28:49 +0200 (MST) Message-ID: <451FDEF8.8090306@informatik.uni-tuebingen.de> Date: Sun, 01 Oct 2006 17:30:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> In-Reply-To: <451BFA80.8070206@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, So we are back to the same problem again concerning the double function of OD ID as stated in: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03400.html Last time, if I remember correctly, we more or less agreed on what is written in the current draft version in order to avoid bigger changes. Some remarks about the current discussion: Andrew Johnson wrote: > IPFIX INFO rev 12 the OD IDs were considered unique per Exporting > Process. That means that each Exporting Process could export > using it's own set of Observation Domain IDs and that the number > space is not common between them. > > Now we don't use the OD ID as an Exporting Process Identifier. We could actually use the Exporting Process ID in the IPFIX header instead, but than we have to assigne unique exporter IDs on a device. > In short, it is agreed that the EP of a connection cannot be > identified with the mandatory information. So Brain and I are > suggesting that the OD ID is considered unique per connection > session. Then we should call it session ID. > The alternative is to scope the Observation Domain ID to be > entire IPFIX device. This means that different Exporting > Processes will have to negotiate (or be configured) to use the > Observation Domains correctly. Furthermore, since template IDs > and other IEs are scoped to the OD ID, then if you wanted two > Exporters to report on the same Observation Domain (with the > same ID) then you would have to negotiate (or configure) use > of Template IDs, flow IDs, common properties IDs, ... This is maybe a stupid question: Can't we distinguish different Exporting Processes on a single device based on the source port number? > Part of the problem here is that the Observation Domain ID seems > to be seen as something useful. Imagine two flows that had > different common properties IDs. You wouldn't expect that to > be useful information without the options to explain what that > ID means. You can't even be assured that the two different IDs > actually map to different properties. The same is true for the > Observation Domain IDs. > > Originally the Observation Domain ID was called the Source ID. > This only changed in version 12 of the INFO draft. It's main > purpose is and always has been (see NetFlow version 9) to be > used to differentiate between templates seen on different Line > Cards of a distributed system. > > Let's examine the c7500 router from Cisco. In this example > we have a system of three line cards and we configure it to > monitor flows that are egressing from a single interface on > one of the Line Cards. > > Now the interface being monitored is present on Line Card 3, > however all the line cards and the Routing Processor could > observe and generate flows that are destined for that Interface. > That is because on a c7500 the output features are run on the > input Line Card. > > This means that the collector will see flow records from up > to four different sources: > > +----------------------------------------------------------+ > | Routing Processor | > +----------------------------------------------------------+ > | | | | > | +---------+ +---------+ +---------+ > | | LC 1 | | LC 2 | | LC 3 | > | +---------+ +---------+ +---------+ > | | | | > v v v v > +----------------------------------------------------------+ > | Collector | > +----------------------------------------------------------+ > > The collector will see a single UDP "session" from a single > Exporting Process, using 4 different source IDs (i.e. Observation > Domain IDs). > > It has been said that you need to know what Observation Domain > a flow was observed in order to aggregate the information > together. In the above case a single flow that has been load > balanced across interfaces on LCs 1 and 2 will generate two > flow records from different Observation Domains. Can you > aggregate? Of course you can! I assume that the administrator has to know the configuration of the monitoring device in this case. I think that we can suppose that this context information is available to him. > What is important is getting the right set of flow keys. In > this case the index of the output interface is important to > the user, so that must be included in the flow. > > If the Line Card that the flow was observed on is important > then put it in the flow (element 141). Agreed. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Oct 01 12:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3wE-0004oX-SY; Sun, 01 Oct 2006 12:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3wD-0004oR-21 for ipfix@ietf.org; Sun, 01 Oct 2006 12:13:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU3w8-0000YZ-Bv for ipfix@ietf.org; Sun, 01 Oct 2006 12:13:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2006 09:13:04 -0700 X-IronPort-AV: i="4.09,241,1157353200"; d="scan'208"; a="44262966:sNHT55524392" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k91GD3Xq009487; Sun, 1 Oct 2006 12:13:04 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k91GD3g2010654; Sun, 1 Oct 2006 18:13:03 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14905; Sun, 1 Oct 2006 17:13:01 +0100 (BST) Message-ID: <451FE90C.7080803@cisco.com> Date: Sun, 01 Oct 2006 17:13:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> In-Reply-To: <451FDEF8.8090306@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3196; t=1159719184; x=1160583184; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Gerhard=20Muenz=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=mx5GTymI0ZCfAbjFc75fzQsZ+edvOCQbjJ1dLOzjQqXfQXwlUFWuZUhDRcZt29mP4qG8GISV CB5N+hYxS+xAN8fLoBfbYN4TK6gCQs+3ZsgbAdU5GqFLx3xAhBlCuDn+; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Gerhard, >>Now we don't use the OD ID as an Exporting Process Identifier. > > We could actually use the Exporting Process ID in the IPFIX header > instead, but than we have to assigne unique exporter IDs on a device. Then these IDs probably have to be assigned manually, because exporters from different vendors which are running on the same IPFIX device can't be expected to communicate with one another to arrange their own unique IDs. Then, as a user, it would be unclear to me why I have to assign unique IDs to all my exporters when really I don't care about exporters at all. What I do care about are: a) what data were observed? - which is conveyed in template and data records, and b) where that data was observed - which may be somewhat conveyed by the OD ID, but see below. What I (as a user) don't care about is which particular exporter sent that information to me. Though the way things stand today, the CP certainly does need to know which exporter sent the info so it can deal with IDs that are scoped to that exporter. >>In short, it is agreed that the EP of a connection cannot be >>identified with the mandatory information. So Brain and I are >>suggesting that the OD ID is considered unique per connection >>session. > > > Then we should call it session ID. No; "session ID" implies an identifier for the session. Whereas the OD ID being unique per session is quite different; it means that this OD ID only has any meaning in the context of this session, and the same OD ID on another session means something else. But it does not identify the session; the source address and port do that. > This is maybe a stupid question: Can't we distinguish different > Exporting Processes on a single device based on the source port number? Nope. Suppose one IPFIX device with two exporters, and suppose each exporter has two export sessions. So ports 1001, 1002, 1003 and 1004 are in use. Which port belongs to which exporter? -> you don't know. > I assume that the administrator has to know the configuration of the > monitoring device in this case. I think that we can suppose that this > context information is available to him. I'd hope that the administrator always has a good understanding of the configuration of the monitoring device. Unless we move to automatic / self configuration... >>What is important is getting the right set of flow keys. In >>this case the index of the output interface is important to >>the user, so that must be included in the flow. >> >>If the Line Card that the flow was observed on is important >>then put it in the flow (element 141). > > Agreed. Then we're agreed that instead of mapping the OD ID directly to an OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this information should be encoded in the flow if it's important? (Even using the reducing-redundancy technique for multiple flows.) Then the OD ID is just an ID that helps us to differentiate templates that have the same template IDs but pertain to different domains. Right? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Oct 01 12:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3wE-0004oX-SY; Sun, 01 Oct 2006 12:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU3wD-0004oR-21 for ipfix@ietf.org; Sun, 01 Oct 2006 12:13:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU3w8-0000YZ-Bv for ipfix@ietf.org; Sun, 01 Oct 2006 12:13:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2006 09:13:04 -0700 X-IronPort-AV: i="4.09,241,1157353200"; d="scan'208"; a="44262966:sNHT55524392" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k91GD3Xq009487; Sun, 1 Oct 2006 12:13:04 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k91GD3g2010654; Sun, 1 Oct 2006 18:13:03 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14905; Sun, 1 Oct 2006 17:13:01 +0100 (BST) Message-ID: <451FE90C.7080803@cisco.com> Date: Sun, 01 Oct 2006 17:13:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> In-Reply-To: <451FDEF8.8090306@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3196; t=1159719184; x=1160583184; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Gerhard=20Muenz=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=mx5GTymI0ZCfAbjFc75fzQsZ+edvOCQbjJ1dLOzjQqXfQXwlUFWuZUhDRcZt29mP4qG8GISV CB5N+hYxS+xAN8fLoBfbYN4TK6gCQs+3ZsgbAdU5GqFLx3xAhBlCuDn+; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Gerhard, >>Now we don't use the OD ID as an Exporting Process Identifier. > > We could actually use the Exporting Process ID in the IPFIX header > instead, but than we have to assigne unique exporter IDs on a device. Then these IDs probably have to be assigned manually, because exporters from different vendors which are running on the same IPFIX device can't be expected to communicate with one another to arrange their own unique IDs. Then, as a user, it would be unclear to me why I have to assign unique IDs to all my exporters when really I don't care about exporters at all. What I do care about are: a) what data were observed? - which is conveyed in template and data records, and b) where that data was observed - which may be somewhat conveyed by the OD ID, but see below. What I (as a user) don't care about is which particular exporter sent that information to me. Though the way things stand today, the CP certainly does need to know which exporter sent the info so it can deal with IDs that are scoped to that exporter. >>In short, it is agreed that the EP of a connection cannot be >>identified with the mandatory information. So Brain and I are >>suggesting that the OD ID is considered unique per connection >>session. > > > Then we should call it session ID. No; "session ID" implies an identifier for the session. Whereas the OD ID being unique per session is quite different; it means that this OD ID only has any meaning in the context of this session, and the same OD ID on another session means something else. But it does not identify the session; the source address and port do that. > This is maybe a stupid question: Can't we distinguish different > Exporting Processes on a single device based on the source port number? Nope. Suppose one IPFIX device with two exporters, and suppose each exporter has two export sessions. So ports 1001, 1002, 1003 and 1004 are in use. Which port belongs to which exporter? -> you don't know. > I assume that the administrator has to know the configuration of the > monitoring device in this case. I think that we can suppose that this > context information is available to him. I'd hope that the administrator always has a good understanding of the configuration of the monitoring device. Unless we move to automatic / self configuration... >>What is important is getting the right set of flow keys. In >>this case the index of the output interface is important to >>the user, so that must be included in the flow. >> >>If the Line Card that the flow was observed on is important >>then put it in the flow (element 141). > > Agreed. Then we're agreed that instead of mapping the OD ID directly to an OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this information should be encoded in the flow if it's important? (Even using the reducing-redundancy technique for multiple flows.) Then the OD ID is just an ID that helps us to differentiate templates that have the same template IDs but pertain to different domains. Right? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 06:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKqI-0003ka-UO; Mon, 02 Oct 2006 06:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKqH-0003kU-1S for ipfix@ietf.org; Mon, 02 Oct 2006 06:16:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKqF-00034C-Qa for ipfix@ietf.org; Mon, 02 Oct 2006 06:16:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 06:16:07 -0400 X-IronPort-AV: i="4.09,243,1157342400"; d="scan'208"; a="105342100:sNHT434330664" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92AG7om006602 for ; Mon, 2 Oct 2006 06:16:07 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92AG6g2014684 for ; Mon, 2 Oct 2006 12:16:06 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12477 for ; Mon, 2 Oct 2006 11:16:05 +0100 (BST) Message-ID: <4520E6E4.80701@cisco.com> Date: Mon, 02 Oct 2006 11:16:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1375; t=1159784167; x=1160648167; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:IPFIX=20fragmentIdentification |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DDD/LXQZTmxMW3daiHudxtcLOm2c=3D; b=YfZksBJv0cr/ZmumUplqjJ+WZ0fi8rnWwg2Z648txTlUotqIMEIzYM0CC5cqL7nBwsmnmVp5 trCu0/MWHAlkiRcD1NttMQfsoFBskJmo7imSnPsOV6unLcQ+ODXJWW91; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [IPFIX] IPFIX fragmentIdentification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org IPFIX fragmentIdentification is defined as: The value of the Identification field in the IPv4 packet header or the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no Fragment header. So the IPv4 ID and IPv6 fragmentation ID are combined in a single field. RFC 791 shows the IPv4 Identification is 16 bits: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Whereas RFC 2460 shows the IPv6 ID is 32 bits: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to extend the IPv4 ID to 32 bits. Seems that it would be more correct to have two different IDs for these? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 06:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKqI-0003ka-UO; Mon, 02 Oct 2006 06:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKqH-0003kU-1S for ipfix@ietf.org; Mon, 02 Oct 2006 06:16:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKqF-00034C-Qa for ipfix@ietf.org; Mon, 02 Oct 2006 06:16:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 06:16:07 -0400 X-IronPort-AV: i="4.09,243,1157342400"; d="scan'208"; a="105342100:sNHT434330664" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92AG7om006602 for ; Mon, 2 Oct 2006 06:16:07 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92AG6g2014684 for ; Mon, 2 Oct 2006 12:16:06 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12477 for ; Mon, 2 Oct 2006 11:16:05 +0100 (BST) Message-ID: <4520E6E4.80701@cisco.com> Date: Mon, 02 Oct 2006 11:16:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1375; t=1159784167; x=1160648167; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:IPFIX=20fragmentIdentification |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DDD/LXQZTmxMW3daiHudxtcLOm2c=3D; b=YfZksBJv0cr/ZmumUplqjJ+WZ0fi8rnWwg2Z648txTlUotqIMEIzYM0CC5cqL7nBwsmnmVp5 trCu0/MWHAlkiRcD1NttMQfsoFBskJmo7imSnPsOV6unLcQ+ODXJWW91; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [IPFIX] IPFIX fragmentIdentification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org IPFIX fragmentIdentification is defined as: The value of the Identification field in the IPv4 packet header or the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no Fragment header. So the IPv4 ID and IPv6 fragmentation ID are combined in a single field. RFC 791 shows the IPv4 Identification is 16 bits: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Whereas RFC 2460 shows the IPv6 ID is 32 bits: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to extend the IPv4 ID to 32 bits. Seems that it would be more correct to have two different IDs for these? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 08:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNDY-0000xS-2Z; Mon, 02 Oct 2006 08:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNDV-0000xK-Oy for ipfix@ietf.org; Mon, 02 Oct 2006 08:48:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNDU-0001ek-IF for ipfix@ietf.org; Mon, 02 Oct 2006 08:48:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 08:48:16 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105358871:sNHT46197584" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92CmFY1010224 for ; Mon, 2 Oct 2006 08:48:16 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92CmFg2001595 for ; Mon, 2 Oct 2006 14:48:15 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA27241 for ; Mon, 2 Oct 2006 13:48:14 +0100 (BST) Message-ID: <45210A8D.6010202@cisco.com> Date: Mon, 02 Oct 2006 13:48:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=317; t=1159793296; x=1160657296; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:IPFIX=20totalLength? |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DA4F5hw4WdAez7ozcObJ+jSt0Zvg=3D; b=mVZQ3RHPNsGfj8V1zPXzwctnmwnmIAOqgk53ZIx+LkGcZlXpWA/qeugmQUG6cZ9WfcCk68jU oPDBSjSOuayk499mespvVyh/L6zp9ii3i5jhQ4xYRFO5YwDGrTFioRsh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [IPFIX] IPFIX totalLength? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I could not find one. Probably all we can do is to calculate #191 payloadLengthIPv6 + 40. A new IE, "totalLengthIPv6", would be useful - as would a generic "IPtotalLength" IE. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 08:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNDY-0000xS-2Z; Mon, 02 Oct 2006 08:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNDV-0000xK-Oy for ipfix@ietf.org; Mon, 02 Oct 2006 08:48:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNDU-0001ek-IF for ipfix@ietf.org; Mon, 02 Oct 2006 08:48:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 08:48:16 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105358871:sNHT46197584" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92CmFY1010224 for ; Mon, 2 Oct 2006 08:48:16 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92CmFg2001595 for ; Mon, 2 Oct 2006 14:48:15 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA27241 for ; Mon, 2 Oct 2006 13:48:14 +0100 (BST) Message-ID: <45210A8D.6010202@cisco.com> Date: Mon, 02 Oct 2006 13:48:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=317; t=1159793296; x=1160657296; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:IPFIX=20totalLength? |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DA4F5hw4WdAez7ozcObJ+jSt0Zvg=3D; b=mVZQ3RHPNsGfj8V1zPXzwctnmwnmIAOqgk53ZIx+LkGcZlXpWA/qeugmQUG6cZ9WfcCk68jU oPDBSjSOuayk499mespvVyh/L6zp9ii3i5jhQ4xYRFO5YwDGrTFioRsh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [IPFIX] IPFIX totalLength? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I could not find one. Probably all we can do is to calculate #191 payloadLengthIPv6 + 40. A new IE, "totalLengthIPv6", would be useful - as would a generic "IPtotalLength" IE. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 09:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNwE-0005dQ-Tz; Mon, 02 Oct 2006 09:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNwE-0005af-5R for ipfix@ietf.org; Mon, 02 Oct 2006 09:34:30 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNwB-0002O7-U0 for ipfix@ietf.org; Mon, 02 Oct 2006 09:34:30 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92DYLGw004211 for ; Mon, 2 Oct 2006 09:34:23 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92DXKB2004166 for ; Mon, 2 Oct 2006 09:33:20 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92DXJKR004164; Mon, 02 Oct 2006 09:33:20 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92DXJrS006889; Mon, 2 Oct 2006 09:33:19 -0400 In-Reply-To: <451FE90C.7080803@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions Date: Mon, 2 Oct 2006 09:32:48 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 1, 2006, at 12:13 PM, Paul Aitken wrote: >>> What is important is getting the right set of flow keys. In >>> this case the index of the output interface is important to >>> the user, so that must be included in the flow. >>> >>> If the Line Card that the flow was observed on is important >>> then put it in the flow (element 141). >> Agreed. > > Then we're agreed that instead of mapping the OD ID directly to an > OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this > information should be encoded in the flow if it's important? (Even > using the reducing-redundancy technique for multiple flows.) > > Then the OD ID is just an ID that helps us to differentiate > templates that have the same template IDs but pertain to different > domains. Right? That's my view of it, with a couple of caveats: 1. to "differentiate templates" I'd add "differentiate scoped options" (because odId is also the root of all other scopes, especially cpId as in reducing-redundancy). 2. we may want to allow implementors to allow operators to shoot themselves in the foot with odId, if they're sure they know what they're doing, as follows: A. the EP implementation MAY allow the user to configure odIDs manually, B. the CP implementation MAY allow the user to do something with the odID (such as storing it with the flow); however C. if not specifically configured in this way, the CP MUST NOT store the odID (much as it doesn't store the tID now). Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 09:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNwE-0005dQ-Tz; Mon, 02 Oct 2006 09:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNwE-0005af-5R for ipfix@ietf.org; Mon, 02 Oct 2006 09:34:30 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNwB-0002O7-U0 for ipfix@ietf.org; Mon, 02 Oct 2006 09:34:30 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92DYLGw004211 for ; Mon, 2 Oct 2006 09:34:23 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92DXKB2004166 for ; Mon, 2 Oct 2006 09:33:20 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92DXJKR004164; Mon, 02 Oct 2006 09:33:20 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92DXJrS006889; Mon, 2 Oct 2006 09:33:19 -0400 In-Reply-To: <451FE90C.7080803@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions Date: Mon, 2 Oct 2006 09:32:48 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 1, 2006, at 12:13 PM, Paul Aitken wrote: >>> What is important is getting the right set of flow keys. In >>> this case the index of the output interface is important to >>> the user, so that must be included in the flow. >>> >>> If the Line Card that the flow was observed on is important >>> then put it in the flow (element 141). >> Agreed. > > Then we're agreed that instead of mapping the OD ID directly to an > OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this > information should be encoded in the flow if it's important? (Even > using the reducing-redundancy technique for multiple flows.) > > Then the OD ID is just an ID that helps us to differentiate > templates that have the same template IDs but pertain to different > domains. Right? That's my view of it, with a couple of caveats: 1. to "differentiate templates" I'd add "differentiate scoped options" (because odId is also the root of all other scopes, especially cpId as in reducing-redundancy). 2. we may want to allow implementors to allow operators to shoot themselves in the foot with odId, if they're sure they know what they're doing, as follows: A. the EP implementation MAY allow the user to configure odIDs manually, B. the CP implementation MAY allow the user to do something with the odID (such as storing it with the flow); however C. if not specifically configured in this way, the CP MUST NOT store the odID (much as it doesn't store the tID now). Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 09:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO5r-0004ZS-AO; Mon, 02 Oct 2006 09:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO5p-0004ZN-MD for ipfix@ietf.org; Mon, 02 Oct 2006 09:44:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUO5o-00048N-DH for ipfix@ietf.org; Mon, 02 Oct 2006 09:44:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 09:44:14 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105368253:sNHT2154409936" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92DiDOr019398; Mon, 2 Oct 2006 09:44:14 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92DiDg2021189; Mon, 2 Oct 2006 15:44:13 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA03238; Mon, 2 Oct 2006 14:44:11 +0100 (BST) Message-ID: <452117AA.1010402@cisco.com> Date: Mon, 02 Oct 2006 14:44:10 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> In-Reply-To: <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2227; t=1159796654; x=1160660654; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=lIBm0iluRCSMFUug1J1IZ0fC+6qfHfMpn5InxuRsGFbXsL0VWDjdUwAvwOXqpXacBuAL1Qvp /60e7Igb0+qLfRDRJaCoXCbjri5OhKf+c7O6NbnP9Tpw2eua9C3I3QSz; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >> Then we're agreed that instead of mapping the OD ID directly to an OD >> (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this >> information should be encoded in the flow if it's important? (Even >> using the reducing-redundancy technique for multiple flows.) >> >> Then the OD ID is just an ID that helps us to differentiate templates >> that have the same template IDs but pertain to different domains. Right? > > > That's my view of it, with a couple of caveats: > > 1. to "differentiate templates" I'd add "differentiate scoped options" > (because odId is also the root of all other scopes, especially cpId as > in reducing-redundancy). Agreed. > 2. we may want to allow implementors to allow operators to shoot > themselves in the foot with odId, if they're sure they know what > they're doing, as follows: A. the EP implementation MAY allow the user > to configure odIDs manually, B. the CP implementation MAY allow the > user to do something with the odID (such as storing it with the flow); > however C. if not specifically configured in this way, the CP MUST NOT > store the odID (much as it doesn't store the tID now). Why would you store the OD ID with the flow data? Firstly, we just agreed that it's not going to tell you anything useful about the data. It only helps you figure out which templates (including options, ACK) to use to decode the data, and presumably you've already done that part. Secondly, the OD ID will be completely out of context. By your own arguments, it's only valid within the scope of an export session. Making it available outwith that session is just meaningless. If the OD ID only helps us to scope templates (including options) then that's *all* we must do with it. It mustn't be stored in or with the flow data *as if* it has some other meaning. OTOH if it does have some other meaning (eg, 0x0102 maps to "linecard 2") then it would make sense to store it with the flow data. But that's saying that OD IDs are configured per device, and is contrary to the idea that the OD ID is unique within the export session. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 09:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO5r-0004ZS-AO; Mon, 02 Oct 2006 09:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO5p-0004ZN-MD for ipfix@ietf.org; Mon, 02 Oct 2006 09:44:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUO5o-00048N-DH for ipfix@ietf.org; Mon, 02 Oct 2006 09:44:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 09:44:14 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105368253:sNHT2154409936" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92DiDOr019398; Mon, 2 Oct 2006 09:44:14 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92DiDg2021189; Mon, 2 Oct 2006 15:44:13 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA03238; Mon, 2 Oct 2006 14:44:11 +0100 (BST) Message-ID: <452117AA.1010402@cisco.com> Date: Mon, 02 Oct 2006 14:44:10 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> In-Reply-To: <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2227; t=1159796654; x=1160660654; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=lIBm0iluRCSMFUug1J1IZ0fC+6qfHfMpn5InxuRsGFbXsL0VWDjdUwAvwOXqpXacBuAL1Qvp /60e7Igb0+qLfRDRJaCoXCbjri5OhKf+c7O6NbnP9Tpw2eua9C3I3QSz; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >> Then we're agreed that instead of mapping the OD ID directly to an OD >> (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this >> information should be encoded in the flow if it's important? (Even >> using the reducing-redundancy technique for multiple flows.) >> >> Then the OD ID is just an ID that helps us to differentiate templates >> that have the same template IDs but pertain to different domains. Right? > > > That's my view of it, with a couple of caveats: > > 1. to "differentiate templates" I'd add "differentiate scoped options" > (because odId is also the root of all other scopes, especially cpId as > in reducing-redundancy). Agreed. > 2. we may want to allow implementors to allow operators to shoot > themselves in the foot with odId, if they're sure they know what > they're doing, as follows: A. the EP implementation MAY allow the user > to configure odIDs manually, B. the CP implementation MAY allow the > user to do something with the odID (such as storing it with the flow); > however C. if not specifically configured in this way, the CP MUST NOT > store the odID (much as it doesn't store the tID now). Why would you store the OD ID with the flow data? Firstly, we just agreed that it's not going to tell you anything useful about the data. It only helps you figure out which templates (including options, ACK) to use to decode the data, and presumably you've already done that part. Secondly, the OD ID will be completely out of context. By your own arguments, it's only valid within the scope of an export session. Making it available outwith that session is just meaningless. If the OD ID only helps us to scope templates (including options) then that's *all* we must do with it. It mustn't be stored in or with the flow data *as if* it has some other meaning. OTOH if it does have some other meaning (eg, 0x0102 maps to "linecard 2") then it would make sense to store it with the flow data. But that's saying that OD IDs are configured per device, and is contrary to the idea that the OD ID is unique within the export session. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOPC-0007j7-3r; Mon, 02 Oct 2006 10:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOPB-0007iy-1h for ipfix@ietf.org; Mon, 02 Oct 2006 10:04:25 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOP9-0006Kl-Pd for ipfix@ietf.org; Mon, 02 Oct 2006 10:04:25 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92E4LvD008226 for ; Mon, 2 Oct 2006 10:04:21 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92E3A6o008160 for ; Mon, 2 Oct 2006 10:03:10 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92E3Aom008158; Mon, 02 Oct 2006 10:03:10 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92E3APk011988; Mon, 2 Oct 2006 10:03:10 -0400 In-Reply-To: <452117AA.1010402@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions Date: Mon, 2 Oct 2006 10:02:39 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 2, 2006, at 9:44 AM, Paul Aitken wrote: > Brian, > >>> Then we're agreed that instead of mapping the OD ID directly to >>> an OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that >>> this information should be encoded in the flow if it's >>> important? (Even using the reducing-redundancy technique for >>> multiple flows.) >>> >>> Then the OD ID is just an ID that helps us to differentiate >>> templates that have the same template IDs but pertain to >>> different domains. Right? >> That's my view of it, with a couple of caveats: >> 1. to "differentiate templates" I'd add "differentiate scoped >> options" (because odId is also the root of all other scopes, >> especially cpId as in reducing-redundancy). > > Agreed. > >> 2. we may want to allow implementors to allow operators to shoot >> themselves in the foot with odId, if they're sure they know what >> they're doing, as follows: A. the EP implementation MAY allow the >> user to configure odIDs manually, B. the CP implementation MAY >> allow the user to do something with the odID (such as storing it >> with the flow); however C. if not specifically configured in this >> way, the CP MUST NOT store the odID (much as it doesn't store the >> tID now). > > Why would you store the OD ID with the flow data? The only reason to do so is if you know 1. it was manually assigned and 2. is stable (I'm thinking about a specific use case I have here). But, you're right; if we really need this, we have more than enough in the way of information elements with _actual meaning_ to do the same thing. (Complete aside, it would be really nice to have a way to scope a value to a message. Perhaps a zero-length IE whose presence as scope means the option applies to the entire message?) > Firstly, we just agreed that it's not going to tell you anything > useful about the data. It only helps you figure out which templates > (including options, ACK) to use to decode the data, and presumably > you've already done that part. > > Secondly, the OD ID will be completely out of context. By your own > arguments, it's only valid within the scope of an export session. > Making it available outwith that session is just meaningless. > > If the OD ID only helps us to scope templates (including options) > then that's *all* we must do with it. It mustn't be stored in or > with the flow data *as if* it has some other meaning. These are all excellent points, so I'm going to go ahead and declare myself convinced. Strike caveat 2. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOPC-0007j7-3r; Mon, 02 Oct 2006 10:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOPB-0007iy-1h for ipfix@ietf.org; Mon, 02 Oct 2006 10:04:25 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOP9-0006Kl-Pd for ipfix@ietf.org; Mon, 02 Oct 2006 10:04:25 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92E4LvD008226 for ; Mon, 2 Oct 2006 10:04:21 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92E3A6o008160 for ; Mon, 2 Oct 2006 10:03:10 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92E3Aom008158; Mon, 02 Oct 2006 10:03:10 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92E3APk011988; Mon, 2 Oct 2006 10:03:10 -0400 In-Reply-To: <452117AA.1010402@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions Date: Mon, 2 Oct 2006 10:02:39 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 2, 2006, at 9:44 AM, Paul Aitken wrote: > Brian, > >>> Then we're agreed that instead of mapping the OD ID directly to >>> an OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that >>> this information should be encoded in the flow if it's >>> important? (Even using the reducing-redundancy technique for >>> multiple flows.) >>> >>> Then the OD ID is just an ID that helps us to differentiate >>> templates that have the same template IDs but pertain to >>> different domains. Right? >> That's my view of it, with a couple of caveats: >> 1. to "differentiate templates" I'd add "differentiate scoped >> options" (because odId is also the root of all other scopes, >> especially cpId as in reducing-redundancy). > > Agreed. > >> 2. we may want to allow implementors to allow operators to shoot >> themselves in the foot with odId, if they're sure they know what >> they're doing, as follows: A. the EP implementation MAY allow the >> user to configure odIDs manually, B. the CP implementation MAY >> allow the user to do something with the odID (such as storing it >> with the flow); however C. if not specifically configured in this >> way, the CP MUST NOT store the odID (much as it doesn't store the >> tID now). > > Why would you store the OD ID with the flow data? The only reason to do so is if you know 1. it was manually assigned and 2. is stable (I'm thinking about a specific use case I have here). But, you're right; if we really need this, we have more than enough in the way of information elements with _actual meaning_ to do the same thing. (Complete aside, it would be really nice to have a way to scope a value to a message. Perhaps a zero-length IE whose presence as scope means the option applies to the entire message?) > Firstly, we just agreed that it's not going to tell you anything > useful about the data. It only helps you figure out which templates > (including options, ACK) to use to decode the data, and presumably > you've already done that part. > > Secondly, the OD ID will be completely out of context. By your own > arguments, it's only valid within the scope of an export session. > Making it available outwith that session is just meaningless. > > If the OD ID only helps us to scope templates (including options) > then that's *all* we must do with it. It mustn't be stored in or > with the flow data *as if* it has some other meaning. These are all excellent points, so I'm going to go ahead and declare myself convinced. Strike caveat 2. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUObl-0002mY-AW; Mon, 02 Oct 2006 10:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUObk-0002m2-03 for ipfix@ietf.org; Mon, 02 Oct 2006 10:17:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUObi-0007v5-Nw for ipfix@ietf.org; Mon, 02 Oct 2006 10:17:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 10:17:22 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105374318:sNHT73776024" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EHMXN007973; Mon, 2 Oct 2006 10:17:22 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92EHKg2003109; Mon, 2 Oct 2006 16:17:20 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07399; Mon, 2 Oct 2006 15:17:19 +0100 (BST) Message-ID: <45211F6F.7030105@cisco.com> Date: Mon, 02 Oct 2006 15:17:19 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> In-Reply-To: <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2541; t=1159798642; x=1160662642; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=Xklf6/Eh7vrKog9ppQYzAyfywPwMKu1l01JIF1M48K0fhAZssxwkY8IXiE9cfZqQdGtyrVwT E1sj/CpxstOQ8ex+WcDo98k0EuuiswgbrHDpFVr3EbF8czz0On0u47/l; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >>> 2. we may want to allow implementors to allow operators to shoot >>> themselves in the foot with odId, if they're sure they know what >>> they're doing, as follows: A. the EP implementation MAY allow the >>> user to configure odIDs manually, B. the CP implementation MAY >>> allow the user to do something with the odID (such as storing it >>> with the flow); however C. if not specifically configured in this >>> way, the CP MUST NOT store the odID (much as it doesn't store the >>> tID now). >> >> >> Why would you store the OD ID with the flow data? > > > The only reason to do so is if you know 1. it was manually assigned and > 2. is stable (I'm thinking about a specific use case I have here). Then you're attributing a device-wide meaning to an exporter session specific ID. Or looked at another way, you're unnecessarily overloading the OD ID. > But, you're right; if we really need this, we have more than enough in the > way of information elements with _actual meaning_ to do the same thing. Agreed. If the OD ID can be attributed with some information, then put that info in the flow data. If it's duplicated for every flow, then use the techniques in the reducing-redundancy draft. > (Complete aside, it would be really nice to have a way to scope a value > to a message. Perhaps a zero-length IE whose presence as scope means > the option applies to the entire message?) I did recently ask whether a) it's valid to send a zero-length IE (though as data, not as scope) and b) what it means. Seems that it's valid, and probably means that the implimentation is broken ;-) >> Firstly, we just agreed that it's not going to tell you anything >> useful about the data. It only helps you figure out which templates >> (including options, ACK) to use to decode the data, and presumably >> you've already done that part. >> >> Secondly, the OD ID will be completely out of context. By your own >> arguments, it's only valid within the scope of an export session. >> Making it available outwith that session is just meaningless. >> >> If the OD ID only helps us to scope templates (including options) >> then that's *all* we must do with it. It mustn't be stored in or with >> the flow data *as if* it has some other meaning. > > > These are all excellent points, so I'm going to go ahead and declare > myself convinced. Strike caveat 2. :-) -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUObl-0002mY-AW; Mon, 02 Oct 2006 10:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUObk-0002m2-03 for ipfix@ietf.org; Mon, 02 Oct 2006 10:17:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUObi-0007v5-Nw for ipfix@ietf.org; Mon, 02 Oct 2006 10:17:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 10:17:22 -0400 X-IronPort-AV: i="4.09,244,1157342400"; d="scan'208"; a="105374318:sNHT73776024" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EHMXN007973; Mon, 2 Oct 2006 10:17:22 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92EHKg2003109; Mon, 2 Oct 2006 16:17:20 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07399; Mon, 2 Oct 2006 15:17:19 +0100 (BST) Message-ID: <45211F6F.7030105@cisco.com> Date: Mon, 02 Oct 2006 15:17:19 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> In-Reply-To: <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2541; t=1159798642; x=1160662642; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3D0rF9t2nfvp2M/OxDWRhBU7RCWE4=3D; b=Xklf6/Eh7vrKog9ppQYzAyfywPwMKu1l01JIF1M48K0fhAZssxwkY8IXiE9cfZqQdGtyrVwT E1sj/CpxstOQ8ex+WcDo98k0EuuiswgbrHDpFVr3EbF8czz0On0u47/l; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >>> 2. we may want to allow implementors to allow operators to shoot >>> themselves in the foot with odId, if they're sure they know what >>> they're doing, as follows: A. the EP implementation MAY allow the >>> user to configure odIDs manually, B. the CP implementation MAY >>> allow the user to do something with the odID (such as storing it >>> with the flow); however C. if not specifically configured in this >>> way, the CP MUST NOT store the odID (much as it doesn't store the >>> tID now). >> >> >> Why would you store the OD ID with the flow data? > > > The only reason to do so is if you know 1. it was manually assigned and > 2. is stable (I'm thinking about a specific use case I have here). Then you're attributing a device-wide meaning to an exporter session specific ID. Or looked at another way, you're unnecessarily overloading the OD ID. > But, you're right; if we really need this, we have more than enough in the > way of information elements with _actual meaning_ to do the same thing. Agreed. If the OD ID can be attributed with some information, then put that info in the flow data. If it's duplicated for every flow, then use the techniques in the reducing-redundancy draft. > (Complete aside, it would be really nice to have a way to scope a value > to a message. Perhaps a zero-length IE whose presence as scope means > the option applies to the entire message?) I did recently ask whether a) it's valid to send a zero-length IE (though as data, not as scope) and b) what it means. Seems that it's valid, and probably means that the implimentation is broken ;-) >> Firstly, we just agreed that it's not going to tell you anything >> useful about the data. It only helps you figure out which templates >> (including options, ACK) to use to decode the data, and presumably >> you've already done that part. >> >> Secondly, the OD ID will be completely out of context. By your own >> arguments, it's only valid within the scope of an export session. >> Making it available outwith that session is just meaningless. >> >> If the OD ID only helps us to scope templates (including options) >> then that's *all* we must do with it. It mustn't be stored in or with >> the flow data *as if* it has some other meaning. > > > These are all excellent points, so I'm going to go ahead and declare > myself convinced. Strike caveat 2. :-) -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOwG-0005z0-Bn; Mon, 02 Oct 2006 10:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOwE-0005yv-SZ for ipfix@ietf.org; Mon, 02 Oct 2006 10:38:34 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOwD-0001wi-Fe for ipfix@ietf.org; Mon, 02 Oct 2006 10:38:34 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 655E91BAC4D; Mon, 2 Oct 2006 16:38:32 +0200 (CEST) Date: Mon, 02 Oct 2006 16:38:28 +0200 From: Juergen Quittek To: Paul Aitken , ipfix@ietf.org Subject: Re: [IPFIX] IPFIX fragmentIdentification Message-ID: <1D65F14886840B1D4488ED01@[10.1.1.104]> In-Reply-To: <4520E6E4.80701@cisco.com> References: <4520E6E4.80701@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Paul, --On 02.10.2006 11:16 Uhr +0100 Paul Aitken wrote: > IPFIX fragmentIdentification is defined as: > > The value of the Identification field in the IPv4 packet header or the > IPv6 Fragment header, respectively. The value is 0 for IPv6 if there > is no Fragment header. > > So the IPv4 ID and IPv6 fragmentation ID are combined in a single field. > > > RFC 791 shows the IPv4 Identification is 16 bits: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| IHL |Type of Service| Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |Flags| Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Whereas RFC 2460 shows the IPv6 ID is 32 bits: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Reserved | Fragment Offset |Res|M| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to extend the IPv4 ID to 32 bits. Or you use different templates for v4 and v6. This is anyway preferable if you include more header fields, and required if you include IP addresses. > Seems that it would be more correct to have two different IDs for these? I consider cases where you need them separate to be rare, but I do not have a problem with adding special IEs for v4 and v6. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOwG-0005z0-Bn; Mon, 02 Oct 2006 10:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOwE-0005yv-SZ for ipfix@ietf.org; Mon, 02 Oct 2006 10:38:34 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOwD-0001wi-Fe for ipfix@ietf.org; Mon, 02 Oct 2006 10:38:34 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 655E91BAC4D; Mon, 2 Oct 2006 16:38:32 +0200 (CEST) Date: Mon, 02 Oct 2006 16:38:28 +0200 From: Juergen Quittek To: Paul Aitken , ipfix@ietf.org Subject: Re: [IPFIX] IPFIX fragmentIdentification Message-ID: <1D65F14886840B1D4488ED01@[10.1.1.104]> In-Reply-To: <4520E6E4.80701@cisco.com> References: <4520E6E4.80701@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Paul, --On 02.10.2006 11:16 Uhr +0100 Paul Aitken wrote: > IPFIX fragmentIdentification is defined as: > > The value of the Identification field in the IPv4 packet header or the > IPv6 Fragment header, respectively. The value is 0 for IPv6 if there > is no Fragment header. > > So the IPv4 ID and IPv6 fragmentation ID are combined in a single field. > > > RFC 791 shows the IPv4 Identification is 16 bits: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| IHL |Type of Service| Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |Flags| Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Whereas RFC 2460 shows the IPv6 ID is 32 bits: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Reserved | Fragment Offset |Res|M| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to extend the IPv4 ID to 32 bits. Or you use different templates for v4 and v6. This is anyway preferable if you include more header fields, and required if you include IP addresses. > Seems that it would be more correct to have two different IDs for these? I consider cases where you need them separate to be rare, but I do not have a problem with adding special IEs for v4 and v6. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3u-0008Ur-32; Mon, 02 Oct 2006 10:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3t-0008TY-3h for ipfix@ietf.org; Mon, 02 Oct 2006 10:46:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP3q-0002Xp-SS for ipfix@ietf.org; Mon, 02 Oct 2006 10:46:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 10:46:27 -0400 X-IronPort-AV: i="4.09,245,1157342400"; d="scan'208"; a="105379630:sNHT49096012" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EkQY7029585; Mon, 2 Oct 2006 10:46:26 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92EkPg2013497; Mon, 2 Oct 2006 16:46:25 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA10333; Mon, 2 Oct 2006 15:46:23 +0100 (BST) Message-ID: <4521263E.4020006@cisco.com> Date: Mon, 02 Oct 2006 15:46:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] IPFIX fragmentIdentification References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]> In-Reply-To: <1D65F14886840B1D4488ED01@[10.1.1.104]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=846; t=1159800386; x=1160664386; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20IPFIX=20fragmentIdentification |To:Juergen=20Quittek=20; X=v=3Dcisco.com=3B=20h=3D2waevV8sg0N5qR1ADrkT7ag3wmI=3D; b=Hq9efqjzeevKg2rD3rizocE12mEVtJOmBHLXwpVQQOm5UlBeA/wQPNGubioQlKEGl5MHteTp 5Nh6eqHqpJQRF6ESw5IV7buqUaws8/JcJ1aw6e9lNDL/VHlMr9o4FgzC; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen, >> So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to >> extend the IPv4 ID to 32 bits. > > Or you use different templates for v4 and v6. This is anyway preferable > if you include more header fields, and required if you include IP > addresses. Suppose you don't know (and don't especially care) whether it's IPv4 or IPv6 traffic? For some reason you're just monitoring the IDs. >> Seems that it would be more correct to have two different IDs for these? > > I consider cases where you need them separate to be rare, but I do not > have a problem with adding special IEs for v4 and v6. I think I would prefer to go back to #54 = IPv4 ID (coming from the netflow v9 definition) and create a new fragmentIdentificationIPv6 IE. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 10:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3u-0008Ur-32; Mon, 02 Oct 2006 10:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3t-0008TY-3h for ipfix@ietf.org; Mon, 02 Oct 2006 10:46:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP3q-0002Xp-SS for ipfix@ietf.org; Mon, 02 Oct 2006 10:46:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 10:46:27 -0400 X-IronPort-AV: i="4.09,245,1157342400"; d="scan'208"; a="105379630:sNHT49096012" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EkQY7029585; Mon, 2 Oct 2006 10:46:26 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92EkPg2013497; Mon, 2 Oct 2006 16:46:25 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA10333; Mon, 2 Oct 2006 15:46:23 +0100 (BST) Message-ID: <4521263E.4020006@cisco.com> Date: Mon, 02 Oct 2006 15:46:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] IPFIX fragmentIdentification References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]> In-Reply-To: <1D65F14886840B1D4488ED01@[10.1.1.104]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=846; t=1159800386; x=1160664386; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20IPFIX=20fragmentIdentification |To:Juergen=20Quittek=20; X=v=3Dcisco.com=3B=20h=3D2waevV8sg0N5qR1ADrkT7ag3wmI=3D; b=Hq9efqjzeevKg2rD3rizocE12mEVtJOmBHLXwpVQQOm5UlBeA/wQPNGubioQlKEGl5MHteTp 5Nh6eqHqpJQRF6ESw5IV7buqUaws8/JcJ1aw6e9lNDL/VHlMr9o4FgzC; Authentication-Results: rtp-dkim-2.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen, >> So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to >> extend the IPv4 ID to 32 bits. > > Or you use different templates for v4 and v6. This is anyway preferable > if you include more header fields, and required if you include IP > addresses. Suppose you don't know (and don't especially care) whether it's IPv4 or IPv6 traffic? For some reason you're just monitoring the IDs. >> Seems that it would be more correct to have two different IDs for these? > > I consider cases where you need them separate to be rare, but I do not > have a problem with adding special IEs for v4 and v6. I think I would prefer to go back to #54 = IPv4 ID (coming from the netflow v9 definition) and create a new fragmentIdentificationIPv6 IE. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 11:40:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPt3-0004F7-G0; Mon, 02 Oct 2006 11:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPt2-0004Cn-Tk for ipfix@ietf.org; Mon, 02 Oct 2006 11:39:20 -0400 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPt1-0001W7-Mc for ipfix@ietf.org; Mon, 02 Oct 2006 11:39:20 -0400 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92FdFtL002220 for ; Mon, 2 Oct 2006 11:39:15 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92Fcnbx002185 for ; Mon, 2 Oct 2006 11:38:49 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92FcnHX002183; Mon, 02 Oct 2006 11:38:49 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-13.remote.cert.org [10.25.4.13]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92FcnsK024861; Mon, 2 Oct 2006 11:38:49 -0400 In-Reply-To: <45211F6F.7030105@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> <45211F6F.7030105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: zero-length information elements (was: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions) Date: Mon, 2 Oct 2006 11:37:58 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 2, 2006, at 10:17 AM, Paul Aitken wrote: >> (Complete aside, it would be really nice to have a way to scope a >> value to a message. Perhaps a zero-length IE whose presence as >> scope means the option applies to the entire message?) > > I did recently ask whether a) it's valid to send a zero-length IE > (though as data, not as scope) and b) what it means. > > Seems that it's valid, and probably means that the implimentation > is broken ;-) Indeed, there is no restriction on (or mention of) this in the protocol or the implementation guidelines. There should at least be a mention, I think, to avoid confusion. The two most reasonable possibilities (at least from the limited point of view of the use cases I have for them :) ) seem to be: 1. allow zero-length IEs to be used as scope only; the meaning of the scope would be part of the IE definition; note that I can at the moment think of only two meaningful scopes, message and session. 2. forbid zero-length IEs at all; message and session scope could then be implemented using special IEs whose content would be ignored. Thoughts? - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 11:40:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPt3-0004F7-G0; Mon, 02 Oct 2006 11:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPt2-0004Cn-Tk for ipfix@ietf.org; Mon, 02 Oct 2006 11:39:20 -0400 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPt1-0001W7-Mc for ipfix@ietf.org; Mon, 02 Oct 2006 11:39:20 -0400 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k92FdFtL002220 for ; Mon, 2 Oct 2006 11:39:15 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k92Fcnbx002185 for ; Mon, 2 Oct 2006 11:38:49 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k92FcnHX002183; Mon, 02 Oct 2006 11:38:49 -0400 (EDT) Received: from [128.237.235.210] (vpn-10-25-4-13.remote.cert.org [10.25.4.13]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k92FcnsK024861; Mon, 2 Oct 2006 11:38:49 -0400 In-Reply-To: <45211F6F.7030105@cisco.com> References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> <45211F6F.7030105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: zero-length information elements (was: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions) Date: Mon, 2 Oct 2006 11:37:58 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 2, 2006, at 10:17 AM, Paul Aitken wrote: >> (Complete aside, it would be really nice to have a way to scope a >> value to a message. Perhaps a zero-length IE whose presence as >> scope means the option applies to the entire message?) > > I did recently ask whether a) it's valid to send a zero-length IE > (though as data, not as scope) and b) what it means. > > Seems that it's valid, and probably means that the implimentation > is broken ;-) Indeed, there is no restriction on (or mention of) this in the protocol or the implementation guidelines. There should at least be a mention, I think, to avoid confusion. The two most reasonable possibilities (at least from the limited point of view of the use cases I have for them :) ) seem to be: 1. allow zero-length IEs to be used as scope only; the meaning of the scope would be part of the IE definition; note that I can at the moment think of only two meaningful scopes, message and session. 2. forbid zero-length IEs at all; message and session scope could then be implemented using special IEs whose content would be ignored. Thoughts? - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 12:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzw-0006Yg-Ub; Mon, 02 Oct 2006 12:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzw-0006YY-2N for ipfix@ietf.org; Mon, 02 Oct 2006 12:50:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQzt-0005Un-Jx for ipfix@ietf.org; Mon, 02 Oct 2006 12:50:32 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 09:50:29 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44516567:sNHT52789060" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92GoSVg012952; Mon, 2 Oct 2006 12:50:29 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92GoSg2018693; Mon, 2 Oct 2006 18:50:28 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA23804; Mon, 2 Oct 2006 17:50:26 +0100 (BST) Message-ID: <45214352.9010406@cisco.com> Date: Mon, 02 Oct 2006 17:50:26 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> <45211F6F.7030105@cisco.com> <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> In-Reply-To: <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1875; t=1159807829; x=1160671829; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20zero-length=20information=20elements |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DvnM0/Nq31ttutUniV2TC+lVilic=3D; b=E+v4Q1HjlRpohePStoF0JrmvffbwlUFnZ+irADA0kSbDbFb1VGCsphvmKdRfFgSUF7bWZg4C pteKCgdj3l3Qc1umU+i1Onlhk8kMeUwp0Ui3wckAQRJw3SuKFBRYKzk9; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipfix@ietf.org Subject: [IPFIX] Re: zero-length information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >>> (Complete aside, it would be really nice to have a way to scope a >>> value to a message. Perhaps a zero-length IE whose presence as >>> scope means the option applies to the entire message?) >> >> >> I did recently ask whether a) it's valid to send a zero-length IE >> (though as data, not as scope) and b) what it means. >> >> Seems that it's valid, and probably means that the implimentation is >> broken ;-) > > > Indeed, there is no restriction on (or mention of) this in the protocol > or the implementation guidelines. There should at least be a mention, I > think, to avoid confusion. > > The two most reasonable possibilities (at least from the limited point > of view of the use cases I have for them :) ) seem to be: > > 1. allow zero-length IEs to be used as scope only; the meaning of the > scope would be part of the IE definition; note that I can at the moment > think of only two meaningful scopes, message and session. If you want scope then you should be using options. Or more generally (as has been suggested before) we should have defined data and options templates to be one and the same thing, with the possibility of scope length = 0. > 2. forbid zero-length IEs at all; message and session scope could then > be implemented using special IEs whose content would be ignored. I don't see any reason to forbid zero-length IEs. Granted, they're unusual and not particularly useful - but there's nothing actually wrong with sending them. Hopefully collectors are robust enough to deal with them! If you want to embed scope info into data records, then let's do it properly with new IEs designed for the purpose. Or design a new data set with a different header. But let's not mandate tricksy solutions! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 02 12:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzw-0006Yg-Ub; Mon, 02 Oct 2006 12:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzw-0006YY-2N for ipfix@ietf.org; Mon, 02 Oct 2006 12:50:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQzt-0005Un-Jx for ipfix@ietf.org; Mon, 02 Oct 2006 12:50:32 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 09:50:29 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44516567:sNHT52789060" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92GoSVg012952; Mon, 2 Oct 2006 12:50:29 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92GoSg2018693; Mon, 2 Oct 2006 18:50:28 +0200 (MEST) Received: from [10.82.224.112] (rtp-vpn1-112.cisco.com [10.82.224.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA23804; Mon, 2 Oct 2006 17:50:26 +0100 (BST) Message-ID: <45214352.9010406@cisco.com> Date: Mon, 02 Oct 2006 17:50:26 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> <451FE90C.7080803@cisco.com> <7ADBFA31-0143-4658-9DDB-64F2EF8149A4@cert.org> <452117AA.1010402@cisco.com> <6F81A7AB-00E4-4301-B4C2-83C5B5B7BA8B@cert.org> <45211F6F.7030105@cisco.com> <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> In-Reply-To: <8D6ED326-3032-4272-B2D4-C1D69EC838FE@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1875; t=1159807829; x=1160671829; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20zero-length=20information=20elements |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DvnM0/Nq31ttutUniV2TC+lVilic=3D; b=E+v4Q1HjlRpohePStoF0JrmvffbwlUFnZ+irADA0kSbDbFb1VGCsphvmKdRfFgSUF7bWZg4C pteKCgdj3l3Qc1umU+i1Onlhk8kMeUwp0Ui3wckAQRJw3SuKFBRYKzk9; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipfix@ietf.org Subject: [IPFIX] Re: zero-length information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, >>> (Complete aside, it would be really nice to have a way to scope a >>> value to a message. Perhaps a zero-length IE whose presence as >>> scope means the option applies to the entire message?) >> >> >> I did recently ask whether a) it's valid to send a zero-length IE >> (though as data, not as scope) and b) what it means. >> >> Seems that it's valid, and probably means that the implimentation is >> broken ;-) > > > Indeed, there is no restriction on (or mention of) this in the protocol > or the implementation guidelines. There should at least be a mention, I > think, to avoid confusion. > > The two most reasonable possibilities (at least from the limited point > of view of the use cases I have for them :) ) seem to be: > > 1. allow zero-length IEs to be used as scope only; the meaning of the > scope would be part of the IE definition; note that I can at the moment > think of only two meaningful scopes, message and session. If you want scope then you should be using options. Or more generally (as has been suggested before) we should have defined data and options templates to be one and the same thing, with the possibility of scope length = 0. > 2. forbid zero-length IEs at all; message and session scope could then > be implemented using special IEs whose content would be ignored. I don't see any reason to forbid zero-length IEs. Granted, they're unusual and not particularly useful - but there's nothing actually wrong with sending them. Hopefully collectors are robust enough to deal with them! If you want to embed scope info into data records, then let's do it properly with new IEs designed for the purpose. Or design a new data set with a different header. But let's not mandate tricksy solutions! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Oct 03 06:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTE-00011B-BV; Tue, 03 Oct 2006 06:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTD-00010J-04 for ipfix@ietf.org; Tue, 03 Oct 2006 06:25:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhSY-0005Af-5O for ipfix@ietf.org; Tue, 03 Oct 2006 06:25:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Oct 2006 06:25:10 -0400 X-IronPort-AV: i="4.09,248,1157342400"; d="scan'208"; a="105489305:sNHT55607324" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93AP99P029403; Tue, 3 Oct 2006 06:25:09 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k93AP9g2026061; Tue, 3 Oct 2006 12:25:09 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA09324; Tue, 3 Oct 2006 11:25:08 +0100 (BST) Message-ID: <45223A84.9070808@cisco.com> Date: Tue, 03 Oct 2006 11:25:08 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> In-Reply-To: <451FDEF8.8090306@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3931; t=1159871110; x=1160735110; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Gerhard=20Muenz=20; X=v=3Dcisco.com=3B=20h=3D5AcsNG26RxVP2wgYs1OQCcZy/eo=3D; b=rJnqBZM/0KO8QCTLY2aGbABE0l2xEuhmdDGZTR5NxWHyhZGE0LlfxPw3kZ1RYMCbV3dgfoRp Mddi5bfL93pNenkOK4hRydgDjvBusHY1UQm0hYgpvCicb1dvdgdhVBrs; Authentication-Results: rtp-dkim-1.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi reply inline. Gerhard Muenz wrote: > Dear all, > > So we are back to the same problem again concerning the double function > of OD ID as stated in: > http://www1.ietf.org/mail-archive/web/ipfix/current/msg03400.html > > Last time, if I remember correctly, we more or less agreed on what is > written in the current draft version in order to avoid bigger changes. > > Some remarks about the current discussion: > > Andrew Johnson wrote: >> IPFIX INFO rev 12 the OD IDs were considered unique per Exporting >> Process. That means that each Exporting Process could export >> using it's own set of Observation Domain IDs and that the number >> space is not common between them. >> >> Now we don't use the OD ID as an Exporting Process Identifier. > > We could actually use the Exporting Process ID in the IPFIX header > instead, but than we have to assigne unique exporter IDs on a device. Unique Exporting Process IDs are not really expected to be difficult to assign as every process gets a unique ID from the OS. However everyone would have to agree to use that as the ID. >> In short, it is agreed that the EP of a connection cannot be >> identified with the mandatory information. So Brain and I are >> suggesting that the OD ID is considered unique per connection >> session. > > Then we should call it session ID. Each session could use several OD IDs. The collector can differentiate between sessions already, what it can't do is tell which session belongs to which Exporting Process. So a session restart means that all the IDs that are considered unique per Exporting Process become confusable. >> The alternative is to scope the Observation Domain ID to be >> entire IPFIX device. This means that different Exporting >> Processes will have to negotiate (or be configured) to use the >> Observation Domains correctly. Furthermore, since template IDs >> and other IEs are scoped to the OD ID, then if you wanted two >> Exporters to report on the same Observation Domain (with the >> same ID) then you would have to negotiate (or configure) use >> of Template IDs, flow IDs, common properties IDs, ... > > This is maybe a stupid question: Can't we distinguish different > Exporting Processes on a single device based on the source port number? No, this is the main problem. The port numbers tell us that these are different sessions. If we have two Exporting Processes using ports 1000 and 2000 and we have a link failure, when the sessions are re-established using ports 3000 and 4000, we can't tell how these map to the old port numbers. [SNIP] >> It has been said that you need to know what Observation Domain >> a flow was observed in order to aggregate the information >> together. In the above case a single flow that has been load >> balanced across interfaces on LCs 1 and 2 will generate two >> flow records from different Observation Domains. Can you >> aggregate? Of course you can! > > I assume that the administrator has to know the configuration of the > monitoring device in this case. I think that we can suppose that this > context information is available to him. My point is that different vendors will use the OD to mean different things. The administrator will hopefully know how, but at the moment we can't have generic rules about how to interpret the OD ID as it has no real meaning. regards Andrew >> What is important is getting the right set of flow keys. In >> this case the index of the output interface is important to >> the user, so that must be included in the flow. >> >> If the Line Card that the flow was observed on is important >> then put it in the flow (element 141). > > Agreed. > > Regards, > Gerhard > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Oct 03 06:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTE-00011B-BV; Tue, 03 Oct 2006 06:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTD-00010J-04 for ipfix@ietf.org; Tue, 03 Oct 2006 06:25:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhSY-0005Af-5O for ipfix@ietf.org; Tue, 03 Oct 2006 06:25:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Oct 2006 06:25:10 -0400 X-IronPort-AV: i="4.09,248,1157342400"; d="scan'208"; a="105489305:sNHT55607324" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93AP99P029403; Tue, 3 Oct 2006 06:25:09 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k93AP9g2026061; Tue, 3 Oct 2006 12:25:09 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA09324; Tue, 3 Oct 2006 11:25:08 +0100 (BST) Message-ID: <45223A84.9070808@cisco.com> Date: Tue, 03 Oct 2006 11:25:08 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> <451FDEF8.8090306@informatik.uni-tuebingen.de> In-Reply-To: <451FDEF8.8090306@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3931; t=1159871110; x=1160735110; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Re=3A=20[ipfix-protocol]=20IPFIX-INFO=20last=20call=20 comment=3A=09Observation=0A=20Domains,=20Templates,=20and=20Sessions |To:Gerhard=20Muenz=20; X=v=3Dcisco.com=3B=20h=3D5AcsNG26RxVP2wgYs1OQCcZy/eo=3D; b=rJnqBZM/0KO8QCTLY2aGbABE0l2xEuhmdDGZTR5NxWHyhZGE0LlfxPw3kZ1RYMCbV3dgfoRp Mddi5bfL93pNenkOK4hRydgDjvBusHY1UQm0hYgpvCicb1dvdgdhVBrs; Authentication-Results: rtp-dkim-1.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi reply inline. Gerhard Muenz wrote: > Dear all, > > So we are back to the same problem again concerning the double function > of OD ID as stated in: > http://www1.ietf.org/mail-archive/web/ipfix/current/msg03400.html > > Last time, if I remember correctly, we more or less agreed on what is > written in the current draft version in order to avoid bigger changes. > > Some remarks about the current discussion: > > Andrew Johnson wrote: >> IPFIX INFO rev 12 the OD IDs were considered unique per Exporting >> Process. That means that each Exporting Process could export >> using it's own set of Observation Domain IDs and that the number >> space is not common between them. >> >> Now we don't use the OD ID as an Exporting Process Identifier. > > We could actually use the Exporting Process ID in the IPFIX header > instead, but than we have to assigne unique exporter IDs on a device. Unique Exporting Process IDs are not really expected to be difficult to assign as every process gets a unique ID from the OS. However everyone would have to agree to use that as the ID. >> In short, it is agreed that the EP of a connection cannot be >> identified with the mandatory information. So Brain and I are >> suggesting that the OD ID is considered unique per connection >> session. > > Then we should call it session ID. Each session could use several OD IDs. The collector can differentiate between sessions already, what it can't do is tell which session belongs to which Exporting Process. So a session restart means that all the IDs that are considered unique per Exporting Process become confusable. >> The alternative is to scope the Observation Domain ID to be >> entire IPFIX device. This means that different Exporting >> Processes will have to negotiate (or be configured) to use the >> Observation Domains correctly. Furthermore, since template IDs >> and other IEs are scoped to the OD ID, then if you wanted two >> Exporters to report on the same Observation Domain (with the >> same ID) then you would have to negotiate (or configure) use >> of Template IDs, flow IDs, common properties IDs, ... > > This is maybe a stupid question: Can't we distinguish different > Exporting Processes on a single device based on the source port number? No, this is the main problem. The port numbers tell us that these are different sessions. If we have two Exporting Processes using ports 1000 and 2000 and we have a link failure, when the sessions are re-established using ports 3000 and 4000, we can't tell how these map to the old port numbers. [SNIP] >> It has been said that you need to know what Observation Domain >> a flow was observed in order to aggregate the information >> together. In the above case a single flow that has been load >> balanced across interfaces on LCs 1 and 2 will generate two >> flow records from different Observation Domains. Can you >> aggregate? Of course you can! > > I assume that the administrator has to know the configuration of the > monitoring device in this case. I think that we can suppose that this > context information is available to him. My point is that different vendors will use the OD to mean different things. The administrator will hopefully know how, but at the moment we can't have generic rules about how to interpret the OD ID as it has no real meaning. regards Andrew >> What is important is getting the right set of flow keys. In >> this case the index of the output interface is important to >> the user, so that must be included in the flow. >> >> If the Line Card that the flow was observed on is important >> then put it in the flow (element 141). > > Agreed. > > Regards, > Gerhard > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 03:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0sd-0006Zp-BU; Wed, 04 Oct 2006 03:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0sc-0006Zk-Fa for ipfix@ietf.org; Wed, 04 Oct 2006 03:09:22 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0sa-0005NG-Cr for ipfix@ietf.org; Wed, 04 Oct 2006 03:09:22 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Icq001076 for ; Wed, 4 Oct 2006 16:09:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479IbP000987 for ; Wed, 4 Oct 2006 16:09:18 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479H51024658 for ; Wed, 4 Oct 2006 16:09:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479HZ0007094 for ; Wed, 4 Oct 2006 16:09:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Gju013670 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479GWP013667 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Gdg021837 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Message-ID: <45235E1D.5000100@lab.ntt.co.jp> Date: Wed, 04 Oct 2006 16:09:17 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [IPFIX] when flow{Start,End}SysUpTime overflow X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, I have a question about flow{Start,End}SysUpTime IEs. flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, and 47 seconds since (re-)initialization of IPFIX device, because abstract data type of flow{Start,End}SysUpTime is unsigned32. When exporter (ex. router) runs over 50 days, how can these IE represent time stamp? If these counter reset to 0 when these counter overflow, there is a possibility that the collector confuses information of the 1st day and information of 50th day. If exporter can update systemInitTimeMilliseconds arbitrarily, it can avoid this problem. But, systemInitTimeMilliseconds represent "The absolute timestamp of the last (re-)initialization of the IFPIX Device", therefore it seems that it is bad thing to update systemInitTimeMilliseconds arbitrarily. How should exporter export for a long time (over 50 days) that uses flow{Start,End}SysUpTime? -- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 03:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0sd-0006Zp-BU; Wed, 04 Oct 2006 03:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0sc-0006Zk-Fa for ipfix@ietf.org; Wed, 04 Oct 2006 03:09:22 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0sa-0005NG-Cr for ipfix@ietf.org; Wed, 04 Oct 2006 03:09:22 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Icq001076 for ; Wed, 4 Oct 2006 16:09:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479IbP000987 for ; Wed, 4 Oct 2006 16:09:18 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479H51024658 for ; Wed, 4 Oct 2006 16:09:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479HZ0007094 for ; Wed, 4 Oct 2006 16:09:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Gju013670 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479GWP013667 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9479Gdg021837 for ; Wed, 4 Oct 2006 16:09:16 +0900 (JST) Message-ID: <45235E1D.5000100@lab.ntt.co.jp> Date: Wed, 04 Oct 2006 16:09:17 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [IPFIX] when flow{Start,End}SysUpTime overflow X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, I have a question about flow{Start,End}SysUpTime IEs. flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, and 47 seconds since (re-)initialization of IPFIX device, because abstract data type of flow{Start,End}SysUpTime is unsigned32. When exporter (ex. router) runs over 50 days, how can these IE represent time stamp? If these counter reset to 0 when these counter overflow, there is a possibility that the collector confuses information of the 1st day and information of 50th day. If exporter can update systemInitTimeMilliseconds arbitrarily, it can avoid this problem. But, systemInitTimeMilliseconds represent "The absolute timestamp of the last (re-)initialization of the IFPIX Device", therefore it seems that it is bad thing to update systemInitTimeMilliseconds arbitrarily. How should exporter export for a long time (over 50 days) that uses flow{Start,End}SysUpTime? -- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 09:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Aq-0006Qr-G3; Wed, 04 Oct 2006 09:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Ap-0006Ql-4W for ipfix@ietf.org; Wed, 04 Oct 2006 09:52:35 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7An-0002Fr-SQ for ipfix@ietf.org; Wed, 04 Oct 2006 09:52:35 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k94DqNdU005478 for ; Wed, 4 Oct 2006 09:52:29 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k94DpT2X005396 for ; Wed, 4 Oct 2006 09:51:29 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k94DpTpb005394; Wed, 04 Oct 2006 09:51:29 -0400 (EDT) Received: from [128.237.241.27] (vpn-10-25-4-16.remote.cert.org [10.25.4.16]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k94DpTGl031235; Wed, 4 Oct 2006 09:51:29 -0400 In-Reply-To: <45235E1D.5000100@lab.ntt.co.jp> References: <45235E1D.5000100@lab.ntt.co.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow Date: Wed, 4 Oct 2006 09:50:56 -0400 To: Hitoshi Irino X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 4, 2006, at 3:09 AM, Hitoshi Irino wrote: > Dear all, > > I have a question about flow{Start,End}SysUpTime IEs. > > flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, > and > 47 seconds since (re-)initialization of IPFIX device, because > abstract > data type of flow{Start,End}SysUpTime is unsigned32. > When exporter (ex. router) runs over 50 days, how can these IE > represent > time stamp? > > If these counter reset to 0 when these counter overflow, there is a > possibility that the collector confuses information of the 1st day and > information of 50th day. > > If exporter can update systemInitTimeMilliseconds arbitrarily, it can > avoid this problem. But, systemInitTimeMilliseconds represent "The > absolute timestamp of the last (re-)initialization of the IFPIX > Device", > therefore it seems that it is bad thing to update > systemInitTimeMilliseconds arbitrarily. Agreed. > How should exporter export for a long time (over 50 days) that uses > flow{Start,End}SysUpTime? It seems the solution to this one is the same we've had on other "overflowable" counter IEs - simply define it in the Information Model to be an unsigned64, then use reduced length encoding in the case of shorter than 50 day uptimes. Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be used to express flow times as negative offsets from the message export time, and have the dual advantages of 1. being 32 bit counters and 2. having greater precision; however, the overhead to calculate them (as the message export time may not be known until _after_ the MP generates the records) may be measurably higher than that for SysUpTime, so this may not solve your problem. In any case, I'd recommend to the WG that the SysUpTime IEs be redefined as 64 bits. Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 09:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Aq-0006Qr-G3; Wed, 04 Oct 2006 09:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Ap-0006Ql-4W for ipfix@ietf.org; Wed, 04 Oct 2006 09:52:35 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7An-0002Fr-SQ for ipfix@ietf.org; Wed, 04 Oct 2006 09:52:35 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k94DqNdU005478 for ; Wed, 4 Oct 2006 09:52:29 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k94DpT2X005396 for ; Wed, 4 Oct 2006 09:51:29 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k94DpTpb005394; Wed, 04 Oct 2006 09:51:29 -0400 (EDT) Received: from [128.237.241.27] (vpn-10-25-4-16.remote.cert.org [10.25.4.16]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k94DpTGl031235; Wed, 4 Oct 2006 09:51:29 -0400 In-Reply-To: <45235E1D.5000100@lab.ntt.co.jp> References: <45235E1D.5000100@lab.ntt.co.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow Date: Wed, 4 Oct 2006 09:50:56 -0400 To: Hitoshi Irino X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Oct 4, 2006, at 3:09 AM, Hitoshi Irino wrote: > Dear all, > > I have a question about flow{Start,End}SysUpTime IEs. > > flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, > and > 47 seconds since (re-)initialization of IPFIX device, because > abstract > data type of flow{Start,End}SysUpTime is unsigned32. > When exporter (ex. router) runs over 50 days, how can these IE > represent > time stamp? > > If these counter reset to 0 when these counter overflow, there is a > possibility that the collector confuses information of the 1st day and > information of 50th day. > > If exporter can update systemInitTimeMilliseconds arbitrarily, it can > avoid this problem. But, systemInitTimeMilliseconds represent "The > absolute timestamp of the last (re-)initialization of the IFPIX > Device", > therefore it seems that it is bad thing to update > systemInitTimeMilliseconds arbitrarily. Agreed. > How should exporter export for a long time (over 50 days) that uses > flow{Start,End}SysUpTime? It seems the solution to this one is the same we've had on other "overflowable" counter IEs - simply define it in the Information Model to be an unsigned64, then use reduced length encoding in the case of shorter than 50 day uptimes. Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be used to express flow times as negative offsets from the message export time, and have the dual advantages of 1. being 32 bit counters and 2. having greater precision; however, the overhead to calculate them (as the message export time may not be known until _after_ the MP generates the records) may be measurably higher than that for SysUpTime, so this may not solve your problem. In any case, I'd recommend to the WG that the SysUpTime IEs be redefined as 64 bits. Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 10:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7zq-0007sF-CY; Wed, 04 Oct 2006 10:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7zp-0007qr-Sy for ipfix@ietf.org; Wed, 04 Oct 2006 10:45:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7zo-0004LU-Lo for ipfix@ietf.org; Wed, 04 Oct 2006 10:45:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 07:45:13 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44805747:sNHT50365876" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94EjAGa005940; Wed, 4 Oct 2006 10:45:11 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k94EjAg2026923; Wed, 4 Oct 2006 16:45:10 +0200 (MEST) Received: from [10.61.65.154] (ams3-vpn-dhcp410.cisco.com [10.61.65.154]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01056; Wed, 4 Oct 2006 15:45:08 +0100 (BST) Message-ID: <4523C8F5.6000703@cisco.com> Date: Wed, 04 Oct 2006 15:45:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> In-Reply-To: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=732; t=1159973111; x=1160837111; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D; b=f4VBXu32q+1alfmmVeQyiPdxUFYgBVaSnjWGg09XtrTq5BF8YEf0FSTzeam3+Or8IJ7VWPPq E/Y2b1R6CWzlGYAW3Eo+130DFdaJVfl3VxedYDO6MASaO+fKXtb8EUrO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > however, the overhead to calculate them (as the message export time > may not be known until _after_ the MP generates the records) may be > measurably higher The export time is defined as Time in seconds since 0000 UTC Jan 1st 1970, at which the IPFIX Message Header leaves the Exporter. So presumably the EP would have to calculate a pseudo export time, recalculate any delta times relative to the pseudo export time, and then either check whether the pseudo export time was still the current time (ie, clock has not ticked to the next second) or wait for the pseudo export time to occur (if it was deliberately in advance). -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 10:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7zq-0007sF-CY; Wed, 04 Oct 2006 10:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7zp-0007qr-Sy for ipfix@ietf.org; Wed, 04 Oct 2006 10:45:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7zo-0004LU-Lo for ipfix@ietf.org; Wed, 04 Oct 2006 10:45:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 07:45:13 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44805747:sNHT50365876" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94EjAGa005940; Wed, 4 Oct 2006 10:45:11 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k94EjAg2026923; Wed, 4 Oct 2006 16:45:10 +0200 (MEST) Received: from [10.61.65.154] (ams3-vpn-dhcp410.cisco.com [10.61.65.154]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01056; Wed, 4 Oct 2006 15:45:08 +0100 (BST) Message-ID: <4523C8F5.6000703@cisco.com> Date: Wed, 04 Oct 2006 15:45:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> In-Reply-To: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=732; t=1159973111; x=1160837111; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow |To:Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D; b=f4VBXu32q+1alfmmVeQyiPdxUFYgBVaSnjWGg09XtrTq5BF8YEf0FSTzeam3+Or8IJ7VWPPq E/Y2b1R6CWzlGYAW3Eo+130DFdaJVfl3VxedYDO6MASaO+fKXtb8EUrO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > however, the overhead to calculate them (as the message export time > may not be known until _after_ the MP generates the records) may be > measurably higher The export time is defined as Time in seconds since 0000 UTC Jan 1st 1970, at which the IPFIX Message Header leaves the Exporter. So presumably the EP would have to calculate a pseudo export time, recalculate any delta times relative to the pseudo export time, and then either check whether the pseudo export time was still the current time (ie, clock has not ticked to the next second) or wait for the pseudo export time to occur (if it was deliberately in advance). -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 23:53:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKGu-0000Fv-VB; Wed, 04 Oct 2006 23:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKGu-0000Fq-2H for ipfix@ietf.org; Wed, 04 Oct 2006 23:51:44 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVKGs-0000Co-2g for ipfix@ietf.org; Wed, 04 Oct 2006 23:51:44 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953pAOc029684; Thu, 5 Oct 2006 12:51:10 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p9tg016302; Thu, 5 Oct 2006 12:51:09 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8fL000478; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8TN023332; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8mx025594; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p7vx025589; Thu, 5 Oct 2006 12:51:07 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p7ZZ015256; Thu, 5 Oct 2006 12:51:07 +0900 (JST) Message-ID: <4524812B.2010900@lab.ntt.co.jp> Date: Thu, 05 Oct 2006 12:51:07 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> In-Reply-To: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Brian, Brian Trammell wrote: > On Oct 4, 2006, at 3:09 AM, Hitoshi Irino wrote: > >> Dear all, >> >> I have a question about flow{Start,End}SysUpTime IEs. >> >> flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, and >> 47 seconds since (re-)initialization of IPFIX device, because abstract >> data type of flow{Start,End}SysUpTime is unsigned32. >> When exporter (ex. router) runs over 50 days, how can these IE represent >> time stamp? >> >> If these counter reset to 0 when these counter overflow, there is a >> possibility that the collector confuses information of the 1st day and >> information of 50th day. >> >> If exporter can update systemInitTimeMilliseconds arbitrarily, it can >> avoid this problem. But, systemInitTimeMilliseconds represent "The >> absolute timestamp of the last (re-)initialization of the IFPIX Device", >> therefore it seems that it is bad thing to update >> systemInitTimeMilliseconds arbitrarily. > > Agreed. > >> How should exporter export for a long time (over 50 days) that uses >> flow{Start,End}SysUpTime? > > It seems the solution to this one is the same we've had on other > "overflowable" counter IEs - simply define it in the Information Model > to be an unsigned64, then use reduced length encoding in the case of > shorter than 50 day uptimes. > > Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be used > to express flow times as negative offsets from the message export time, > and have the dual advantages of 1. being 32 bit counters and 2. having > greater precision; however, the overhead to calculate them (as the > message export time may not be known until _after_ the MP generates the > records) may be measurably higher than that for SysUpTime, so this may > not solve your problem. > > In any case, I'd recommend to the WG that the SysUpTime IEs be redefined > as 64 bits. Thank you for your suggestion, I also agree to extend data type of SysUpTime IEs to unsigned64. -- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino Email: irino.hitoshi@lab.ntt.co.jp Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Oct 04 23:53:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKGu-0000Fv-VB; Wed, 04 Oct 2006 23:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKGu-0000Fq-2H for ipfix@ietf.org; Wed, 04 Oct 2006 23:51:44 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVKGs-0000Co-2g for ipfix@ietf.org; Wed, 04 Oct 2006 23:51:44 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953pAOc029684; Thu, 5 Oct 2006 12:51:10 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p9tg016302; Thu, 5 Oct 2006 12:51:09 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8fL000478; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8TN023332; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p8mx025594; Thu, 5 Oct 2006 12:51:08 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p7vx025589; Thu, 5 Oct 2006 12:51:07 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k953p7ZZ015256; Thu, 5 Oct 2006 12:51:07 +0900 (JST) Message-ID: <4524812B.2010900@lab.ntt.co.jp> Date: Thu, 05 Oct 2006 12:51:07 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> In-Reply-To: <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Brian, Brian Trammell wrote: > On Oct 4, 2006, at 3:09 AM, Hitoshi Irino wrote: > >> Dear all, >> >> I have a question about flow{Start,End}SysUpTime IEs. >> >> flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, and >> 47 seconds since (re-)initialization of IPFIX device, because abstract >> data type of flow{Start,End}SysUpTime is unsigned32. >> When exporter (ex. router) runs over 50 days, how can these IE represent >> time stamp? >> >> If these counter reset to 0 when these counter overflow, there is a >> possibility that the collector confuses information of the 1st day and >> information of 50th day. >> >> If exporter can update systemInitTimeMilliseconds arbitrarily, it can >> avoid this problem. But, systemInitTimeMilliseconds represent "The >> absolute timestamp of the last (re-)initialization of the IFPIX Device", >> therefore it seems that it is bad thing to update >> systemInitTimeMilliseconds arbitrarily. > > Agreed. > >> How should exporter export for a long time (over 50 days) that uses >> flow{Start,End}SysUpTime? > > It seems the solution to this one is the same we've had on other > "overflowable" counter IEs - simply define it in the Information Model > to be an unsigned64, then use reduced length encoding in the case of > shorter than 50 day uptimes. > > Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be used > to express flow times as negative offsets from the message export time, > and have the dual advantages of 1. being 32 bit counters and 2. having > greater precision; however, the overhead to calculate them (as the > message export time may not be known until _after_ the MP generates the > records) may be measurably higher than that for SysUpTime, so this may > not solve your problem. > > In any case, I'd recommend to the WG that the SysUpTime IEs be redefined > as 64 bits. Thank you for your suggestion, I also agree to extend data type of SysUpTime IEs to unsigned64. -- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino Email: irino.hitoshi@lab.ntt.co.jp Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 08:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSXO-0000zp-Tu; Thu, 05 Oct 2006 08:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSXN-0000yN-Nh for ipfix@ietf.org; Thu, 05 Oct 2006 08:41:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSXM-0003wT-GF for ipfix@ietf.org; Thu, 05 Oct 2006 08:41:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 08:41:16 -0400 X-IronPort-AV: i="4.09,263,1157342400"; d="scan'208"; a="105817509:sNHT54834876" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95CfF7v018761; Thu, 5 Oct 2006 08:41:16 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95CfDmd000744; Thu, 5 Oct 2006 14:41:13 +0200 (MEST) Received: from [144.254.153.29] (dhcp-144-254-153-29.cisco.com [144.254.153.29]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA18410; Thu, 5 Oct 2006 13:41:12 +0100 (BST) Message-ID: <4524FD68.8010008@cisco.com> Date: Thu, 05 Oct 2006 13:41:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Hitoshi Irino , Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> In-Reply-To: <4524812B.2010900@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1036; t=1160052076; x=1160916076; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow |To:Hitoshi=20Irino=20, =20Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D; b=gifuaXodua8dpRZK3mUxIOAdlDOx0QQ3DtsfDonE6iNF3PyLAyK75s9QC7yN7kep3NhJsXer q2gT7ONSzwcpV4NLrfHtjT2w97TlHPV3cvlPGlaoPM3vLsMTD9Cjia2T; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, Hotishi-san, >> In any case, I'd recommend to the WG that the SysUpTime IEs be >> redefined as 64 bits. > > Thank you for your suggestion, > I also agree to extend data type of SysUpTime IEs to unsigned64. I disagree. The main advantage of sending sysuptime in netflow v9 is to save space, since each flow contains two 32 bit quantities (start and end time) that are referenced to another two 32-bit quantities (sysUpTime and UNIX Secs) in the header. IPFIX doesn't have sysuptime in the header (only Export time), so you have to send a seperate systemInitTimeMilliseconds. Sending that per flow would be wasteful. Perhaps it could be sent as an option. Sending 64 bit sysuptimes completely negates that advantage. At that point you'd be far better sending the absolute flowStart* and flowEnd* IEs which are also 64 bits, but which saves you from performing any calculations to convert the relative sysuptimes to absolute values. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 08:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSXO-0000zp-Tu; Thu, 05 Oct 2006 08:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSXN-0000yN-Nh for ipfix@ietf.org; Thu, 05 Oct 2006 08:41:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSXM-0003wT-GF for ipfix@ietf.org; Thu, 05 Oct 2006 08:41:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 08:41:16 -0400 X-IronPort-AV: i="4.09,263,1157342400"; d="scan'208"; a="105817509:sNHT54834876" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95CfF7v018761; Thu, 5 Oct 2006 08:41:16 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95CfDmd000744; Thu, 5 Oct 2006 14:41:13 +0200 (MEST) Received: from [144.254.153.29] (dhcp-144-254-153-29.cisco.com [144.254.153.29]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA18410; Thu, 5 Oct 2006 13:41:12 +0100 (BST) Message-ID: <4524FD68.8010008@cisco.com> Date: Thu, 05 Oct 2006 13:41:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Hitoshi Irino , Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> In-Reply-To: <4524812B.2010900@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1036; t=1160052076; x=1160916076; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow |To:Hitoshi=20Irino=20, =20Brian=20Trammell=20; X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D; b=gifuaXodua8dpRZK3mUxIOAdlDOx0QQ3DtsfDonE6iNF3PyLAyK75s9QC7yN7kep3NhJsXer q2gT7ONSzwcpV4NLrfHtjT2w97TlHPV3cvlPGlaoPM3vLsMTD9Cjia2T; Authentication-Results: rtp-dkim-1.cisco.com; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, Hotishi-san, >> In any case, I'd recommend to the WG that the SysUpTime IEs be >> redefined as 64 bits. > > Thank you for your suggestion, > I also agree to extend data type of SysUpTime IEs to unsigned64. I disagree. The main advantage of sending sysuptime in netflow v9 is to save space, since each flow contains two 32 bit quantities (start and end time) that are referenced to another two 32-bit quantities (sysUpTime and UNIX Secs) in the header. IPFIX doesn't have sysuptime in the header (only Export time), so you have to send a seperate systemInitTimeMilliseconds. Sending that per flow would be wasteful. Perhaps it could be sent as an option. Sending 64 bit sysuptimes completely negates that advantage. At that point you'd be far better sending the absolute flowStart* and flowEnd* IEs which are also 64 bits, but which saves you from performing any calculations to convert the relative sysuptimes to absolute values. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 10:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUFn-00062U-70; Thu, 05 Oct 2006 10:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUFl-00062O-Vy for ipfix@ietf.org; Thu, 05 Oct 2006 10:31:13 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUFj-0005rS-NO for ipfix@ietf.org; Thu, 05 Oct 2006 10:31:13 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k95EV573030758 for ; Thu, 5 Oct 2006 10:31:07 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k95ETUuJ030622 for ; Thu, 5 Oct 2006 10:29:30 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k95ETU39030618; Thu, 05 Oct 2006 10:29:30 -0400 (EDT) Received: from [128.237.234.248] (vpn-10-25-4-27.remote.cert.org [10.25.4.27]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k95ETU3G012870; Thu, 5 Oct 2006 10:29:30 -0400 In-Reply-To: <4524FD68.8010008@cisco.com> References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09E808C5-96BD-4D93-B220-8D6110757197@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow Date: Thu, 5 Oct 2006 10:28:57 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Paul, Hitoshi-san, I presume in all of this that systemInitTimeMilliseconds gets sent once per session as an option and is stored by the Collecting Process for the duration; also, I'm presuming that in the common case the flow {Start,End}SysUpTime IE would be encoded using 32 bits via reduced length encoding (much like commonPropertiesID, the definition would be unsigned64, but you really wouldn't expect to see it on the wire that way most of the time). The issue with simply moving the systemInitTimeMilliseconds counter forward (i.e., simulating a restart) is that the information element defintion (INFO-13 section 5.9.11) clearly states that this is the actual reinitialization time; it doesn't allow for simulation. Collecting Processes that presume this is a true restart time (perhaps, that might warn the user on unscheduled MP/EP restart) could behave inappropriately under simulated restart conditions. Certainly, a CP could be confused by a MP/EP restart not accompanied by a session restart. Now, I could see the use of three other information elements that could be used to implement initTime/upTime flow timestamps without this semantic difficulty: let's call them flowBaseTimeMilliseconds, flowStartOffsetMilliseconds, and flowEndOffsetMilliseconds. I'm not _actually_ proposing this, but it does give us a way to define the offsets as unsigned32 without breaking the meaning of InitTime. - Brian On Oct 5, 2006, at 8:41 AM, Paul Aitken wrote: > Brian, Hotishi-san, > >>> In any case, I'd recommend to the WG that the SysUpTime IEs be >>> redefined as 64 bits. >> Thank you for your suggestion, >> I also agree to extend data type of SysUpTime IEs to unsigned64. > > I disagree. > > The main advantage of sending sysuptime in netflow v9 is to save > space, since each flow contains two 32 bit quantities (start and > end time) that are referenced to another two 32-bit quantities > (sysUpTime and UNIX Secs) in the header. > > IPFIX doesn't have sysuptime in the header (only Export time), so > you have to send a seperate systemInitTimeMilliseconds. Sending > that per flow would be wasteful. Perhaps it could be sent as an > option. > > Sending 64 bit sysuptimes completely negates that advantage. At > that point you'd be far better sending the absolute flowStart* and > flowEnd* IEs which are also 64 bits, but which saves you from > performing any calculations to convert the relative sysuptimes to > absolute values. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 10:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUFn-00062U-70; Thu, 05 Oct 2006 10:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUFl-00062O-Vy for ipfix@ietf.org; Thu, 05 Oct 2006 10:31:13 -0400 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUFj-0005rS-NO for ipfix@ietf.org; Thu, 05 Oct 2006 10:31:13 -0400 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k95EV573030758 for ; Thu, 5 Oct 2006 10:31:07 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k95ETUuJ030622 for ; Thu, 5 Oct 2006 10:29:30 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k95ETU39030618; Thu, 05 Oct 2006 10:29:30 -0400 (EDT) Received: from [128.237.234.248] (vpn-10-25-4-27.remote.cert.org [10.25.4.27]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id k95ETU3G012870; Thu, 5 Oct 2006 10:29:30 -0400 In-Reply-To: <4524FD68.8010008@cisco.com> References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09E808C5-96BD-4D93-B220-8D6110757197@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow Date: Thu, 5 Oct 2006 10:28:57 -0400 To: Paul Aitken X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Paul, Hitoshi-san, I presume in all of this that systemInitTimeMilliseconds gets sent once per session as an option and is stored by the Collecting Process for the duration; also, I'm presuming that in the common case the flow {Start,End}SysUpTime IE would be encoded using 32 bits via reduced length encoding (much like commonPropertiesID, the definition would be unsigned64, but you really wouldn't expect to see it on the wire that way most of the time). The issue with simply moving the systemInitTimeMilliseconds counter forward (i.e., simulating a restart) is that the information element defintion (INFO-13 section 5.9.11) clearly states that this is the actual reinitialization time; it doesn't allow for simulation. Collecting Processes that presume this is a true restart time (perhaps, that might warn the user on unscheduled MP/EP restart) could behave inappropriately under simulated restart conditions. Certainly, a CP could be confused by a MP/EP restart not accompanied by a session restart. Now, I could see the use of three other information elements that could be used to implement initTime/upTime flow timestamps without this semantic difficulty: let's call them flowBaseTimeMilliseconds, flowStartOffsetMilliseconds, and flowEndOffsetMilliseconds. I'm not _actually_ proposing this, but it does give us a way to define the offsets as unsigned32 without breaking the meaning of InitTime. - Brian On Oct 5, 2006, at 8:41 AM, Paul Aitken wrote: > Brian, Hotishi-san, > >>> In any case, I'd recommend to the WG that the SysUpTime IEs be >>> redefined as 64 bits. >> Thank you for your suggestion, >> I also agree to extend data type of SysUpTime IEs to unsigned64. > > I disagree. > > The main advantage of sending sysuptime in netflow v9 is to save > space, since each flow contains two 32 bit quantities (start and > end time) that are referenced to another two 32-bit quantities > (sysUpTime and UNIX Secs) in the header. > > IPFIX doesn't have sysuptime in the header (only Export time), so > you have to send a seperate systemInitTimeMilliseconds. Sending > that per flow would be wasteful. Perhaps it could be sent as an > option. > > Sending 64 bit sysuptimes completely negates that advantage. At > that point you'd be far better sending the absolute flowStart* and > flowEnd* IEs which are also 64 bits, but which saves you from > performing any calculations to convert the relative sysuptimes to > absolute values. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 10:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgy-0001Dg-4H; Thu, 05 Oct 2006 10:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgY-0008Gc-LF for ipfix@ietf.org; Thu, 05 Oct 2006 10:58:54 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUSp-0001jL-79 for ipfix@ietf.org; Thu, 05 Oct 2006 10:44:50 -0400 Received: from [192.168.1.11] (z82.58-98-178.ppp.wakwak.ne.jp [58.98.178.82]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 488D14D865; Thu, 5 Oct 2006 23:44:23 +0900 (JST) Message-ID: <45251A10.9060300@sfc.wide.ad.jp> Date: Thu, 05 Oct 2006 23:43:28 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> In-Reply-To: <4524FD68.8010008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear paul, Paul Aitken wrote: > Brian, Hotishi-san, > >>> In any case, I'd recommend to the WG that the SysUpTime IEs be >>> redefined as 64 bits. >> >> Thank you for your suggestion, >> I also agree to extend data type of SysUpTime IEs to unsigned64. > > I disagree. > > The main advantage of sending sysuptime in netflow v9 is to save space, > since each flow contains two 32 bit quantities (start and end time) that > are referenced to another two 32-bit quantities (sysUpTime and UNIX > Secs) in the header. > > IPFIX doesn't have sysuptime in the header (only Export time), so you > have to send a seperate systemInitTimeMilliseconds. Sending that per > flow would be wasteful. Perhaps it could be sent as an option. I know that systemInitTimeMilliseconds can be sent in option. Do you suggest that exporter update systemInitTimeMilliseconds whenever SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.) But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" are different. (systemInitTimeMilliseconds is defined as "The absolute timestamp of the last (re-)initialization of the IFPIX Device") > Sending 64 bit sysuptimes completely negates that advantage. At that > point you'd be far better sending the absolute flowStart* and flowEnd* > IEs which are also 64 bits, but which saves you from performing any > calculations to convert the relative sysuptimes to absolute values. But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime whose data type are unsgined64. Therefore, I think 64 bit sysuptimes do not negates that advantage. If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, and the new IE should be sent with systemInitTimeMilliseconds in option. regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 10:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgy-0001Dg-4H; Thu, 05 Oct 2006 10:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgY-0008Gc-LF for ipfix@ietf.org; Thu, 05 Oct 2006 10:58:54 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUSp-0001jL-79 for ipfix@ietf.org; Thu, 05 Oct 2006 10:44:50 -0400 Received: from [192.168.1.11] (z82.58-98-178.ppp.wakwak.ne.jp [58.98.178.82]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 488D14D865; Thu, 5 Oct 2006 23:44:23 +0900 (JST) Message-ID: <45251A10.9060300@sfc.wide.ad.jp> Date: Thu, 05 Oct 2006 23:43:28 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> In-Reply-To: <4524FD68.8010008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear paul, Paul Aitken wrote: > Brian, Hotishi-san, > >>> In any case, I'd recommend to the WG that the SysUpTime IEs be >>> redefined as 64 bits. >> >> Thank you for your suggestion, >> I also agree to extend data type of SysUpTime IEs to unsigned64. > > I disagree. > > The main advantage of sending sysuptime in netflow v9 is to save space, > since each flow contains two 32 bit quantities (start and end time) that > are referenced to another two 32-bit quantities (sysUpTime and UNIX > Secs) in the header. > > IPFIX doesn't have sysuptime in the header (only Export time), so you > have to send a seperate systemInitTimeMilliseconds. Sending that per > flow would be wasteful. Perhaps it could be sent as an option. I know that systemInitTimeMilliseconds can be sent in option. Do you suggest that exporter update systemInitTimeMilliseconds whenever SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.) But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" are different. (systemInitTimeMilliseconds is defined as "The absolute timestamp of the last (re-)initialization of the IFPIX Device") > Sending 64 bit sysuptimes completely negates that advantage. At that > point you'd be far better sending the absolute flowStart* and flowEnd* > IEs which are also 64 bits, but which saves you from performing any > calculations to convert the relative sysuptimes to absolute values. But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime whose data type are unsgined64. Therefore, I think 64 bit sysuptimes do not negates that advantage. If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, and the new IE should be sent with systemInitTimeMilliseconds in option. regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 14:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXb5-0005E7-Q5; Thu, 05 Oct 2006 14:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXb4-0005Dz-BA for ipfix@ietf.org; Thu, 05 Oct 2006 14:05:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXb2-0000HV-UW for ipfix@ietf.org; Thu, 05 Oct 2006 14:05:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 14:05:24 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105870937:sNHT57676532" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95I5OQq008310 for ; Thu, 5 Oct 2006 14:05:24 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95I5Nmd009442 for ; Thu, 5 Oct 2006 20:05:24 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA22273 for ; Thu, 5 Oct 2006 19:05:23 +0100 (BST) Message-ID: <45254963.9050802@cisco.com> Date: Thu, 05 Oct 2006 19:05:23 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=5264; t=1160071524; x=1160935524; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Observation=20Domains,=20Templates,=20and=20Session |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DqB8Lwxpifi2FPHF1vssZ/zEZO0o=3D; b=FwU9xq04pA+9/g5lg0+IYseNDwjkQwaKpxsYYCZC4xD+FnqbYQNxbItzUfhUDYqYLDFaDsoI ILyDEYYjjZB+bf6qWv9mGqiR38P9gvfHvfFg57WmvBAcj0yuEuCKEwkw; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [IPFIX] Observation Domains, Templates, and Session X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello all With regard to the recent discussion on the mailing list titled: "Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions" The discussion doesn't seem to be going anywhere and I hope this email will define the heart of the problem sufficiently that we can all jump on board and find a solution. I realise this is quite a long email but it's written in logical sections, each one providing more details. You can stop reading as soon as you agree with me :-) regards Andrew THE PROBLEM =========== It is agreed that with the present definition of the IPFIX protocol the Collecting Process cannot reliably differentiate between different Exporting Processes on a single IPFIX device. This is a problem because the Observation Domain ID is considered "unique per Exporting Process". Now if the Collector cannot differentiate between Exporting Processes, how does it correctly scope this Identifier? In short, it can't. We MUST change the scoping of this identifier to something the CP can differentiate. Re-scoping OD ID requires care because it is included in the IPFIX header and several other IEs are scoped per Observation Domain: templateId, flowId, observationPointId and commonPropertiesId. WHAT WE HAVE TODAY ================== Currently the Observation Domain is considered unique per Exporting Process and the Exporting Process ID is considered unique per IPFIX device. Scope has to be inherited, i.e. a template ID is really unique per Observation Domain, per Exporting Process, per IPFIX Device. Currently we have: IPFIX Device -> Exporting Process -> Observation Domain -> Template This means that each Exporting process has a set of templates and other identifiers per Observation Domain. This is great because then the different parts of a distributed Exporter simply need to pick a different OD ID and then they can use templates etc. as required. If you look at the history of the OD ID (sourceID) you can see this was the original purpose (see below). Alas, we can't have Exporting Process as the scope so what are the alternatives? PROPOSED SOLUTION ================= Scope the Observation Domain to the communication session between the EP and the CP. This is very similar to scoping it to the Exporting Process however if an Exporting Process has a session restart then it would have to resend the definitions of all its templates and other identifiers. Well originally, we thought that the Collecting Process would differentiate between Exporting Processes via the session and the protocol already says that the templates must be resent on a TCP or SCTP session restart. Now that we realise that a session can restart even if the Exporting Process doesn't we have to be explicit and make sure we resend all the identifiers scoped to the session for all transport protocols, including UDP. SO WHAT'S THE DOWNSIDE? ======================= Well the humble sourceID has now evolved into an identifier of the Observation Domain and there are some who feel that that is a really useful thing to know. The thing is we don't actually ever know the Observation Domain, we know the Observation Domain ID, but it is never defined. If we look at the history of the Observation Domain ID (sourceID) we can see it was never intended as anything other than something to scope other fields. Recent editing changes have evolved how we have come to think of it. HISTORY OF THE OBSERVATION DOMAIN ID ==================================== It began life as the source ID. It was used, as in v9, by an Exporting Process to select the scope of information from different line cards in a distributed system. By using a different source ID per line card, each line card could use its own set of templates and other identifiers. From IPFIX-INFO 7 to 11: 5.1.9. sourceId Description: An identifier of an Observation Domain that is locally unique to an Exporting Process. Typically, this Information Element is used for limiting the scope of other Information Elements. Then we changed it to be called the Observation Domain ID. After all, it is an identifier of the Observation Domain, right? Well it is, but it's primary function is still to make a distributed Exporting Process easier to manage by allowing different line cards to have their own set of templates and identifiers. From IPFIX-INFO 12: 5.1.9. observationDomainId Description: An identifier of an Observation Domain that is unique per Exporting Process. And now in from IPFIX-INFO 13: 5.1.9. observationDomainId Description: An identifier of an Observation Domain that is locally unique to an Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain where Flows were metered. Now these are the definition of the Observation Domain ID Information Element. Note that the Observation Domain ID is included in the header of every IPFIX message, and this is why it is so important. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Oct 05 14:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXb5-0005E7-Q5; Thu, 05 Oct 2006 14:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXb4-0005Dz-BA for ipfix@ietf.org; Thu, 05 Oct 2006 14:05:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXb2-0000HV-UW for ipfix@ietf.org; Thu, 05 Oct 2006 14:05:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 14:05:24 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105870937:sNHT57676532" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95I5OQq008310 for ; Thu, 5 Oct 2006 14:05:24 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95I5Nmd009442 for ; Thu, 5 Oct 2006 20:05:24 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA22273 for ; Thu, 5 Oct 2006 19:05:23 +0100 (BST) Message-ID: <45254963.9050802@cisco.com> Date: Thu, 05 Oct 2006 19:05:23 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=5264; t=1160071524; x=1160935524; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Observation=20Domains,=20Templates,=20and=20Session |To:ipfix@ietf.org; X=v=3Dcisco.com=3B=20h=3DqB8Lwxpifi2FPHF1vssZ/zEZO0o=3D; b=FwU9xq04pA+9/g5lg0+IYseNDwjkQwaKpxsYYCZC4xD+FnqbYQNxbItzUfhUDYqYLDFaDsoI ILyDEYYjjZB+bf6qWv9mGqiR38P9gvfHvfFg57WmvBAcj0yuEuCKEwkw; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [IPFIX] Observation Domains, Templates, and Session X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello all With regard to the recent discussion on the mailing list titled: "Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions" The discussion doesn't seem to be going anywhere and I hope this email will define the heart of the problem sufficiently that we can all jump on board and find a solution. I realise this is quite a long email but it's written in logical sections, each one providing more details. You can stop reading as soon as you agree with me :-) regards Andrew THE PROBLEM =========== It is agreed that with the present definition of the IPFIX protocol the Collecting Process cannot reliably differentiate between different Exporting Processes on a single IPFIX device. This is a problem because the Observation Domain ID is considered "unique per Exporting Process". Now if the Collector cannot differentiate between Exporting Processes, how does it correctly scope this Identifier? In short, it can't. We MUST change the scoping of this identifier to something the CP can differentiate. Re-scoping OD ID requires care because it is included in the IPFIX header and several other IEs are scoped per Observation Domain: templateId, flowId, observationPointId and commonPropertiesId. WHAT WE HAVE TODAY ================== Currently the Observation Domain is considered unique per Exporting Process and the Exporting Process ID is considered unique per IPFIX device. Scope has to be inherited, i.e. a template ID is really unique per Observation Domain, per Exporting Process, per IPFIX Device. Currently we have: IPFIX Device -> Exporting Process -> Observation Domain -> Template This means that each Exporting process has a set of templates and other identifiers per Observation Domain. This is great because then the different parts of a distributed Exporter simply need to pick a different OD ID and then they can use templates etc. as required. If you look at the history of the OD ID (sourceID) you can see this was the original purpose (see below). Alas, we can't have Exporting Process as the scope so what are the alternatives? PROPOSED SOLUTION ================= Scope the Observation Domain to the communication session between the EP and the CP. This is very similar to scoping it to the Exporting Process however if an Exporting Process has a session restart then it would have to resend the definitions of all its templates and other identifiers. Well originally, we thought that the Collecting Process would differentiate between Exporting Processes via the session and the protocol already says that the templates must be resent on a TCP or SCTP session restart. Now that we realise that a session can restart even if the Exporting Process doesn't we have to be explicit and make sure we resend all the identifiers scoped to the session for all transport protocols, including UDP. SO WHAT'S THE DOWNSIDE? ======================= Well the humble sourceID has now evolved into an identifier of the Observation Domain and there are some who feel that that is a really useful thing to know. The thing is we don't actually ever know the Observation Domain, we know the Observation Domain ID, but it is never defined. If we look at the history of the Observation Domain ID (sourceID) we can see it was never intended as anything other than something to scope other fields. Recent editing changes have evolved how we have come to think of it. HISTORY OF THE OBSERVATION DOMAIN ID ==================================== It began life as the source ID. It was used, as in v9, by an Exporting Process to select the scope of information from different line cards in a distributed system. By using a different source ID per line card, each line card could use its own set of templates and other identifiers. From IPFIX-INFO 7 to 11: 5.1.9. sourceId Description: An identifier of an Observation Domain that is locally unique to an Exporting Process. Typically, this Information Element is used for limiting the scope of other Information Elements. Then we changed it to be called the Observation Domain ID. After all, it is an identifier of the Observation Domain, right? Well it is, but it's primary function is still to make a distributed Exporting Process easier to manage by allowing different line cards to have their own set of templates and identifiers. From IPFIX-INFO 12: 5.1.9. observationDomainId Description: An identifier of an Observation Domain that is unique per Exporting Process. And now in from IPFIX-INFO 13: 5.1.9. observationDomainId Description: An identifier of an Observation Domain that is locally unique to an Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain where Flows were metered. Now these are the definition of the Observation Domain ID Information Element. Note that the Observation Domain ID is included in the header of every IPFIX message, and this is why it is so important. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 06 11:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSN-0006Jp-5c; Fri, 06 Oct 2006 11:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSJ-0006Ii-VA for ipfix@ietf.org; Fri, 06 Oct 2006 11:17:43 -0400 Received: from serv-80-156.sernet.de ([193.175.80.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrI7-0008IS-DD for ipfix@ietf.org; Fri, 06 Oct 2006 11:07:15 -0400 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by serv-80-156.SerNet.DE with esmtpa (Exim 4.51) id 1GVrHz-0006K6-MM; Fri, 06 Oct 2006 17:07:03 +0200 Message-ID: <45267117.8080809@CS.Uni-Goettingen.DE> Date: Fri, 06 Oct 2006 17:07:03 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Thunderbird 1.5.0.7 (X11/20060911) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> In-Reply-To: <45254963.9050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all, Andrew Johnson, 05.10.2006 20:05: > The discussion doesn't seem to be going anywhere and I hope this > email will define the heart of the problem sufficiently that we > can all jump on board and find a solution. I realise this is > quite a long email but it's written in logical sections, each one > providing more details. You can stop reading as soon as you > agree with me :-) if you are interested in a bit more abstract, top-down approach thoughts from an outsider viewpoint: I think you guys _have_ to use a session ID for scoping. (Be careful, the following might be confusing to some people. ;-) ) To avoid collisions the collector needs to globally identify the template of each record in some way. So either you send the whole cascade of identifiers with each record, which together form a globally unique identifier for the template, or - to save space in the headers - you use a temporary identifier, which is unique for both the sender and receiver and which is mapped to the global template identifier or at least a part of it. For the second option you need a handshake, which is not possible with the IPFIX protocol, as it is designed as a one-way protocol. So the only handshake that happens is on the transport layer for session management. Only this session identifier you can use as a replacement for the part of the identifier cascade, which doesn't change during one session, in order to save space in the headers. So you would probably, if I understand it correctly, map the session ID to {IPFIX Device ID, Exporting Process ID} on the collectors side and scope the OD ID to the session ID. If you expect that the OD ID is most of the time the same during one session, you could even map the session ID to {IPFIX Device ID, Exporting Process ID, OD ID} and scope the template ID directly to the session ID, then you could even remove the OD ID from the headers. Of course with the down side, that you have to open several sessions for several OD IDs. But probably changing the IPFIX protocol is not an option at this time anyway. ;-) Regards, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 06 11:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSN-0006Jp-5c; Fri, 06 Oct 2006 11:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSJ-0006Ii-VA for ipfix@ietf.org; Fri, 06 Oct 2006 11:17:43 -0400 Received: from serv-80-156.sernet.de ([193.175.80.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrI7-0008IS-DD for ipfix@ietf.org; Fri, 06 Oct 2006 11:07:15 -0400 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by serv-80-156.SerNet.DE with esmtpa (Exim 4.51) id 1GVrHz-0006K6-MM; Fri, 06 Oct 2006 17:07:03 +0200 Message-ID: <45267117.8080809@CS.Uni-Goettingen.DE> Date: Fri, 06 Oct 2006 17:07:03 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Thunderbird 1.5.0.7 (X11/20060911) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> In-Reply-To: <45254963.9050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all, Andrew Johnson, 05.10.2006 20:05: > The discussion doesn't seem to be going anywhere and I hope this > email will define the heart of the problem sufficiently that we > can all jump on board and find a solution. I realise this is > quite a long email but it's written in logical sections, each one > providing more details. You can stop reading as soon as you > agree with me :-) if you are interested in a bit more abstract, top-down approach thoughts from an outsider viewpoint: I think you guys _have_ to use a session ID for scoping. (Be careful, the following might be confusing to some people. ;-) ) To avoid collisions the collector needs to globally identify the template of each record in some way. So either you send the whole cascade of identifiers with each record, which together form a globally unique identifier for the template, or - to save space in the headers - you use a temporary identifier, which is unique for both the sender and receiver and which is mapped to the global template identifier or at least a part of it. For the second option you need a handshake, which is not possible with the IPFIX protocol, as it is designed as a one-way protocol. So the only handshake that happens is on the transport layer for session management. Only this session identifier you can use as a replacement for the part of the identifier cascade, which doesn't change during one session, in order to save space in the headers. So you would probably, if I understand it correctly, map the session ID to {IPFIX Device ID, Exporting Process ID} on the collectors side and scope the OD ID to the session ID. If you expect that the OD ID is most of the time the same during one session, you could even map the session ID to {IPFIX Device ID, Exporting Process ID, OD ID} and scope the template ID directly to the session ID, then you could even remove the OD ID from the headers. Of course with the down side, that you have to open several sessions for several OD IDs. But probably changing the IPFIX protocol is not an option at this time anyway. ;-) Regards, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 06 12:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCZ-0008CQ-3x; Fri, 06 Oct 2006 12:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCX-00089c-7U for ipfix@ietf.org; Fri, 06 Oct 2006 12:05:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsCV-0000mb-VD for ipfix@ietf.org; Fri, 06 Oct 2006 12:05:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2006 12:05:28 -0400 X-IronPort-AV: i="4.09,273,1157342400"; d="scan'208"; a="105996397:sNHT53320988" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96G5RA4005514; Fri, 6 Oct 2006 12:05:27 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k96G5Qmd026474; Fri, 6 Oct 2006 18:05:26 +0200 (MEST) Received: from [10.61.64.112] (ams3-vpn-dhcp112.cisco.com [10.61.64.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA08199; Fri, 6 Oct 2006 17:05:26 +0100 (BST) Message-ID: <45267EA7.6070205@cisco.com> Date: Fri, 06 Oct 2006 17:04:55 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sven Anderson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> <45267117.8080809@CS.Uni-Goettingen.DE> In-Reply-To: <45267117.8080809@CS.Uni-Goettingen.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2489; t=1160150727; x=1161014727; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Observation=20Domains, =20Templates, =20and=20Session |To:Sven=20Anderson=20; X=v=3Dcisco.com=3B=20h=3Dy2IH1UfIbTadBUhzIGYgeqmoLtQ=3D; b=vJPnQGWqqfnejl3TY59p9nLsNNahSbfZqkzrcmernGIU9XN+lR6KcUmUEypoMI2ZfUxYqxM2 iJt6aDbzL3+BhcmmE9WFfiqTbmvyVxxiCL2H0m88GlmGRQuqief4fP0H; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Sven Anderson wrote: > Hi all, > > Andrew Johnson, 05.10.2006 20:05: >> The discussion doesn't seem to be going anywhere and I hope this >> email will define the heart of the problem sufficiently that we >> can all jump on board and find a solution. I realise this is >> quite a long email but it's written in logical sections, each one >> providing more details. You can stop reading as soon as you >> agree with me :-) > > if you are interested in a bit more abstract, top-down approach thoughts > from an outsider viewpoint: I think you guys _have_ to use a session ID > for scoping. > > (Be careful, the following might be confusing to some people. ;-) ) > > To avoid collisions the collector needs to globally identify the template > of each record in some way. So either you send the whole cascade of > identifiers with each record, which together form a globally unique > identifier for the template, or - to save space in the headers - you use a > temporary identifier, which is unique for both the sender and receiver and > which is mapped to the global template identifier or at least a part of > it. For the second option you need a handshake, which is not possible with > the IPFIX protocol, as it is designed as a one-way protocol. So the only > handshake that happens is on the transport layer for session management. > Only this session identifier you can use as a replacement for the part of > the identifier cascade, which doesn't change during one session, in order > to save space in the headers. > > So you would probably, if I understand it correctly, map the session ID to > {IPFIX Device ID, Exporting Process ID} on the collectors side and scope > the OD ID to the session ID. Almost. The Collecting Process can't identify the Exporting Process. I'm proposing that the session identifier won't map directly to anything, but instead provide scope as a replacement for the Exporting Process ID. regards Andrew > If you expect that the OD ID is most of the > time the same during one session, you could even map the session ID to > {IPFIX Device ID, Exporting Process ID, OD ID} and scope the template ID > directly to the session ID, then you could even remove the OD ID from the > headers. Of course with the down side, that you have to open several > sessions for several OD IDs. But probably changing the IPFIX protocol is > not an option at this time anyway. ;-) > > > Regards, > > Sven > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Oct 06 12:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCZ-0008CQ-3x; Fri, 06 Oct 2006 12:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCX-00089c-7U for ipfix@ietf.org; Fri, 06 Oct 2006 12:05:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsCV-0000mb-VD for ipfix@ietf.org; Fri, 06 Oct 2006 12:05:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2006 12:05:28 -0400 X-IronPort-AV: i="4.09,273,1157342400"; d="scan'208"; a="105996397:sNHT53320988" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96G5RA4005514; Fri, 6 Oct 2006 12:05:27 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k96G5Qmd026474; Fri, 6 Oct 2006 18:05:26 +0200 (MEST) Received: from [10.61.64.112] (ams3-vpn-dhcp112.cisco.com [10.61.64.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA08199; Fri, 6 Oct 2006 17:05:26 +0100 (BST) Message-ID: <45267EA7.6070205@cisco.com> Date: Fri, 06 Oct 2006 17:04:55 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sven Anderson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> <45267117.8080809@CS.Uni-Goettingen.DE> In-Reply-To: <45267117.8080809@CS.Uni-Goettingen.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2489; t=1160150727; x=1161014727; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Observation=20Domains, =20Templates, =20and=20Session |To:Sven=20Anderson=20; X=v=3Dcisco.com=3B=20h=3Dy2IH1UfIbTadBUhzIGYgeqmoLtQ=3D; b=vJPnQGWqqfnejl3TY59p9nLsNNahSbfZqkzrcmernGIU9XN+lR6KcUmUEypoMI2ZfUxYqxM2 iJt6aDbzL3+BhcmmE9WFfiqTbmvyVxxiCL2H0m88GlmGRQuqief4fP0H; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Sven Anderson wrote: > Hi all, > > Andrew Johnson, 05.10.2006 20:05: >> The discussion doesn't seem to be going anywhere and I hope this >> email will define the heart of the problem sufficiently that we >> can all jump on board and find a solution. I realise this is >> quite a long email but it's written in logical sections, each one >> providing more details. You can stop reading as soon as you >> agree with me :-) > > if you are interested in a bit more abstract, top-down approach thoughts > from an outsider viewpoint: I think you guys _have_ to use a session ID > for scoping. > > (Be careful, the following might be confusing to some people. ;-) ) > > To avoid collisions the collector needs to globally identify the template > of each record in some way. So either you send the whole cascade of > identifiers with each record, which together form a globally unique > identifier for the template, or - to save space in the headers - you use a > temporary identifier, which is unique for both the sender and receiver and > which is mapped to the global template identifier or at least a part of > it. For the second option you need a handshake, which is not possible with > the IPFIX protocol, as it is designed as a one-way protocol. So the only > handshake that happens is on the transport layer for session management. > Only this session identifier you can use as a replacement for the part of > the identifier cascade, which doesn't change during one session, in order > to save space in the headers. > > So you would probably, if I understand it correctly, map the session ID to > {IPFIX Device ID, Exporting Process ID} on the collectors side and scope > the OD ID to the session ID. Almost. The Collecting Process can't identify the Exporting Process. I'm proposing that the session identifier won't map directly to anything, but instead provide scope as a replacement for the Exporting Process ID. regards Andrew > If you expect that the OD ID is most of the > time the same during one session, you could even map the session ID to > {IPFIX Device ID, Exporting Process ID, OD ID} and scope the template ID > directly to the session ID, then you could even remove the OD ID from the > headers. Of course with the down side, that you have to open several > sessions for several OD IDs. But probably changing the IPFIX protocol is > not an option at this time anyway. ;-) > > > Regards, > > Sven > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 10:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw8T-0002z2-O3; Mon, 09 Oct 2006 10:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw8S-0002yw-Lb for ipfix@ietf.org; Mon, 09 Oct 2006 10:29:40 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWw8R-0001xZ-7X for ipfix@ietf.org; Mon, 09 Oct 2006 10:29:40 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99ESFd20514; Mon, 9 Oct 2006 16:28:15 +0200 (MEST) Message-ID: <452A5CC9.6010104@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 16:29:29 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> In-Reply-To: <45254963.9050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > THE PROBLEM > =========== > It is agreed that with the present definition of the IPFIX protocol > the Collecting Process cannot reliably differentiate between > different Exporting Processes on a single IPFIX device. This is a yes. > problem because the Observation Domain ID is considered "unique per > Exporting Process". I don't follow you here. You can have the observation domain unique per Exporting Process. It is enough to limit the validity of TemplateIDs and CommonPropertiesIDs to the respective communication sessions. Then the Collecting Process does not need any knowledge about the originating Exporting Process. Or do I miss something? Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 10:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw8T-0002z2-O3; Mon, 09 Oct 2006 10:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw8S-0002yw-Lb for ipfix@ietf.org; Mon, 09 Oct 2006 10:29:40 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWw8R-0001xZ-7X for ipfix@ietf.org; Mon, 09 Oct 2006 10:29:40 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99ESFd20514; Mon, 9 Oct 2006 16:28:15 +0200 (MEST) Message-ID: <452A5CC9.6010104@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 16:29:29 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Observation Domains, Templates, and Session References: <45254963.9050802@cisco.com> In-Reply-To: <45254963.9050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > THE PROBLEM > =========== > It is agreed that with the present definition of the IPFIX protocol > the Collecting Process cannot reliably differentiate between > different Exporting Processes on a single IPFIX device. This is a yes. > problem because the Observation Domain ID is considered "unique per > Exporting Process". I don't follow you here. You can have the observation domain unique per Exporting Process. It is enough to limit the validity of TemplateIDs and CommonPropertiesIDs to the respective communication sessions. Then the Collecting Process does not need any knowledge about the originating Exporting Process. Or do I miss something? Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 10:38:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwH3-0002MU-Ot; Mon, 09 Oct 2006 10:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwH2-0002MP-BC for ipfix@ietf.org; Mon, 09 Oct 2006 10:38:32 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwH0-0004Qo-Ss for ipfix@ietf.org; Mon, 09 Oct 2006 10:38:32 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99EbFd21903; Mon, 9 Oct 2006 16:37:15 +0200 (MEST) Message-ID: <452A5EE6.7010203@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 16:38:30 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> In-Reply-To: <451BFA80.8070206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, >>> If we have two software programs, from two different vendors, running >>> on a linux based router. Both these programs are monitoring flows >>> and exporting using IPFIX. They are exporting to the same collector >>> from the same Observation Domain. >>> >>> As far as the collector is concerned, these are two sessions from >>> the same IPFIX device. There is no way of telling different Exporting >>> Processes apart. If a network problem caused both sessions to restart >>> simultaneously, the collector has no way to know how the two old >>> sessions map to the new ones. >> >> In your example the two programs should use different OD IDs. >> Then the mapping works. > > What mapping are you referring to? If the two programs export flow records using different OD IDs but keeping them constant on restarts. e.g. prog A use OD ID 1 and prog B use OD ID 2, then the collector can assign data sent before to data send after the session restart, because the OD IDs are the same. In addition the collector can differ data from the two programs, because the OD IDs are different. > > IPFIX INFO rev 12 the OD IDs were considered unique per Exporting > Process. That means that each Exporting Process could export > using it's own set of Observation Domain IDs and that the number > space is not common between them. > > Now we don't use the OD ID as an Exporting Process Identifier. > In short, it is agreed that the EP of a connection cannot be > identified with the mandatory information. So Brain and I are > suggesting that the OD ID is considered unique per connection > session. > > This isn't really a big change, we already mandate that we resend > all the template and option data if the session restarts. It's > already assumed that the collector shouldn't retain certain info > between sessions, it's just not explicit in the protocol. > > The alternative is to scope the Observation Domain ID to be > entire IPFIX device. This means that different Exporting > Processes will have to negotiate (or be configured) to use the > Observation Domains correctly. Furthermore, since template IDs > and other IEs are scoped to the OD ID, then if you wanted two > Exporters to report on the same Observation Domain (with the > same ID) then you would have to negotiate (or configure) use > of Template IDs, flow IDs, common properties IDs, ... > > I really don't see this as practical. Of course not. But I don't see the motivation to do so. TemplateIDs and common properties IDs are unique per Exporting Process and Observation Domain. The Exporting Process may change TIDs and CPIDs assignments when a session restarts if these IDs are only valid within the session. There is no need to negotiate these values with other processes. > Part of the problem here is that the Observation Domain ID seems > to be seen as something useful. Imagine two flows that had > different common properties IDs. You wouldn't expect that to > be useful information without the options to explain what that > ID means. You can't even be assured that the two different IDs > actually map to different properties. The same is true for the > Observation Domain IDs. At least the Observation Domain IDs can be useful for the collector to group incoming data. See above. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 10:38:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwH3-0002MU-Ot; Mon, 09 Oct 2006 10:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwH2-0002MP-BC for ipfix@ietf.org; Mon, 09 Oct 2006 10:38:32 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwH0-0004Qo-Ss for ipfix@ietf.org; Mon, 09 Oct 2006 10:38:32 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99EbFd21903; Mon, 9 Oct 2006 16:37:15 +0200 (MEST) Message-ID: <452A5EE6.7010203@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 16:38:30 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions References: <6540D5EA-973B-4FDB-A151-9DF8D9F604B4@cert.org> <451410B9.4040304@cisco.com> <45142648.4010601@cisco.com> <45178041.60709@cisco.com> <451A5A23.3060705@cisco.com> <451AA5BF.5060002@fokus.fraunhofer.de> <451BFA80.8070206@cisco.com> In-Reply-To: <451BFA80.8070206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, >>> If we have two software programs, from two different vendors, running >>> on a linux based router. Both these programs are monitoring flows >>> and exporting using IPFIX. They are exporting to the same collector >>> from the same Observation Domain. >>> >>> As far as the collector is concerned, these are two sessions from >>> the same IPFIX device. There is no way of telling different Exporting >>> Processes apart. If a network problem caused both sessions to restart >>> simultaneously, the collector has no way to know how the two old >>> sessions map to the new ones. >> >> In your example the two programs should use different OD IDs. >> Then the mapping works. > > What mapping are you referring to? If the two programs export flow records using different OD IDs but keeping them constant on restarts. e.g. prog A use OD ID 1 and prog B use OD ID 2, then the collector can assign data sent before to data send after the session restart, because the OD IDs are the same. In addition the collector can differ data from the two programs, because the OD IDs are different. > > IPFIX INFO rev 12 the OD IDs were considered unique per Exporting > Process. That means that each Exporting Process could export > using it's own set of Observation Domain IDs and that the number > space is not common between them. > > Now we don't use the OD ID as an Exporting Process Identifier. > In short, it is agreed that the EP of a connection cannot be > identified with the mandatory information. So Brain and I are > suggesting that the OD ID is considered unique per connection > session. > > This isn't really a big change, we already mandate that we resend > all the template and option data if the session restarts. It's > already assumed that the collector shouldn't retain certain info > between sessions, it's just not explicit in the protocol. > > The alternative is to scope the Observation Domain ID to be > entire IPFIX device. This means that different Exporting > Processes will have to negotiate (or be configured) to use the > Observation Domains correctly. Furthermore, since template IDs > and other IEs are scoped to the OD ID, then if you wanted two > Exporters to report on the same Observation Domain (with the > same ID) then you would have to negotiate (or configure) use > of Template IDs, flow IDs, common properties IDs, ... > > I really don't see this as practical. Of course not. But I don't see the motivation to do so. TemplateIDs and common properties IDs are unique per Exporting Process and Observation Domain. The Exporting Process may change TIDs and CPIDs assignments when a session restarts if these IDs are only valid within the session. There is no need to negotiate these values with other processes. > Part of the problem here is that the Observation Domain ID seems > to be seen as something useful. Imagine two flows that had > different common properties IDs. You wouldn't expect that to > be useful information without the options to explain what that > ID means. You can't even be assured that the two different IDs > actually map to different properties. The same is true for the > Observation Domain IDs. At least the Observation Domain IDs can be useful for the collector to group incoming data. See above. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 11:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwzg-0003lH-2M; Mon, 09 Oct 2006 11:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwzf-0003jk-Ai for ipfix@ietf.org; Mon, 09 Oct 2006 11:24:39 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwzd-0002Xd-TP for ipfix@ietf.org; Mon, 09 Oct 2006 11:24:39 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99FNOd26919 for ; Mon, 9 Oct 2006 17:23:24 +0200 (MEST) Message-ID: <452A69B7.3040502@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 17:24:39 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX fragmentIdentification References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]> <4521263E.4020006@cisco.com> In-Reply-To: <4521263E.4020006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org > I think I would prefer to go back to #54 = IPv4 ID (coming from the > netflow v9 definition) and create a new fragmentIdentificationIPv6 IE. I support this. We had this discussion before: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html I still prefer to use a name that makes it clear that this info is part of the IPv6 extension header. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 11:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwzg-0003lH-2M; Mon, 09 Oct 2006 11:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwzf-0003jk-Ai for ipfix@ietf.org; Mon, 09 Oct 2006 11:24:39 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwzd-0002Xd-TP for ipfix@ietf.org; Mon, 09 Oct 2006 11:24:39 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99FNOd26919 for ; Mon, 9 Oct 2006 17:23:24 +0200 (MEST) Message-ID: <452A69B7.3040502@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 17:24:39 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX fragmentIdentification References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]> <4521263E.4020006@cisco.com> In-Reply-To: <4521263E.4020006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org > I think I would prefer to go back to #54 = IPv4 ID (coming from the > netflow v9 definition) and create a new fragmentIdentificationIPv6 IE. I support this. We had this discussion before: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html I still prefer to use a name that makes it clear that this info is part of the IPv6 extension header. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 11:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxEJ-0005kf-H2; Mon, 09 Oct 2006 11:39:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxEI-0005kZ-P4 for ipfix@ietf.org; Mon, 09 Oct 2006 11:39:46 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxEH-0004XQ-CC for ipfix@ietf.org; Mon, 09 Oct 2006 11:39:46 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99FcUd28290; Mon, 9 Oct 2006 17:38:30 +0200 (MEST) Message-ID: <452A6D41.1040707@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 17:39:45 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] IPFIX totalLength? References: <45210A8D.6010202@cisco.com> In-Reply-To: <45210A8D.6010202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org > I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I > could not find one. > > Probably all we can do is to calculate #191 payloadLengthIPv6 + 40. > > A new IE, "totalLengthIPv6", would be useful - as would a generic > "IPtotalLength" IE. yes, and to make it complete we need packetTotalLength to be able to count link layer bytes also. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Oct 09 11:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxEJ-0005kf-H2; Mon, 09 Oct 2006 11:39:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxEI-0005kZ-P4 for ipfix@ietf.org; Mon, 09 Oct 2006 11:39:46 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxEH-0004XQ-CC for ipfix@ietf.org; Mon, 09 Oct 2006 11:39:46 -0400 Received: from [10.147.66.125] (i3dhcp125 [10.147.66.125]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k99FcUd28290; Mon, 9 Oct 2006 17:38:30 +0200 (MEST) Message-ID: <452A6D41.1040707@fokus.fraunhofer.de> Date: Mon, 09 Oct 2006 17:39:45 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] IPFIX totalLength? References: <45210A8D.6010202@cisco.com> In-Reply-To: <45210A8D.6010202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org > I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I > could not find one. > > Probably all we can do is to calculate #191 payloadLengthIPv6 + 40. > > A new IE, "totalLengthIPv6", would be useful - as would a generic > "IPtotalLength" IE. yes, and to make it complete we need packetTotalLength to be able to count link layer bytes also. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From jetmail999oooku@yahoo.com Wed Oct 11 02:57:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXY1d-0004fk-Cg for IPFIX-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Oct 2006 02:57:09 -0400 Received: from [60.14.176.90] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXwA-0001no-Pq for IPFIX-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Oct 2006 02:51:35 -0400 Received: from bsj8 (unknown [21.16.110.172]) by smtp80 (Coremail) with SMTP id of4ixTFnt2ljlvt8.1 for ; Wed, 11 Oct 2006 14:51:28 +0800 (CST) X-Originating-IP: [21.16.110.172] Subject: =?iso-2022-jp?B?GyRCIVo/NCRoJGokKk9NJFM/PSQ3PmUkMiReJDkhWxsoQg==?= From: =?gb2312?B?IA==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0027_01C6E7CD.430DD610" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C6E7CD.430DD610 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0028_01C6E7CD.430DD610" ------=_NextPart_001_0028_01C6E7CD.430DD610 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B!JB~:#%"%/%;%9=8Cf$7$F$*$j$^$9!#!K(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B!Z:.;($7$F(B $B$$$k>l9g$O%_%i!<%5%$%H$+$i$*4j$$$7$^$9!#![(B1$B!!(Bhttp://atk.jp/989 2$B!!(B http://mooo.jp/u5jm3$B!!(Bhttp://ul6.com/9v204$B!!(Bhttp://symy.jp/?AyL$B!J(B18$B:PL$K~$O$4MxMQD:$1$^$;$s!K(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!~0FFb$,$4IT(B $BMW$NJ}$O!~(B(An unnecessary email) uselessness_to_sirve@yahoo.co.jp ------=_NextPart_001_0028_01C6E7CD.430DD610 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable 
 =
 =1B$B!JB~:#%"%/%;%9=3D8Cf$7$F$*$j$^$9!#!K=1B(B
=
3D=1B$B$4LBOG$*$+$1$7$F@?$K$9$_$^$;$s!#=1B(B
=1B$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!=
(!(!(!(!(!(!(!(!(!=1B(B
 =1B$B!Z:.;($7$F$$$k>l9g$O=1B(B=1B$B%_%i!<%5%$%H$+$i=
$*4j$$$7$^$9!#![=1B(B
1=1B$B!!=1B(Bhttp://atk.jp/989 =

2=1B$B!!=1B(Bhttp://mooo.jp/u5jm
3=
=1B$B!!=1B(Bhttp://ul6.com/9v20
4=
=1B$B!!=1B(Bhttp://symy.jp/?AyL
=1B=
$B!J=1B(B18=1B$B:PL$K~$O$4MxMQD:$1$^$;$s!K=1B(B
=1B$B(!(!(=
!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!=1B(B
 
 
=1B$B!~0FFb$=
,$4ITMW$NJ}$O!~=1B(B
(An unnece=
ssary email) 


------=_NextPart_001_0028_01C6E7CD.430DD610--

------=_NextPart_000_0027_01C6E7CD.430DD610
Content-Type: image/gif;
	name="anti.gif"
Content-Transfer-Encoding: base64
Content-ID: <002101c6e781$d14e39c0$0d0ba8c0@53e17b9a08bb48c>

R0lGODlh8wCqAPcAANHR0QgtcVdXV8jGxQo2jOtDP7DVubOzs6inpe+WA+jo6JiWl7fZwfTz8wND
l3lOC3CHdnh5eD1IQUdHR1ctCuuiA4yMjJuvovPr6OHh4m5ubgcBAvXy6tvv3wQ8qc3z1wonWI6E
fIV1ZZ9rFdX13DA5Mv7+/gUPNwUXTc7s1vaiBommkerk2iMpJdaQDJ+s2aPFrGFwid/25ARGtmN3
aFNkbFZoW9nj2rzkxxZGpdzc2/j4+BVFl7y9vKOinU9bdSY2Uu4zMu/u7dTHxn2Wg6vLteTa1cfS
zufl5Or18ZWnmgJCoZa2npufounu9ryJDO+tJf777ehUTgNDq5+Xlcbby/QTF/Pw8cHCwGRWVerr
5xcaF/P5/LXEu7OtqKG6qHmMgxAEBm1oX/mqFcK9uDFLbfn089mjDwkgOhZKs66zrT4hAwtBoKy7
ukpYTYiUkBdCviUWFoyanxtHjp2NgwZStmZ0dZKTi+/o6XRpaH5/flNSStHWzfT0+w1BrdfU1GBf
XwpLn6GpuuPe32hqd+Dm68PmzBVTqcbu0HRyceDo4HSGlgNHoNvY4wNMrPe1G4uEggghZr+ysgtC
jeLs6O3s6fz1+4qNmsvMzfv7+yFSq6mVo/atBwpJrMWIIejl6xRVt1hJRwQDHytIkeagGCYlMv7/
+Bo3iRo0bjAmJSUdIWyBiMXAxNHT229dYO62AnVrd7C6r+7q7razuf/DFdvY005PT6urrSsxOcwy
Nn2UmFdQUxQKD//7/fD67Mrgzvr//0ROYtfPzIiGiW1lakI9PtXZ1TYuMWxgX/r5/QQQHfj++8/c
2hgRDv7594COgr+2tglWpYSEhY6JgxI7fLi4t7a8wzo2Munp69jX2Pv7+NikkNW4oeB7bszkxuJz
aN6EdfEjJM/UueVjWtLEq9W0ntuUg+evp/csMeiYJYmejxYbR+rs6uzs7cno0Il7e5OQkNjNtwoK
CsK7qO48QN/gw63Ptxc8nICHi8p+e6/Aq11oZmZmZvcDCf///8n01CH5BAAAAAAALAAAAADzAKoA
AAj/AP0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp09/vkiQ+Ee0qNGjSJMqXcq0qdOnUKNKnUq1qlWhSTJpNcF1ogkZVsOK
HUu2rNmzaEkIabAjU1eIy4ainUu3rt27eD8oasfW7UMTcvEKHky4cGFEOpAIaWvCIVjDkCNLniy1
CoAMfP0uXPaBsufPoCP3wDSoHeOFvkKrXs3arL5qmDIsbpwQcOvbuHMzNdCk2h8kDTQj7Ky7uPHW
OIYhGKBjdu3j0KN7RhRhwQEAChrQPphJuvfvhDUM/7s1IEPwhN3Bn91Gjmg59Ui95eanpwmW5pkS
7pD8XvU4K+J40884Uo0ThDisfdMPOLgBUl0P2bSTH0L7QSYgg6EF0Q855PQjhVQaIriagtvgJkAi
8PiGzQ76RSZgP/I5ZWB/cwkYxD/bLAgijE59E6NgJJqYiAXVALBii2d54404IiaV441PaVgiXTkW
sI0UC26jZZNLafijUuL0Ew5hQd4mgAYWXHckhVZ5882bUgQhZz90Qumkh1BJCZWSWoIjBYFLKUjn
oIN+45SXTVVJmDn9mENOAeawdmaaRrLIZlU5EqppP1wapaChUfYzJVPlaKjpmF1uWuihPDKVI6ht
Qv+VYzh0whrapNcpYOlBFVKVqap0jnoUllK8OQ6qSunZ1IubCmtUh/3IaUW0cgaBYXxKeuNltkq9
SpQ45nxTgJw0JuXmtOFEmlSpcxJagKRo5rqrQb1O9SuhQdBqxZdGmUpouUcpyxSzml57lKBKbsuv
UfduaifD/RgqKKHOGmXOtBTfqaqtoOGK3bwF1SuVOG9qSY6S/xSAp7mqfpisqEV5AzBRL1oRxDjj
0NlpUbQCy3FRDWv6cFHgRPzPxINWTFTOm76LVMNWfLPzZx7riiRZ8oWpo8ZCpzolOPl22ySjQwMN
bK3dnh1tUkEiHU4QM3uj8qBBSIFxe0jJOc434Vj/EfNqVYNMkMhWSVk0p0opKIWWVw6Yqjng9Axz
Uzn/7J6YPqddLN8Rv/k22zD7Cc7JS2HcjxVTlkOnwUlp2F7RC08W+NViSamh061v/U/OShPlL6GW
Bzx5UgXknDCMKKc9JaL/yAl670n1bAXeRKkcfFGfmko91fF+THtYGgqqLlJa0ygww3Nvynp8OjOl
oLTUWqu87606j1SZoU5/VNFl/6OkONtIX7BUM7tLjUVD+loKo5DVvOF963d0sgKWWqXAtbkvc3da
Xv36hz8Z6e8oqisb0jRlhZnJrntWM2DtBgWopBArZnTiF9R8xD8ZOe6CG5tfA2Nkv4M5sCngUJqN
/+6nqqjF7oSUSiGvyuKv7RlFa9eCFr9Ul7F/YOl6PGtUU0i0DSltSYfM66GnKBiWF/FrhHQaHwFR
KLiBEK4qpsIdUg7XpCexzwpgmxytoHc5Mj6vi6JinAlzpEEe9g9LR5wKrWT4pm9sg2QrAxwbv1e4
flhpKUWTo4LkSDT56KlDfqPcAHGoqv4Rkn6GzF0ipTKtVf5DdaGUZBLbKJA3UkVDJjRKOAxmPabo
KZNOwRgniQgsU04ujP1jnliGODBvhAMd55BBB0hAHM8UcIlkUSZUaKXGvMFMZevbH6GcuL9qTata
N7uTOeNnM1WSJUz9Iwrf6JEPKkRAAxrgBz80kP8IPSgBAV2oQgqqOZhr0ouJfmwKFcnZL1G9KJdF
URnGXMYqVwYNX+4cix2TMg56iKAYquBFM5ohjw2YVB7yaMYWWlACW9hBDYYgqF0MGjKsxVAqRWNg
7koUDp0iBVqRO13s2LVOdMLtaWrjII8AGJactfBZ/ciFKkxK1ZNWlaoo3QIu7MAEmc6FpoMjS4fi
mSqKvqxE4WrKBMVxuHBeVFMVexL8zKlU+YxjmFGhVTgVlIsNhIEXG+BFGEz617/yQrBW3YAyWrCP
X9wFrG4kC9mkAtSmnG8p0HIZurh2trges1Xg2CuPNBTOHtHJhCrLQmAHW9gwsNavq/1rSalqizf/
4KAukK0lWSonFUFNraF8LMoEpySoihH1d28jF/mkhsotwqxn4ODWUwTlU6KggwIbkMdgqcpa13p3
u4R1LWDl0YIi0CW3/rClVLgZFW9MC6/CC+4/oGWnzDKFaXWKijaf94/DYTRQdhtUOBFBge++FrZ+
/W5svVtVWzAjMGVBr3plRSeGJm51rJLvBHkp1LSd7sNP9WVCfTglyeVXKQSz4FEQYQsDu5jBCUaw
dwEL2A3gQg9eDYuEx4Kl6qJ4WvtiVQEa+SakikmcunvWe8OH4Yo6d0rkMJ2K2TeoDxoFERNYcHcP
HOOqCva1r93CBc6y47BAK8RMmSCaQbcpfrUV/ynTWl+UgxWinknBlfsl4qjEESe9MaVnBdjZB/gh
3he7NrzhBS9hY4zSDZSAzJNUIVXmBlEkA+gp/qVbfKxQXbsh5WJ0IpCXfoXFHT65KqE1IQmo4Ndm
JNjFiI7xYBGbXQWf1B5mKbNVsERWbxrtKe7t2v266Z71HQ5KiBKfZUc8RvlORRFZbgatwRxYwR42
vDU+7IFhvI9cRxqbVmFUaTkqJlc+kXFaqjSFg8DDVvFu2RaN7lyOEAfEMri7VG0GMuCBjFSowhX9
3u6hFx3YDZTCEBH+9kGr0o2Gh6PhEI+4xBtOrIlb/OIYz7jFpRCOb0B8Wh6neMgxDnKNm/zkFv/P
h8C5LOswFAMaZjACNIaAAUkgIw6yrupg5TFmsuh6KmoLutCHTvSiG/3oSC96Xw28AVsQIxVfLrjB
I9AKLjhDC2bAwDSaoWhFb2ACOZ7Kz6WS9LKb/exoT7vQrZCKRLjapMfAgiUkIYJrHJoXJSUvIO5A
BiSYgQUTEPiiD60KBvhc4TWtCjcWz/jGO/7xkI+85CdP+cpb/vKYz/zjQ2AEERScH+xoAAYw4AUx
HGO7zbiGLRLRBD40QAvaKAZ3uwxbMBx+lpSEj+7D4o5/MCCwzYAHMD4xiNFzABohQMY7vCAMDpgC
E7EYgBdqcQ2TIhawM3b07eWV+917vypZnkD/I/qQgT58wgxC4EDWMWCGShwAEFtIhR6m4YVjwPba
sHWtPLZwW7GM/fsAOBVfsAGE0AeEgAuEAAsHUAgKgA1X4AW7sAUbsAWutgtUwArFIF4mpQrwQAVZ
MF7ygAhj8X8BWIJOgQjHsAsIUAy4sAulAAh9sANIMACwkIIWgAk6kAiAgAXOQAeqcGjNsAANgAcY
8A6D1QLb5z2SZoJMyBQIkAUTIADXcQvDcAQKgAeDMAhGgAk94AO3gAUAoH6DAA+zdQ1CoAbw0Atk
kAobQANJqEQL14RyuBS+4ANZYAERIAB5eAt9gA14YAZekAfXcA17oAdkIASDwAF4oFobkAcY/xAB
twAMg5CB/ed/iBdWc5iJSOELXkAFpoAAzbAHtoAPfYAEJrAAFoAF19AMd4AJSIABlTB60MCGVFAL
JbAPAzAE16AECYd7S6iJcygDXrAAplAN1/AOkIAJO6AACrAcGKABxXAHfIAEr4gEfygMy9EDGuAD
SCAJbuBYb0hL6QWM5PgPMuADB2AMVHCBVHAFOvB6iAgP8IAA16EFlYAH1CgLLOAMO9ADt5AJsuAK
JcAMvch9v1iOJvgB9NgAACAMwgANjXAFlYAEDpgNeNAAQlAJDTCRQoAHCoABOmACSYAExiAApbAO
NSCCI3iJkYWQmkiPOyALvcACfyAEWlCTSP+gAFfQkZWQkUhQCVdgjxzQANUwAPAgAD8AAiAgCm8Q
jt3nkgHIAD4gC5/gd1eACViABYMgBFRpjT8pBEIgkTk5kdUwAcfACi8QCaiABsogAbrQBgNVFSQI
lQGYAnrQCibwipWAg0hwBbIgBJZgBldwBQ3YAAqABDtgmP6QAWLgBZYwCqeACiiABmgwmcGgDmHH
FHNJlwAYCwvABcCABRlgCcnQC1eQDNggmrLRkxI5mJXAARlwCcQoCJEQDdQAAqfABtQQAJSpC5mp
FJvJmd5HHQCQCVgwDAOQDawADQcAD9KABSawk9YYlFqwA74gB3pgCo3wAwEACgEQCXBQB4H/wANz
EAAg0AQQ5hTBKZy7Zw/4sJMHkAjEgAAWAAgCsAD+wIxh2QCCKQQmoAv48AemIAgBoAmBQAABEJ6d
kAOgEAggAASCIBXryZ66pwfVYApXMAtZsAsTwAvHUA3+0AA7+XoZkJ/wIAc6EAUZ8AMEoAlp8J3h
eQg5wAagMAkoUAZVEBUTSqHqYQiAUAsmsAM+sAvFMAER8I7tIASHCQz+cJwL4ASmgAFNEACHMAVp
AALroAnimQM50Ak8QA0oUAO/aRQ7yqPgcQGJkJhXkA1/AAAAwBbtcAUrcoZ6cAtXgAFRYARlMAmg
AAp+AAInwAOgwAgz0AlT4Ag5EAlo0HPq/8mSumWmTSgAPrAMOuADTeAD1dAAGcAOV2ACOqAHGgCd
ZsABHCAH1OAHh8ADPKAMG4ACgQAKM1AHaeAIhzAHJ4AGlaiZjjqOcwEDEAADRQEB/QcBRLAUBtAC
NlCsSPFoxqqsSEEEEPAPEsAE0MoUwnoUBuCsYsEEW+CGeGEIbnAEXMAMPZABV8AYDeADiYAASWAC
YBkFrVAGBNAJtRoJzUABvBAJhzADacADdeClIKAMNfAUZSoVRCAPztoCNGAAvkoEMGAASXGsEMCs
RgEDW8AUTGADRLECR1Gt01qtRnGtRNECEGsUGWsVECAPbnBbMCAPFPsPOBCtc2EAxYAJXP/gC8vg
BCyAAJdQDM3AD8wADEnQAUlgCYsQAEuQBnMAAhvwAGfwALyAAtTABnXgCGnABjwQsIy6FAXLFAcr
DzZAAwfrrClbAhBArDTgrf+QsTbQtlsQtkixAm6AsRr7D/KQq9AKAR8rs0VBsn1bskVxslXBtrdl
ABLgt0RxrHXxDKWwD3ZACMGACxPwg2GgDLigAdXABVzACkAwCf86BxtwDZ4ABZ6wBhtwAqfgB3XA
Bn4QDQFwAsXQe7rqi+AmFl+LUiXQAhxbFDRQAm5ArL8brCg1vCglAYFLvCjFBEbxtSUQthLAt/8A
rS2AUi0Avf+AuNcLuEQhuEhhAMiLUtb/WxSGSwSVqLj/AAE2gLBloQ9hIArKIAoosA6r8AOBJQ+E
oAPDkAgGiAKOEA2BgAJhMAJjkAAq4AIjsAaiEAmdwAadALCioK1J0bVPobdJAQNmSwTYexQXi602
0AJu0LY2kKsGYANu0LxiO7fbKwG+27w2YL3Y2wK5urZ1mxQ0AMK5awPKSxQSALbTO7x8q7g77LLA
ShZdELUPGgnUUAar4AqAtQ+yYAm3UAwgwAOd4AgBIAoPkA6ckAAV8AqkSwFxEAA5EKugcAon0AII
x7W7OmFVYbhK8bxE8LL/QAPJC8NuoL3XO8RKIbg4sMHni1JEYAPZ6sJM4LI28LZ6LMNO/9HHuxus
bVvDHYzD4ouERKC268sLATAHqBAJSysHQ+BqzVACPVAIQCDGaUAAJ9AMI0ALFdDFZ1ABY+ACD3AC
1FDFM5ADqKAMMTC7Blm7ZYEDM1wUwByzEPwPb+u7EmAAW5DIfdwUTIDC57u80SrIINu3MJC+w9vI
itwUcbwUTPCwxmsU5jsXX4ACkXAPAVCgAfADu/BXJoULPwAE6BwJkbABFHAGrwDLsKwC/JwOa7AO
OVAHSwCwaGB4wLnGgwEB3ou8gHuxMCABv+vHRGHBzhzOz9q2JZCtEv0PGd23SMEEFr0UwXsUKauw
RGC42owDSEgXq0DPXwoCBAAHAcCqVf91AqhAACAQv2HwAI9wBgkwwC7ACfw8BlB7D53ACI7gB/dw
AtCMFBJcFWDrtsV8sYZLA91K0tP7aAYgx2sb0ssbxMObyMns0UcB0k2BA3f70Y9crMiqrSuNFoYA
BDg9CTidoJPAlgkmCusQCeYJBCcQBp7wCAScAKTACWdwBmNQwHEQCUsQDYR6DyCwqAdNu3F4FymL
Ay1bzMhKwimrzXMsDzsMAVsgD0gRxFuQw0VRrQp9sNo81iP70V790VwdsvJAAyyF2tdLF3IAAjmA
AqmLBgkaCKcAqAl2AkiMCku5Bp7ACa3Mz6383KRAASjQCR4wBXXgAdTQlikQwQg9GC3/4Kv7F8Po
m6yFvKzTTF6J/MfI2gL8J83SSq1bAL2undtlHdskHczC+7YSsAWjnatvbRYfAATU4AGRcAqToJS6
idzr4FrKILXUEAkocAJrcAZb/NwWXgEqMMudsARsMAWdMAdoUArWwN2UnXiCgcNusMPFvLY0kLK4
ndvHmsFE0a3G28fQK9pE8LFu0NTz/d8Tbd9G0eJJwbZuwAQtwFJH4eNj8QGXgAI8wAjpjNN8/Z2R
sA7ZFQkEcAgBYM6icM8VfuGtPAYjIAp+EAiTYN13jQZHQOK9XNl34QYrIA8QcOQmWwLUWwISENIP
/Q9uwN5IAQMkG85pK7523ue/SwMh/93j3QvkRZGsTIHDK2XJ9G0WfFDKgXDKSHwK9AwC6bwO8iAK
YswGEM6bE+7czV0BXMzPnqAKHhANPDAFU8ADaIALKnkUT10Vz+sG0LoFjSzaNgADgN7HzpqthWzB
MVzJbhy9M5yyKVu81qvo2DrbRmEDnj3RoC3ILSABEKzkYZEEAoACkxANaXDgAXAPBEAAk+AIHnAK
aHACAZAGDrAO6wCmpU4KF87FXPwEpeABgRAIHjADo3ACL14Ut04V2U4ECE/BFcutxZrnRxG8khyy
Ch3ORADNz1ysOMwEzw64Sj7OSuHoSDGx6F0Cp53kZiEDw+DuDgAK9wDlWF7mDhANHv/wpeacA/GO
BoC6Bi5QwGCO4a8wAiDgAUdtpQEABGpc4pgoGPyNAwjfx5VYwnNOBExQAp4t48F60hTf1MT6Dxm/
8WStwU0h5EiB4vIw9XJu8sssFiSABfJ+CIxQB2X+4JEQCDnA4dWdtb6dA0oZ4cr95WBOCg8AAn7g
B4zACEud3mTa3WNx0kthwRyL8NFbidlOrCWA1jFM2kpBrHt+vsG89YKs8Ucx3/bd3udb7RDQ1I2e
sfKwAqON30jI3wMPFSTgBMWwDqgQCNcNB4zAA5EAAtQwo0Y9BQ7wugFQB995AqLQDE/g9xaeAE8Q
xkpt5gEwsEff5iYuFjscwkkR58r/C/lGYePCarxwnuR4HKwQILhiTxRbn+dnP+2Aa99U/w8tO/AW
G8Nz/MzL3LxybLyADhDy3PwjWNDgwYIfKAVDcSqQoyWdJgViEwBEpHuMHPjxEwjViUg5lqCII2rL
k1cJVCSoQMqFC06PHoRZFwmOh3soGCA0KECDhQMAFOzwV9So0R08lS79B2GLPKjyIBi08VSCGxgH
V7ghYuOfgS0QaBy00WIqwhVmvf4rscIghBJQS0A4W9CGAYIGJPCkgbXFQJ5mEUJgIqEEWxhbcBjc
S9CNvLVMDX5Q9GMdiDmdOk3p5MhDmjmRUAQQ6YfNEmooUBBghOKEyRFjErgY8+TB/+0RI9Zcs1Om
IarISn0CFUr06NGkkpUX7GrDBhODW2BAiAqVCEG6TKK2gNG4oIG4UKEXxAH1rOK3hqEzqUvwbl7v
BrXLa4GXJ5Etg6FKwJGfK2ODDBiPhA5kkIEEpUg4AhdRApgjGg84WmKJHE6JZB1RTjhlCjY6CySS
E1CZRLQTNniAlgReOYOCTYyIR4QsYMmCCmt+EGWDxZgaLqihjkNuOSCXOqwgCJyzj0gjlzLAuRyZ
G4sgt6ga7x/2lsLhOp6KbDJLhJhgkomBiGiPJ8p8kCYRPaS5JYUPEiKhCSA0nCOQKTjLgY05QHht
gw1EQeOeJRihkAAU0IgkEhDWCf+DAihUqMCFEegg44ZaPslkiHeIASQOwHT8iUfjfPQnuSBLNfXU
IGE40oCsUHXV1A9kMKGJVKSBJwJAiplAjyM6oAQLQk44gZpDcuikDkcY4eEUNDbYAgx99NnD0Icc
YMODSERZRzU0RFnjiQoSGMOFJyjQYxknCsGABS9KCUMJ5XYsTtSiSH31Xnzz1Xdfgj6opoc/BLgG
ABPM0EYLHyZQZQJbjhEFMx4YmSKNTgKZ5CNRIkCkoBQIaTCQe9iYYZLXVENBlDAegEKlR2yrxYkb
OMADD0s0kMeQeD+dl157+fX5Z6D5/UCDLSbI9ZoJ+KlmB20aGMQLAQC5BYhTNPH/wJFO/CCAhzJO
kA6hX645gTQPGJkkAFGUuWgdZdbwhBZIRYgnm2yiEOYKSxqZYEjJ5O2R56ADF3zwIBloRgMddLgC
EwQi8KISyHeIggUqZAkmgDRm8GPie7KVAGeEPuihmRM8mMJiD9j+rdkRHqBAhHouWCQDHzYRwhc6
QNqpb53/FrVnwoMXPvBY4vijFxN2MKEXM3qZGQM8GlDkGWZiCACOGcxGBUMwmCKBjgzvgSNQVExe
Zx1eeBFFgHq8eKMKJTR4wwcOfkABhB829pQ4330EPl8DtGB4aBngz36xiyzAAwEIuAUVBnAFPFwB
CVfAAAd80IMXRGIUOaCGniRg/w/ldMAH6zgBAXJwCDjc4wTK2AcsSrEBQlABEBZwgiAQQAUNYAEa
DQnACZrAO/6Fyn9ACyBPyvIcpkAASwh5Eg7GVJD/FHBfMqDCBhLBwFvMYhBmEIIzkNAAPLBgHvNo
xTrKd4IaFCFIH4gFEHhIANFI4BZeEEMqQjALQtTADk1gxS6akAFckIYaaIgPT/wmxOP8D19FRIgb
4pKfpShRKfLIC98Owh0p8usO12AHMJYhC1kM4A9CMAMSkGAGZ3ghEQuYQA2UsLtSkQABpQgRKsoQ
Az2IIQQ+EIEragACNKAhBkDYQAzKAAIeeEAThQKdcHqHyB/pywbV2YJzWmWQ8v/wRAKQKYEEmHRJ
+PCkPFvK5L1wUIxE+EAOFrDAH52WgeWxQgMgxJcWQlEKazCjEL1AQCioQA4I2CISAYhGByOBChAE
gABLqMMSUCGKIxnymfQa1b685JyqWJMnlNRPdeQR0X8I8CuFJAgMRFpOfX1hA7cAQDaw8YkmDAMJ
/lDAAiCgP3zJgA64EEQ1rCGIYABhFTVYRwAixghHsCEHPOgEKDqxhBl0ghqiuKZEg0hRReLrpAhh
pFIkGZhwIoQInUJpvpjQBDw04gALgAcm/NEDdcAyXyQYAi9OAARUiCYAqAjAKQhADQL4wQNRZcMU
OOIAR0zhFCcA6UEOidWgbVX/KyR9yxKJ5FHrHIQGTyzrvb4gAAR8IhlYiCvQvAASApwmEIGwlgdG
FAA2pMEBrPUAHNgwkU6okJyOnSjg+AUD+kj2LWNhQlWJZFmCeKmazmnBewzihih1dl+IUAICLrDb
fXVBGaRhRCB48Nc5WIgADlgCGxjBiKxdzQESmwQKgAgqyPLLkS0QbkE225T2TNOR3nyiSJcUmMZK
V8BM+QUuInGa8hIgAAEY6EIndF4/TChZEsvTe3f2O59Jhwj1JUJUbABd+UxzOwgRKQyCQ5D+DFjF
yyGBAFCAYDYoWK8TKi95/UDeZE1hBnMAgoX7l8gMf0W45dnmY+SBXOxwli2L//ESQoArlRVHmUzS
KJ3ETOOAAKzGAXVig43Xy4jNdWIOP/AxNJHCL0YKFwISgMFhwCKP3dJFKRLAS5MP0uHmSlnPBjmA
KlLrGTbwgBoDpROH1usBNrBWsFJdRJnjq68i4kC4NlgBBACzBRrEWcl0ptITadCCwuxZ1LUoRSTo
5IGy8YDQhu1yIBDtgI3cOABq3B98fbsvOJsUIWx2w1QkfRAchAfU2qzzE6HbHVHvWRGheLGrdfza
a82gy57xAKw5MgkQ5Oyqt9aXWoRL56+F+i3VDM+UCsLmpbQAB+AJTH2TPbwOuAIF1JDYDKbgAQZf
qyOIRbW1b0xmR3M7XzSAiv9w3eAGSBLhSVCcCl0kQFJKKyXFjHSDfdKyhei+u4AkiECDDOsHaecb
Dhwy7xIE64gZLCEASu5JbzHMLxzYYMNMlMeT7ssY6Egy4wShwYkLAgPAUNIAH02ynDUuxQ+EQBT0
ZkOHGHGoe8zAAxQ5jR86YToegECuztz2y33G7oMsKUdYOQiIaYDk5ArkPk9qARGuQiQmVPromfTB
BgLAiEB3wgEXKWx5m66Rq3OwBst5rMD1BXTJoMcgNCgBeHZOFaic+Ow8Fw+RViCmuUsxFnbHu3nh
CIJ7TCFQfXeAB3IwihNsneu29jq/xMIUsAcoKgH+uQ3GRINWxdyyRZIAyzP/HzQENEhQHSIUbJew
3mstgbWdGzzhXT7En0Hg8dhEu4l976qhE/33wvtAFQMg+sJm2fizRfV5c4A21a/+wtDfPqqM3n7C
kUDpAUjWabIc2OO7umwe4AEKmu/8rmM/+BtAKZOBPLC7OsC7JRAN/Osuw5IYQpk+9fuxaCJAC1Sx
QSiGpQuEJTiEJSCUSCAAAtAxqduM/oMXICm81rtAFkSpukKBEBTBe7AQUZg3ariHSTgFaqBBCbQq
1hPAFgzCAqoCXggDVMAY1RAF9cmQGiShFVIFdQgSFQTCfLk+g1A4cso05TC3AEE7guC0+uAJGPDC
g+BC7LAPHJi8LjHDsvqA/2tQhWHAh1TgE3lohj3YA34YhpLokw0ABElgwwk0s3r5GXf7irpwO+0r
iP0wroOQALSzs51bgSMLqQBTOOXoj8YqgVYZOp9rCrISsGkIAwG4hGIIg2ZwFjXQAA3wgmMIAz7Z
AARghy+QwucDMp8pRHH7h7JIROwQMdrTjumzMzgjj78gCHXLEit0isYKw6+ADDG0JAEbgA3AhUbY
hDCQhw1IhVjYIzN4B1eUB2XogiOgJwD8QVvkF1z0DhsogWPkkjkjqQ6ThxKwARroPSIpAUmLPOei
knX0JnqUuLAoQ7lwDghogYXDpmGUD++AAUYUnBRIBXloAjoIA17YgBaYBf9+aAITgARXdBZmaAPs
CsRH25d0tAsu7Kql0A4zXBJHosexKggmwIsiaa59pA6PYkOnIKclgQyCZCKMwiSFJJKDJJwP2AN5
iKE53IBr6IE9EAAsyAI+EYViEAIlwCltM8cKJMmU7L3qiA+UfMeUXIsUk4/FoCxdBEQUC0iegKRJ
8qitQjYogUbCmQZ5sAAkCAU+kQAsKAYBgAaodEVASILuocUAPEetVIrCuKhuag+9kIyhQ0swIZJL
mgqz5LSlwA/s+krNsj38CruTGsvh0YcNEAB4SAVXrAEsOIY36IV3eMUISIJnKJUpNEx94SieyEWZ
CzuztIvdpBKz7LB5dDf/fGQKweAJdjOxJLmPE0PJLaC9oOEDpfSBUtyAfcCCZtgHVoDKDVCGJigE
MvTB9aPNfLFNJ1NH5ILLpcA4psjFS3qKrgSnpQCukES2bYKKhvRNYNsqEBueG1CFPdCGROATOeiB
MCiBd4DI7cQETEBL8KTAM/MZ8tRNu0AuMMGBbWJG8mDLOYOKLTC3DsOoD5sL+FSKrUjJgSAMxxQu
Db054emAPSgG6eSTNmiCMHiDT8BLi6QENaC1FKzFrKxNJTHPMnQkyMizANFQ/WiuFlC8prDH5Dqx
YGsz+gCpl0TMTlQK4SLPrhigDkiELdCDY7DINriDDdCDISiGvEyCN0i//6WYzR/NFyQNEO/4Kpi0
TypR0fv8B0zbi/5oD8x7Us98irIYysS4zKG0kgjVU4NAz+AhgWloASGYhg04BmZogg2QAGKoyA0I
hiTQg2Yqx/B8U60K0uMSyCjJprK7UpNqzH+ggYMUE6g4uBIwN+AKQ7dDiC3wwj9VDrggsSMJtgEi
AS8oAR3gyBaghAjgBSwQBlXYgDBYBUpYBau8ylB9UHQMSb3IRygLkPaI0xVg0iukAVbdUuYQC+dw
JHNjgubMC+GqR6+ywi98osYziEIEGhIggziIgF3YgBLog3eQByXwgWaNyBu40jb1UWslSdrTC6eo
im2dpMDgLLoYV7LCPP+3kDvi5Cp5aEg6RRUJMLf4oC/BIYEBSAVWsIANKIZkSIQWiIUQ+MYjiIV9
MBU3TVh9QTfjlID7YrxCBM0rrC8lotgrhACwuBLf00xd7ETpYwr+YIqI44mL68Gc8oJUGIAFuFR/
nQAtkIQ4sEhFAAMUJEystNl82U8mOEi9yE2Z60EikMt/6I/HUyK4LJKhDSki2FWodVvt2K3nWNXA
cFsiUTK6eD+f+QBTWIBmKIYwFQBsIIYydQVXlAB2sIGQPNjCFNV7cdW3LU740Fw3YNASOFTsIKns
WAsW/QfMczu8RYh/1KYnsgFVoQ9GBM6QrNLBiDt4NZVfUAM92IJmAIT/CdgAWwAGWNgDLAiF0yzY
U6nZQfSZtACPdjy3ggSLPJ0m2isP40oLumWLjMM8C+1YgQTEb20kvDCpmkvShgQuib283AUSdwCE
ZlCFp+CFXSgGebCFPgCEROAAV9gAeXiGP/hOkTQ8fOmPymtEAwbXt5jEpeBMhNxWcL3bUr3NLfjE
S+LCpnUMBpaPFpCH6YMAjrUBJ9UXd0gFVbiDHuhdAZgFDZCGDAAGDbAFPehaZWgDBJhFmkXY5vUZ
L8lTE0NLImDQr5jdhds5CcYOCVwzyWACcto5VlEKGhDisIMK5zwVhWGFHgCEFtgAWDiAYdADC0iE
YmgCC+jaY02EPLXc/7HdYSEEElX5PcLFly7YAHUYgAlwRVsYADTdAFUQAH7QATI4RVugBDfgUbGt
VjZuY0X+GRLQ4gxAgkE4BlUYBGnAxjBQBR/Qg1uwgFNMhBtoATatNUSuqEUuZZ+pBHQyBVMwg1RI
BGnERmcNgxYohqfYgBxqAXdYXh0mZVPuZXzhg2JQg0GohUTghQXY11PcgGT2Xz5Rgzcw2KVABOYd
lTbxZWtGlSpoAWEgAwFIhTz4gzyIADp8xVfcAkywAEMGEgaQF2wQRGq+Zng2FSa4g1rwAi+oBSo4
ADJwlmOwBQFIBH7QgCvCg/ZdVHZ25x3ogHhe6CBBBANQgj1QBUiABP+nHAAtUAAdYAcAGIBbeIZp
BZJn+Gd4OIA/cNB60QKGTulUcaRr0AMNAAQ/5gc9UIcL+OjlkGaRroY/aGesaocUUGmgvmkDKAIc
wAGbNpUVsAVAiIAF6IFsYAd3zgQh0IGjDmqr/hkGsAWl1oMmwAIdEIJMoKhMaIAMwIRPvWq0RjMB
mACfGAYEwIQMaICwphcTaAAFAIBqqOK03usgYYIJYJilXoBqEIoGMAGKSp6pHgAEUAKi5mvHLpwv
oIG/VmoNcGuvFgLlOeyxvutqaAJpeOld0Oq/Hm3SLm3TPm3UTm3VXm3Wbm3Xfm3Yjm3Znm3atoVd
AIQWbgKd/qJMMOz/w94BISjrzh4GgIZpAThu5E5u5V5u5m5u535u6I5u6Z5u6q5u675u7L5uQAAE
fkiEYWiCA4BrzPZtzQZuHcCEavABeJCGCEgEVXxv+I5v+Z5v+q5v+75v/M5v/d5v/u5v//7v/06E
CLAVH6gGTNCBdtiB3qYoozCBsW6HDAAALDgAH1iABWAnDM9wDd9wDu9wD/9wEA9xER9xEi9xEz9x
FD9xeICHBUAANcACAMiAdpBr8mZwf3Bw4EaC8x6AHqiGA/hxIA9yIR9yIi9yIz9yJE9yJV9yJm9y
J39yKH/yfxmAA0cCzF5wGz8KHG+AdtBxHfgDAAhzMR9zMi9zMz9zgDRPczVfczZvczd/cziPczmP
c7p55BlX8BrP8qIwgS2/gnZgB2xQgEBXAEIvdEM/dERPdEVfdEZvdEd/dEiPdEmfdEqv9EYPdGxg
ByEQggbA8zzX8z3n80wY9R0odVM/dVRPdVVfdVZvdVd/dViPdVmfdVqvdVu/9VHvbT638YAAADs=

------=_NextPart_000_0027_01C6E7CD.430DD610--




From ipfix-bounces@ietf.org Wed Oct 11 09:10:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXdpM-0005Jf-VZ; Wed, 11 Oct 2006 09:08:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdpL-0005Gc-Ae
	for ipfix@ietf.org; Wed, 11 Oct 2006 09:08:51 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXdpK-0005JW-1q
	for ipfix@ietf.org; Wed, 11 Oct 2006 09:08:51 -0400
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
	k9BD8nP26937
	for ; Wed, 11 Oct 2006 15:08:49 +0200 (CEST)
Received: from [10.61.65.22] (ams3-vpn-dhcp278.cisco.com [10.61.65.22])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9BD8jP20944
	for ; Wed, 11 Oct 2006 15:08:45 +0200 (CEST)
Message-ID: <452CECC2.5080703@cisco.com>
Date: Wed, 11 Oct 2006 15:08:18 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ipfix@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9
Subject: [IPFIX] observation domain, template, and session: compromise
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0102332178=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0102332178==
Content-Type: multipart/alternative;
	boundary="------------060701070108020201060203"

This is a multi-part message in MIME format.
--------------060701070108020201060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Trying to address the concerns posted on the mailing recently regarding 
"observation domain, template, and session", Andrew, Paul, and I sat 
down and worked out a compromise. We're proposing to make template IDs 
unique per (Observation Domain ID, Session) pair. And NOT to scope the 
Observation Domain to the communication session between the Exporting 
Process and Collecting Process (as proposed by Andrew initially)
I think that this compromise will make everybody happy as this solution 
is mainly a clarification, as opposed to a protocol design change.

Problem Statement.
If I read the protocol draft now, one interpretation could be: as I see 
that the Template Ids are unique per Observation Domain, and that the 
Observation Domain Id are RECOMMENDED to be unique per IPFIX Device, 
this implies that the several Exporting Processes of the same IPFIX 
Device must synchronize the assignments of their Template Ids (to make 
sure that the Template Id are unique per Observation Domain). This might 
prove difficult/impossible in some cases.
Instead of imposing this, the other solution is to make the template IDs 
unique per (Observation Domain ID, Session) pair.
This makes sense as, logically, the template IDs have only a local 
significance between E.P. and C.P.
Note: I brought up the issue of load-balancing or backup where it would 
be nice to have the same template IDs between two connections. The 
solution in this case is to use a single E.P. when load-balancing or 
backup is required.

Please acknowledge that this compromise is fine with you.

Note: 3 minor changes are required in the information elements 
definitions in [IPFIX-INFO]

Regards, Andrew, Paul, and Benoit.

See below for the proposed changes.

_[IPFIX-PROTO]
__
_NEW:_
_

Transport Session
In SCTP, the transport session is known as the SCTP association, which 
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
transport session is known as the TCP connection, which is uniquely 
identified by the combination of IP addresses and TCP ports used; In 
UDP, the transport session is known as the UDP session, which is 
uniquely identified by the combination of IP addresses and UDP ports used.



OLD
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Observation
      Domain that generated the Template ID.  Template IDs 0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.


NEW:
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Transport Session and
     Observation Domain that generated the Template ID.  Template IDs 
0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.

OLD (Section 4.4)
     templateId              An identifier of a Template that
                             locally unique to the Exporting
                             Process.  This Information
                             Element MUST be defined as a Scope
                             Field.
NEW
     templateId              An identifier of a Template. This Information
                                   Element MUST be defined as a Scope
                                   Field.

Section 3.1
OLD
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique to 
the Exporting Process.  The Exporting Process uses the Observation 
Domain ID to uniquely identify to the Collecting Process the Observation 
Domain that metered the Flows.  It is RECOMMENDED that this identifier 
is also unique per IPFIX Device.  Collecting Processes SHOULD use the 
combination of the Exporter (exporterIPv4Address, exporterIPv6Address, 
or exportingProcessId) and the Observation Domain ID field to separate 
different export streams originating from the same Exporting Process.  
The Observation Domain ID SHOULD be 0 when no specific Observation 
Domain ID is relevant for the entire IPFIX Message.  For example, when 
exporting the Exporting Process Statistics, or in case of hierarchy of 
Collector when aggregated data records are exported.

NEW
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique to 
the Exporting Process.  The Exporting Process uses the Observation 
Domain ID to uniquely identify to the Collecting Process the Observation 
Domain that metered the Flows.  It is RECOMMENDED that this identifier 
is also unique per IPFIX Device.  Collecting Processes SHOULD use the 
Transport Session and the Observation Domain ID field to separate 
different export streams originating from the same Exporting Process.  
The Observation Domain ID SHOULD be 0 when no specific Observation 
Domain ID is relevant for the entire IPFIX Message.  For example, when 
exporting the Exporting Process Statistics, or in case of hierarchy of 
Collector when aggregated data records are exported.

Section 8, Template Management
OLD
The Exporting Process assigns and maintains the Template IDs for the 
Exporter's Observation Domains. A newly created Template Record is 
assigned an unused Template ID by the Exporting Process.

NEW
The Exporting Process assigns and maintains the Template IDs per SCTP 
association for the Exporter's Observation Domains.  A newly created 
Template Record is assigned an unused Template ID by the Exporting Process.

OLD
A Template ID MUST be unique per Observation Domain. Different 
Observation Domains from the same Exporter may use the same Template ID 
value to refer to different Templates.

NEW
Different Observation Domains from the same SCTP association may use the 
same Template ID value to refer to different Templates.

OLD
When the Exporting Process restarts, due to the SCTP association 
shutdown, all Template assignments are lost and Template IDs MUST be 
re-assigned.

NEW
When the SCTP association shuts down or the Exporting Process restarts, 
all Template assignments are lost and Template IDs MUST be re-assigned.

Section 9, Collecting Process's side
OLD
Template IDs are unique per IPFIX Device and per Observation Domain.  If 
the Collecting Process receives a Template which has already been 
received but which has not previously been withdrawn (i.e. a Template 
Record from the same Exporter Observation Domain with the same Template 
ID), then the Collecting Process MUST shutdown the association.


NEW
Template IDs are unique per SCTP association and per Observation 
Domain.  If the Collecting Process receives a Template which has already 
been received but which has not previously been withdrawn (i.e. a 
Template Record from the same Exporter Observation Domain with the same 
Template ID received on the SCTP association), then the Collecting 
Process MUST shutdown the association.

OLD

If a Collecting Process receives a Template Withdraw Message, the 
Collecting Process MUST delete the corresponding Template Records 
associated with the specific Exporter and specific Observation Domain, 
and stop decoding IPFIX Messages that use the withdrawn Templates.
 
If the Collecting Process receives a Template Withdraw message for a 
Template Record it has not received before, it MUST reset the SCTP 
association, discard the IPFIX Message, and SHOULD log the error as it 
does for malformed IPFIX Messages. 
 
A Collecting Process that receives IPFIX Messages from several 
Observation Domains from the same Exporter MUST be aware that the 
uniqueness of the Template ID is not guaranteed across Observation Domains.

NEW
If a Collecting Process receives a Template Withdraw Message, the 
Collecting Process MUST delete the corresponding Template Records 
associated with the specific SCTP association and specific Observation 
Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
I
f the Collecting Process receives a Template Withdraw message for a 
Template Record it has not received before on this SCTP assocation, it 
MUST reset the SCTP association, discard the IPFIX Message, and SHOULD 
log the error as it does for malformed IPFIX Messages. 
 
A Collecting Process that receives IPFIX Messages from several 
Observation Domains on the same Transport Session MUST be aware that the 
uniqueness of the Template ID is not guaranteed across Observation Domains.

10.3.7 Collecting Process
OLD
At any given time the Collecting Process SHOULD maintain the following 
for all the current Template Records and Options Template Records: 
.

NEW
Template IDs are unique per UDP session and per Observation Domain.  At 
any given time the Collecting Process SHOULD maintain the following for 
all the current Template Records and Options Template Records: .


10.4.2.2 Template Management

Template IDs are unique per TCP connection and per Observation Domain.  
A Collecting Process MUST record all Template and Options Template 
Records for the duration of the connection, as an Exporting Process is 
not required to re-export Template Records.
 

_[IPFIX-INFO]_

NEW

Transport Session
In SCTP, the transport session is known as the SCTP association, which 
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
transport session is known as the TCP connection, which is uniquely 
identified by the combination of IP addresses and TCP ports used; In 
UDP, the transport session is known as the UDP session, which is 
uniquely identified by the combination of IP addresses and UDP ports used.

OLD
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain.

NEW
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain and the Transport Session.

OLD
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

NEW
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain and the Transport Session.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

OLD
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain.  Typically, this Information Element is used
      to link to information reported in separate records.

NEW:
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain and Transport Session.  Typically, this Information Element is used
      to link to information reported in separate records.



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




  


Dear all,



Trying to address the concerns posted on the mailing recently regarding
"observation domain, template, and session", Andrew, Paul, and I sat
down and worked out a compromise. We're
proposing to make template IDs unique per (Observation Domain ID,
Session) pair. And NOT to scope the Observation Domain to the
communication session between the
Exporting Process and Collecting Process (as proposed by Andrew
initially)

I think that this compromise will make everybody happy as this solution
is mainly a clarification,
as opposed to a protocol design change.




Problem Statement.

If I read the protocol draft now, one interpretation could be: as I see
that the Template Ids are unique
per Observation Domain, and that the Observation Domain Id are
RECOMMENDED to
be unique per IPFIX Device, this implies that the several Exporting
Processes of the same IPFIX Device must synchronize the assignments of
their
Template Ids (to make sure that the Template Id are unique per
Observation Domain). This might prove difficult/impossible in some
cases.

Instead of imposing this, the other solution is to make the template
IDs unique per (Observation Domain ID,
Session) pair.

This makes sense as, logically, the template IDs have only a local
significance between E.P. and C.P.

Note: I brought up the issue of load-balancing or backup where it would
be nice to have the same template IDs between two connections. The
solution in this case is to use a single E.P. when load-balancing or
backup is required.



Please acknowledge that this compromise is fine with you.



Note: 3 minor changes are required in the information elements
definitions in [IPFIX-INFO]



Regards, Andrew, Paul, and Benoit.



See below for the proposed changes.



[IPFIX-PROTO]



NEW:



Transport
Session

In SCTP, the transport
session is known as the SCTP association, which is uniquely identified
by the
SCTP endpoints [RFC2960]; in TCP, the transport session is known as the
TCP
connection, which is uniquely identified by the combination of IP
addresses and
TCP ports used; In UDP, the transport session is known as the UDP
session,
which is uniquely identified by the combination of IP addresses and UDP
ports
used.





OLD

Template
ID


      Each of the newly
generated Template Records is given a unique 

      Template ID.  This
uniqueness is local to the Observation 

      Domain
that generated the Template ID.  Template IDs
0-255 are 

      reserved for Template Sets, Options
Template Sets, and other 

      reserved Sets yet to be created.  Template IDs of Data Sets 

      are numbered from 256 to 65535.  There are no constraints 


      regarding the order of the
Template ID
allocation.





NEW:

Template
ID


      Each of the newly
generated Template Records is given a unique 

      Template ID.  This
uniqueness is local to the Transport Session
and 

     Observation Domain that generated the Template ID. 
Template IDs 0-255 are 

      reserved for Template Sets, Options
Template Sets, and other 

      reserved Sets yet to be
created.  Template IDs of Data Sets 

      are numbered from 256 to 65535.  There are no constraints 


      regarding the order of the
Template ID
allocation. 



OLD (Section 4.4)

    
templateId              An
identifier of a Template that 

                             locally
unique to
the Exporting 

                             Process.  This Information 

                             Element MUST
be defined as a Scope

                             Field.

NEW

    
templateId              An
identifier of a Template. This Information 

                                   Element MUST
be defined as a Scope

                               
   Field.



Section 3.1

OLD

Observation Domain
ID


A 32-bit identifier of the Observation Domain
that is locally unique to the Exporting Process.  The
Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain
that metered the Flows.  It is
RECOMMENDED that this identifier is also unique per IPFIX Device.  Collecting Processes SHOULD use the combination
of the Exporter (exporterIPv4Address, exporterIPv6Address, or
exportingProcessId) and the Observation Domain ID field to separate
different
export streams originating from the same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.  For example, when exporting the Exporting
Process Statistics, or in case of hierarchy of Collector when
aggregated data
records are exported. 



NEW

Observation Domain
ID


A 32-bit identifier of the Observation Domain
that is locally unique to the Exporting Process.  The
Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain
that metered the Flows.  It is
RECOMMENDED that this identifier is also unique per IPFIX Device.  Collecting Processes SHOULD use the Transport Session and the
Observation Domain ID field to separate different export
streams originating from the same Exporting Process.  The
Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.  For example, when exporting the Exporting
Process Statistics, or in case of hierarchy of Collector when
aggregated data
records are exported. 





Section 8, Template Management

OLD

The Exporting Process assigns and maintains the Template IDs
for the Exporter's Observation Domains. A newly created Template Record
is
assigned an unused Template ID by the Exporting Process.




NEW

The Exporting Process assigns and maintains the Template IDs
per SCTP association for the Exporter's Observation Domains.  A newly created Template Record is assigned an
unused Template ID by the Exporting Process.




OLD

A Template ID MUST be unique per Observation Domain.
Different Observation Domains from the same Exporter may use the same
Template
ID value to refer to different Templates. 

NEW

Different Observation
Domains from the same SCTP association may use the same Template ID
value to
refer to different Templates.




OLD

When the
Exporting Process restarts, due to the
SCTP association shutdown, all Template assignments are lost and
Template IDs
MUST be re-assigned. 



NEW

When
the SCTP association shuts down or the
Exporting Process restarts, all Template assignments are lost and
Template IDs
MUST be re-assigned.



Section 9, Collecting Process's side

OLD

Template IDs are unique per
IPFIX Device
and per Observation Domain.  If the
Collecting Process receives a Template which has already been received
but
which has not previously been withdrawn (i.e. a Template Record from
the same
Exporter Observation Domain with the same Template ID), then the
Collecting
Process MUST shutdown the association. 

 



NEW

Template
IDs are unique per SCTP association and per Observation Domain.  If the Collecting Process receives a Template
which has already been received but which has not previously been
withdrawn
(i.e. a Template Record from the same Exporter Observation Domain with
the same
Template ID received on the SCTP association), then the Collecting
Process MUST
shutdown the association. 



OLD



If a Collecting Process
receives a
Template Withdraw Message, the Collecting Process MUST delete the
corresponding
Template Records associated with the specific Exporter and specific
Observation
Domain, and stop decoding IPFIX Messages that use the withdrawn
Templates. 


 


If
the Collecting Process receives a Template Withdraw message for a
Template
Record it has not received before, it MUST reset the SCTP association,
discard
the IPFIX Message, and SHOULD log the error as it does for malformed
IPFIX
Messages.  


 


A
Collecting Process that receives IPFIX Messages from several
Observation Domains
from the same Exporter MUST be aware that the uniqueness of the
Template ID is
not guaranteed across Observation Domains.



NEW

If
a Collecting Process receives a Template Withdraw Message, the
Collecting
Process MUST delete the corresponding Template Records associated with
the
specific SCTP association and specific Observation Domain, and stop
decoding
IPFIX Messages that use the withdrawn Templates. 


I

f
the Collecting Process receives a Template Withdraw message for a
Template
Record it has not received before on this SCTP assocation, it MUST
reset the
SCTP association, discard the IPFIX Message, and SHOULD log the error
as it
does for malformed IPFIX Messages.  


 

A
Collecting Process that receives IPFIX Messages from several
Observation
Domains on the same Transport Session MUST be aware that the uniqueness
of the
Template ID is not guaranteed across Observation Domains.



10.3.7 Collecting Process

OLD

At
any given time the Collecting Process SHOULD
maintain the following for all the current Template Records and Options
Template Records: <Exporting Process, Observation Domain ID,
Template ID,
Template Definition, Last Received>. 



NEW

Template
IDs are unique per UDP session and per Observation Domain.  At any given time
the Collecting Process SHOULD
maintain the following for all the current Template Records and Options
Template Records: <IPFIX Device, Exporter source UDP port,
Observation
Domain ID, Template ID, Template Definition, Last Received>.





10.4.2.2 Template Management



Template
IDs are unique per TCP connection and per Observation Domain.  A
Collecting Process MUST record all Template and Options Template
Records for
the duration of the connection, as an Exporting Process is not required
to
re-export Template Records.

 




[IPFIX-INFO]



NEW

Transport Session

In SCTP, the transport
session is known as the SCTP association, which is uniquely identified
by the
SCTP endpoints [RFC2960]; in TCP, the transport session is known as the
TCP
connection, which is uniquely identified by the combination of IP
addresses and
TCP ports used; In UDP, the transport session is known as the UDP
session,
which is uniquely identified by the combination of IP addresses and UDP
ports
used.


OLD
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain.

NEW
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain and the Transport Session.

OLD
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

NEW
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain and the Transport Session.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

OLD
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain.  Typically, this Information Element is used
      to link to information reported in separate records.

NEW:
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain and Transport Session.  Typically, this Information Element is used
      to link to information reported in separate records.







--------------060701070108020201060203--


--===============0102332178==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0102332178==--




From ipfix-bounces@ietf.org Wed Oct 11 09:10:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXdpM-0005Jf-VZ; Wed, 11 Oct 2006 09:08:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdpL-0005Gc-Ae
	for ipfix@ietf.org; Wed, 11 Oct 2006 09:08:51 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXdpK-0005JW-1q
	for ipfix@ietf.org; Wed, 11 Oct 2006 09:08:51 -0400
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
	k9BD8nP26937
	for ; Wed, 11 Oct 2006 15:08:49 +0200 (CEST)
Received: from [10.61.65.22] (ams3-vpn-dhcp278.cisco.com [10.61.65.22])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9BD8jP20944
	for ; Wed, 11 Oct 2006 15:08:45 +0200 (CEST)
Message-ID: <452CECC2.5080703@cisco.com>
Date: Wed, 11 Oct 2006 15:08:18 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ipfix@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9
Subject: [IPFIX] observation domain, template, and session: compromise
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0102332178=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0102332178==
Content-Type: multipart/alternative;
	boundary="------------060701070108020201060203"

This is a multi-part message in MIME format.
--------------060701070108020201060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Trying to address the concerns posted on the mailing recently regarding 
"observation domain, template, and session", Andrew, Paul, and I sat 
down and worked out a compromise. We're proposing to make template IDs 
unique per (Observation Domain ID, Session) pair. And NOT to scope the 
Observation Domain to the communication session between the Exporting 
Process and Collecting Process (as proposed by Andrew initially)
I think that this compromise will make everybody happy as this solution 
is mainly a clarification, as opposed to a protocol design change.

Problem Statement.
If I read the protocol draft now, one interpretation could be: as I see 
that the Template Ids are unique per Observation Domain, and that the 
Observation Domain Id are RECOMMENDED to be unique per IPFIX Device, 
this implies that the several Exporting Processes of the same IPFIX 
Device must synchronize the assignments of their Template Ids (to make 
sure that the Template Id are unique per Observation Domain). This might 
prove difficult/impossible in some cases.
Instead of imposing this, the other solution is to make the template IDs 
unique per (Observation Domain ID, Session) pair.
This makes sense as, logically, the template IDs have only a local 
significance between E.P. and C.P.
Note: I brought up the issue of load-balancing or backup where it would 
be nice to have the same template IDs between two connections. The 
solution in this case is to use a single E.P. when load-balancing or 
backup is required.

Please acknowledge that this compromise is fine with you.

Note: 3 minor changes are required in the information elements 
definitions in [IPFIX-INFO]

Regards, Andrew, Paul, and Benoit.

See below for the proposed changes.

_[IPFIX-PROTO]
__
_NEW:_
_

Transport Session
In SCTP, the transport session is known as the SCTP association, which 
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
transport session is known as the TCP connection, which is uniquely 
identified by the combination of IP addresses and TCP ports used; In 
UDP, the transport session is known as the UDP session, which is 
uniquely identified by the combination of IP addresses and UDP ports used.



OLD
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Observation
      Domain that generated the Template ID.  Template IDs 0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.


NEW:
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Transport Session and
     Observation Domain that generated the Template ID.  Template IDs 
0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.

OLD (Section 4.4)
     templateId              An identifier of a Template that
                             locally unique to the Exporting
                             Process.  This Information
                             Element MUST be defined as a Scope
                             Field.
NEW
     templateId              An identifier of a Template. This Information
                                   Element MUST be defined as a Scope
                                   Field.

Section 3.1
OLD
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique to 
the Exporting Process.  The Exporting Process uses the Observation 
Domain ID to uniquely identify to the Collecting Process the Observation 
Domain that metered the Flows.  It is RECOMMENDED that this identifier 
is also unique per IPFIX Device.  Collecting Processes SHOULD use the 
combination of the Exporter (exporterIPv4Address, exporterIPv6Address, 
or exportingProcessId) and the Observation Domain ID field to separate 
different export streams originating from the same Exporting Process.  
The Observation Domain ID SHOULD be 0 when no specific Observation 
Domain ID is relevant for the entire IPFIX Message.  For example, when 
exporting the Exporting Process Statistics, or in case of hierarchy of 
Collector when aggregated data records are exported.

NEW
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique to 
the Exporting Process.  The Exporting Process uses the Observation 
Domain ID to uniquely identify to the Collecting Process the Observation 
Domain that metered the Flows.  It is RECOMMENDED that this identifier 
is also unique per IPFIX Device.  Collecting Processes SHOULD use the 
Transport Session and the Observation Domain ID field to separate 
different export streams originating from the same Exporting Process.  
The Observation Domain ID SHOULD be 0 when no specific Observation 
Domain ID is relevant for the entire IPFIX Message.  For example, when 
exporting the Exporting Process Statistics, or in case of hierarchy of 
Collector when aggregated data records are exported.

Section 8, Template Management
OLD
The Exporting Process assigns and maintains the Template IDs for the 
Exporter's Observation Domains. A newly created Template Record is 
assigned an unused Template ID by the Exporting Process.

NEW
The Exporting Process assigns and maintains the Template IDs per SCTP 
association for the Exporter's Observation Domains.  A newly created 
Template Record is assigned an unused Template ID by the Exporting Process.

OLD
A Template ID MUST be unique per Observation Domain. Different 
Observation Domains from the same Exporter may use the same Template ID 
value to refer to different Templates.

NEW
Different Observation Domains from the same SCTP association may use the 
same Template ID value to refer to different Templates.

OLD
When the Exporting Process restarts, due to the SCTP association 
shutdown, all Template assignments are lost and Template IDs MUST be 
re-assigned.

NEW
When the SCTP association shuts down or the Exporting Process restarts, 
all Template assignments are lost and Template IDs MUST be re-assigned.

Section 9, Collecting Process's side
OLD
Template IDs are unique per IPFIX Device and per Observation Domain.  If 
the Collecting Process receives a Template which has already been 
received but which has not previously been withdrawn (i.e. a Template 
Record from the same Exporter Observation Domain with the same Template 
ID), then the Collecting Process MUST shutdown the association.


NEW
Template IDs are unique per SCTP association and per Observation 
Domain.  If the Collecting Process receives a Template which has already 
been received but which has not previously been withdrawn (i.e. a 
Template Record from the same Exporter Observation Domain with the same 
Template ID received on the SCTP association), then the Collecting 
Process MUST shutdown the association.

OLD

If a Collecting Process receives a Template Withdraw Message, the 
Collecting Process MUST delete the corresponding Template Records 
associated with the specific Exporter and specific Observation Domain, 
and stop decoding IPFIX Messages that use the withdrawn Templates.
 
If the Collecting Process receives a Template Withdraw message for a 
Template Record it has not received before, it MUST reset the SCTP 
association, discard the IPFIX Message, and SHOULD log the error as it 
does for malformed IPFIX Messages. 
 
A Collecting Process that receives IPFIX Messages from several 
Observation Domains from the same Exporter MUST be aware that the 
uniqueness of the Template ID is not guaranteed across Observation Domains.

NEW
If a Collecting Process receives a Template Withdraw Message, the 
Collecting Process MUST delete the corresponding Template Records 
associated with the specific SCTP association and specific Observation 
Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
I
f the Collecting Process receives a Template Withdraw message for a 
Template Record it has not received before on this SCTP assocation, it 
MUST reset the SCTP association, discard the IPFIX Message, and SHOULD 
log the error as it does for malformed IPFIX Messages. 
 
A Collecting Process that receives IPFIX Messages from several 
Observation Domains on the same Transport Session MUST be aware that the 
uniqueness of the Template ID is not guaranteed across Observation Domains.

10.3.7 Collecting Process
OLD
At any given time the Collecting Process SHOULD maintain the following 
for all the current Template Records and Options Template Records: 
.

NEW
Template IDs are unique per UDP session and per Observation Domain.  At 
any given time the Collecting Process SHOULD maintain the following for 
all the current Template Records and Options Template Records: .


10.4.2.2 Template Management

Template IDs are unique per TCP connection and per Observation Domain.  
A Collecting Process MUST record all Template and Options Template 
Records for the duration of the connection, as an Exporting Process is 
not required to re-export Template Records.
 

_[IPFIX-INFO]_

NEW

Transport Session
In SCTP, the transport session is known as the SCTP association, which 
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
transport session is known as the TCP connection, which is uniquely 
identified by the combination of IP addresses and TCP ports used; In 
UDP, the transport session is known as the UDP session, which is 
uniquely identified by the combination of IP addresses and UDP ports used.

OLD
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain.

NEW
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain and the Transport Session.

OLD
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

NEW
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain and the Transport Session.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

OLD
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain.  Typically, this Information Element is used
      to link to information reported in separate records.

NEW:
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain and Transport Session.  Typically, this Information Element is used
      to link to information reported in separate records.



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




  


Dear all,



Trying to address the concerns posted on the mailing recently regarding
"observation domain, template, and session", Andrew, Paul, and I sat
down and worked out a compromise. We're
proposing to make template IDs unique per (Observation Domain ID,
Session) pair. And NOT to scope the Observation Domain to the
communication session between the
Exporting Process and Collecting Process (as proposed by Andrew
initially)

I think that this compromise will make everybody happy as this solution
is mainly a clarification,
as opposed to a protocol design change.




Problem Statement.

If I read the protocol draft now, one interpretation could be: as I see
that the Template Ids are unique
per Observation Domain, and that the Observation Domain Id are
RECOMMENDED to
be unique per IPFIX Device, this implies that the several Exporting
Processes of the same IPFIX Device must synchronize the assignments of
their
Template Ids (to make sure that the Template Id are unique per
Observation Domain). This might prove difficult/impossible in some
cases.

Instead of imposing this, the other solution is to make the template
IDs unique per (Observation Domain ID,
Session) pair.

This makes sense as, logically, the template IDs have only a local
significance between E.P. and C.P.

Note: I brought up the issue of load-balancing or backup where it would
be nice to have the same template IDs between two connections. The
solution in this case is to use a single E.P. when load-balancing or
backup is required.



Please acknowledge that this compromise is fine with you.



Note: 3 minor changes are required in the information elements
definitions in [IPFIX-INFO]



Regards, Andrew, Paul, and Benoit.



See below for the proposed changes.



[IPFIX-PROTO]



NEW:



Transport
Session

In SCTP, the transport
session is known as the SCTP association, which is uniquely identified
by the
SCTP endpoints [RFC2960]; in TCP, the transport session is known as the
TCP
connection, which is uniquely identified by the combination of IP
addresses and
TCP ports used; In UDP, the transport session is known as the UDP
session,
which is uniquely identified by the combination of IP addresses and UDP
ports
used.





OLD

Template
ID


      Each of the newly
generated Template Records is given a unique 

      Template ID.  This
uniqueness is local to the Observation 

      Domain
that generated the Template ID.  Template IDs
0-255 are 

      reserved for Template Sets, Options
Template Sets, and other 

      reserved Sets yet to be created.  Template IDs of Data Sets 

      are numbered from 256 to 65535.  There are no constraints 


      regarding the order of the
Template ID
allocation.





NEW:

Template
ID


      Each of the newly
generated Template Records is given a unique 

      Template ID.  This
uniqueness is local to the Transport Session
and 

     Observation Domain that generated the Template ID. 
Template IDs 0-255 are 

      reserved for Template Sets, Options
Template Sets, and other 

      reserved Sets yet to be
created.  Template IDs of Data Sets 

      are numbered from 256 to 65535.  There are no constraints 


      regarding the order of the
Template ID
allocation. 



OLD (Section 4.4)

    
templateId              An
identifier of a Template that 

                             locally
unique to
the Exporting 

                             Process.  This Information 

                             Element MUST
be defined as a Scope

                             Field.

NEW

    
templateId              An
identifier of a Template. This Information 

                                   Element MUST
be defined as a Scope

                               
   Field.



Section 3.1

OLD

Observation Domain
ID


A 32-bit identifier of the Observation Domain
that is locally unique to the Exporting Process.  The
Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain
that metered the Flows.  It is
RECOMMENDED that this identifier is also unique per IPFIX Device.  Collecting Processes SHOULD use the combination
of the Exporter (exporterIPv4Address, exporterIPv6Address, or
exportingProcessId) and the Observation Domain ID field to separate
different
export streams originating from the same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.  For example, when exporting the Exporting
Process Statistics, or in case of hierarchy of Collector when
aggregated data
records are exported. 



NEW

Observation Domain
ID


A 32-bit identifier of the Observation Domain
that is locally unique to the Exporting Process.  The
Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain
that metered the Flows.  It is
RECOMMENDED that this identifier is also unique per IPFIX Device.  Collecting Processes SHOULD use the Transport Session and the
Observation Domain ID field to separate different export
streams originating from the same Exporting Process.  The
Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.  For example, when exporting the Exporting
Process Statistics, or in case of hierarchy of Collector when
aggregated data
records are exported. 





Section 8, Template Management

OLD

The Exporting Process assigns and maintains the Template IDs
for the Exporter's Observation Domains. A newly created Template Record
is
assigned an unused Template ID by the Exporting Process.




NEW

The Exporting Process assigns and maintains the Template IDs
per SCTP association for the Exporter's Observation Domains.  A newly created Template Record is assigned an
unused Template ID by the Exporting Process.




OLD

A Template ID MUST be unique per Observation Domain.
Different Observation Domains from the same Exporter may use the same
Template
ID value to refer to different Templates. 

NEW

Different Observation
Domains from the same SCTP association may use the same Template ID
value to
refer to different Templates.




OLD

When the
Exporting Process restarts, due to the
SCTP association shutdown, all Template assignments are lost and
Template IDs
MUST be re-assigned. 



NEW

When
the SCTP association shuts down or the
Exporting Process restarts, all Template assignments are lost and
Template IDs
MUST be re-assigned.



Section 9, Collecting Process's side

OLD

Template IDs are unique per
IPFIX Device
and per Observation Domain.  If the
Collecting Process receives a Template which has already been received
but
which has not previously been withdrawn (i.e. a Template Record from
the same
Exporter Observation Domain with the same Template ID), then the
Collecting
Process MUST shutdown the association. 

 



NEW

Template
IDs are unique per SCTP association and per Observation Domain.  If the Collecting Process receives a Template
which has already been received but which has not previously been
withdrawn
(i.e. a Template Record from the same Exporter Observation Domain with
the same
Template ID received on the SCTP association), then the Collecting
Process MUST
shutdown the association. 



OLD



If a Collecting Process
receives a
Template Withdraw Message, the Collecting Process MUST delete the
corresponding
Template Records associated with the specific Exporter and specific
Observation
Domain, and stop decoding IPFIX Messages that use the withdrawn
Templates. 


 


If
the Collecting Process receives a Template Withdraw message for a
Template
Record it has not received before, it MUST reset the SCTP association,
discard
the IPFIX Message, and SHOULD log the error as it does for malformed
IPFIX
Messages.  


 


A
Collecting Process that receives IPFIX Messages from several
Observation Domains
from the same Exporter MUST be aware that the uniqueness of the
Template ID is
not guaranteed across Observation Domains.



NEW

If
a Collecting Process receives a Template Withdraw Message, the
Collecting
Process MUST delete the corresponding Template Records associated with
the
specific SCTP association and specific Observation Domain, and stop
decoding
IPFIX Messages that use the withdrawn Templates. 


I

f
the Collecting Process receives a Template Withdraw message for a
Template
Record it has not received before on this SCTP assocation, it MUST
reset the
SCTP association, discard the IPFIX Message, and SHOULD log the error
as it
does for malformed IPFIX Messages.  


 

A
Collecting Process that receives IPFIX Messages from several
Observation
Domains on the same Transport Session MUST be aware that the uniqueness
of the
Template ID is not guaranteed across Observation Domains.



10.3.7 Collecting Process

OLD

At
any given time the Collecting Process SHOULD
maintain the following for all the current Template Records and Options
Template Records: <Exporting Process, Observation Domain ID,
Template ID,
Template Definition, Last Received>. 



NEW

Template
IDs are unique per UDP session and per Observation Domain.  At any given time
the Collecting Process SHOULD
maintain the following for all the current Template Records and Options
Template Records: <IPFIX Device, Exporter source UDP port,
Observation
Domain ID, Template ID, Template Definition, Last Received>.





10.4.2.2 Template Management



Template
IDs are unique per TCP connection and per Observation Domain.  A
Collecting Process MUST record all Template and Options Template
Records for
the duration of the connection, as an Exporting Process is not required
to
re-export Template Records.

 




[IPFIX-INFO]



NEW

Transport Session

In SCTP, the transport
session is known as the SCTP association, which is uniquely identified
by the
SCTP endpoints [RFC2960]; in TCP, the transport session is known as the
TCP
connection, which is uniquely identified by the combination of IP
addresses and
TCP ports used; In UDP, the transport session is known as the UDP
session,
which is uniquely identified by the combination of IP addresses and UDP
ports
used.


OLD
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain.

NEW
5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique within an
      Observation Domain and the Transport Session.

OLD
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

NEW
5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain and the Transport Session.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.

OLD
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain.  Typically, this Information Element is used
      to link to information reported in separate records.

NEW:
5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain and Transport Session.  Typically, this Information Element is used
      to link to information reported in separate records.







--------------060701070108020201060203--


--===============0102332178==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0102332178==--




From ipfix-bounces@ietf.org Wed Oct 11 12:04:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXgW3-0003HT-Cu; Wed, 11 Oct 2006 12:01:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgW1-0003F1-MX
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:01:05 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgW1-0003DQ-04
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:01:05 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9BG0wO4026993 for ; Wed, 11 Oct 2006 12:01:00 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9BFxsQC026919
	for ; Wed, 11 Oct 2006 11:59:54 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9BFxsoH026917;
	Wed, 11 Oct 2006 11:59:54 -0400 (EDT)
Received: from [172.28.173.116] (vpn-10-25-4-22.remote.cert.org [10.25.4.22])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9BFxnl4004220; Wed, 11 Oct 2006 11:59:52 -0400
In-Reply-To: <452CECC2.5080703@cisco.com>
References: <452CECC2.5080703@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Wed, 11 Oct 2006 08:39:55 -0700
To: Benoit Claise 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Benoit and all,

Excellent - this looks good to me, and addresses all the concerns I  
had with scoping templates and observation IDs (and as you point out,  
has the added benefit of minimal change to the protocol as it stands).

One point: do we want to be more pedantic about defining a Transport  
Session for UDP? Both the SCTP and TCP Transport Session definitions  
have temporal limits (the Association or the Connection lifetime,  
defined by each transport protocol itself), while UDP does not. I  
would suggest (from a past message to the list):

In UDP, the transport session is known as the UDP session, which is  
uniquely identified by the IP addresses and UDP ports used, within  
the time between the first UDP packet sent by the EP in the session  
and the timeout after the last template retransmission.

Thoughts?

- Brian

On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:

> Dear all,
>
> Trying to address the concerns posted on the mailing recently  
> regarding "observation domain, template, and session", Andrew,  
> Paul, and I sat down and worked out a compromise. We're proposing  
> to make template IDs unique per (Observation Domain ID, Session)  
> pair. And NOT to scope the Observation Domain to the communication  
> session between the Exporting Process and Collecting Process (as  
> proposed by Andrew initially)
> I think that this compromise will make everybody happy as this  
> solution is mainly a clarification, as opposed to a protocol design  
> change.
>
> Problem Statement.
> If I read the protocol draft now, one interpretation could be: as I  
> see that the Template Ids are unique per Observation Domain, and  
> that the Observation Domain Id are RECOMMENDED to be unique per  
> IPFIX Device, this implies that the several Exporting Processes of  
> the same IPFIX Device must synchronize the assignments of their  
> Template Ids (to make sure that the Template Id are unique per  
> Observation Domain). This might prove difficult/impossible in some  
> cases.
> Instead of imposing this, the other solution is to make the  
> template IDs unique per (Observation Domain ID, Session) pair.
> This makes sense as, logically, the template IDs have only a local  
> significance between E.P. and C.P.
> Note: I brought up the issue of load-balancing or backup where it  
> would be nice to have the same template IDs between two  
> connections. The solution in this case is to use a single E.P. when  
> load-balancing or backup is required.
>
> Please acknowledge that this compromise is fine with you.
>
> Note: 3 minor changes are required in the information elements  
> definitions in [IPFIX-INFO]
>
> Regards, Andrew, Paul, and Benoit.
>
> See below for the proposed changes.
>
> [IPFIX-PROTO]
>
> NEW:
> Transport Session
> In SCTP, the transport session is known as the SCTP association,  
> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
> TCP, the transport session is known as the TCP connection, which is  
> uniquely identified by the combination of IP addresses and TCP  
> ports used; In UDP, the transport session is known as the UDP  
> session, which is uniquely identified by the combination of IP  
> addresses and UDP ports used.
>
>
>
> OLD
> Template ID
>       Each of the newly generated Template Records is given a unique
>       Template ID.  This uniqueness is local to the Observation
>       Domain that generated the Template ID.  Template IDs 0-255 are
>       reserved for Template Sets, Options Template Sets, and other
>       reserved Sets yet to be created.  Template IDs of Data Sets
>       are numbered from 256 to 65535.  There are no constraints
>       regarding the order of the Template ID allocation.
>
>
> NEW:
> Template ID
>       Each of the newly generated Template Records is given a unique
>       Template ID.  This uniqueness is local to the Transport  
> Session and
>      Observation Domain that generated the Template ID.  Template  
> IDs 0-255 are
>       reserved for Template Sets, Options Template Sets, and other
>       reserved Sets yet to be created.  Template IDs of Data Sets
>       are numbered from 256 to 65535.  There are no constraints
>       regarding the order of the Template ID allocation.
>
> OLD (Section 4.4)
>      templateId              An identifier of a Template that
>                              locally unique to the Exporting
>                              Process.  This Information
>                              Element MUST be defined as a Scope
>                              Field.
> NEW
>      templateId              An identifier of a Template. This  
> Information
>                                    Element MUST be defined as a Scope
>                                    Field.
>
> Section 3.1
> OLD
> Observation Domain ID
> A 32-bit identifier of the Observation Domain that is locally  
> unique to the Exporting Process.  The Exporting Process uses the  
> Observation Domain ID to uniquely identify to the Collecting  
> Process the Observation Domain that metered the Flows.  It is  
> RECOMMENDED that this identifier is also unique per IPFIX Device.   
> Collecting Processes SHOULD use the combination of the Exporter  
> (exporterIPv4Address, exporterIPv6Address, or exportingProcessId)  
> and the Observation Domain ID field to separate different export  
> streams originating from the same Exporting Process.  The  
> Observation Domain ID SHOULD be 0 when no specific Observation  
> Domain ID is relevant for the entire IPFIX Message.  For example,  
> when exporting the Exporting Process Statistics, or in case of  
> hierarchy of Collector when aggregated data records are exported.
>
> NEW
> Observation Domain ID
> A 32-bit identifier of the Observation Domain that is locally  
> unique to the Exporting Process.  The Exporting Process uses the  
> Observation Domain ID to uniquely identify to the Collecting  
> Process the Observation Domain that metered the Flows.  It is  
> RECOMMENDED that this identifier is also unique per IPFIX Device.   
> Collecting Processes SHOULD use the Transport Session and the  
> Observation Domain ID field to separate different export streams  
> originating from the same Exporting Process.  The Observation  
> Domain ID SHOULD be 0 when no specific Observation Domain ID is  
> relevant for the entire IPFIX Message.  For example, when exporting  
> the Exporting Process Statistics, or in case of hierarchy of  
> Collector when aggregated data records are exported.
>
> Section 8, Template Management
> OLD
> The Exporting Process assigns and maintains the Template IDs for  
> the Exporter's Observation Domains. A newly created Template Record  
> is assigned an unused Template ID by the Exporting Process.
>
> NEW
> The Exporting Process assigns and maintains the Template IDs per  
> SCTP association for the Exporter's Observation Domains.  A newly  
> created Template Record is assigned an unused Template ID by the  
> Exporting Process.
>
> OLD
> A Template ID MUST be unique per Observation Domain. Different  
> Observation Domains from the same Exporter may use the same  
> Template ID value to refer to different Templates.
>
> NEW
> Different Observation Domains from the same SCTP association may  
> use the same Template ID value to refer to different Templates.
>
> OLD
> When the Exporting Process restarts, due to the SCTP association  
> shutdown, all Template assignments are lost and Template IDs MUST  
> be re-assigned.
>
> NEW
> When the SCTP association shuts down or the Exporting Process  
> restarts, all Template assignments are lost and Template IDs MUST  
> be re-assigned.
>
> Section 9, Collecting Process's side
> OLD
> Template IDs are unique per IPFIX Device and per Observation  
> Domain.  If the Collecting Process receives a Template which has  
> already been received but which has not previously been withdrawn  
> (i.e. a Template Record from the same Exporter Observation Domain  
> with the same Template ID), then the Collecting Process MUST  
> shutdown the association.
>
>
> NEW
> Template IDs are unique per SCTP association and per Observation  
> Domain.  If the Collecting Process receives a Template which has  
> already been received but which has not previously been withdrawn  
> (i.e. a Template Record from the same Exporter Observation Domain  
> with the same Template ID received on the SCTP association), then  
> the Collecting Process MUST shutdown the association.
>
> OLD
>
> If a Collecting Process receives a Template Withdraw Message, the  
> Collecting Process MUST delete the corresponding Template Records  
> associated with the specific Exporter and specific Observation  
> Domain, and stop decoding IPFIX Messages that use the withdrawn  
> Templates.
>
> If the Collecting Process receives a Template Withdraw message for  
> a Template Record it has not received before, it MUST reset the  
> SCTP association, discard the IPFIX Message, and SHOULD log the  
> error as it does for malformed IPFIX Messages.
>
> A Collecting Process that receives IPFIX Messages from several  
> Observation Domains from the same Exporter MUST be aware that the  
> uniqueness of the Template ID is not guaranteed across Observation  
> Domains.
>
> NEW
> If a Collecting Process receives a Template Withdraw Message, the  
> Collecting Process MUST delete the corresponding Template Records  
> associated with the specific SCTP association and specific  
> Observation Domain, and stop decoding IPFIX Messages that use the  
> withdrawn Templates.
> I
> f the Collecting Process receives a Template Withdraw message for a  
> Template Record it has not received before on this SCTP assocation,  
> it MUST reset the SCTP association, discard the IPFIX Message, and  
> SHOULD log the error as it does for malformed IPFIX Messages.
>
> A Collecting Process that receives IPFIX Messages from several  
> Observation Domains on the same Transport Session MUST be aware  
> that the uniqueness of the Template ID is not guaranteed across  
> Observation Domains.
>
> 10.3.7 Collecting Process
> OLD
> At any given time the Collecting Process SHOULD maintain the  
> following for all the current Template Records and Options Template  
> Records:  Template Definition, Last Received>.
>
> NEW
> Template IDs are unique per UDP session and per Observation  
> Domain.  At any given time the Collecting Process SHOULD maintain  
> the following for all the current Template Records and Options  
> Template Records:  Observation Domain ID, Template ID, Template Definition, Last  
> Received>.
>
>
> 10.4.2.2 Template Management
>
> Template IDs are unique per TCP connection and per Observation  
> Domain.  A Collecting Process MUST record all Template and Options  
> Template Records for the duration of the connection, as an  
> Exporting Process is not required to re-export Template Records.
>
>
> [IPFIX-INFO]
> NEWTransport Session
> In SCTP, the transport session is known as the SCTP association,  
> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
> TCP, the transport session is known as the TCP connection, which is  
> uniquely identified by the combination of IP addresses and TCP  
> ports used; In UDP, the transport session is known as the UDP  
> session, which is uniquely identified by the combination of IP  
> addresses and UDP ports used.
> OLD 5.1.8. templateId Description: An identifier of a Template that  
> is locally unique within an Observation Domain. NEW 5.1.8.  
> templateId Description: An identifier of a Template that is locally  
> unique within an Observation Domain and the Transport Session. OLD  
> 5.1.7. flowId Description: An identifier of a Flow that is unique  
> within an Observation Domain. This Information Element can be used  
> to distinguish between different Flows if Flow Keys such as IP  
> addresses and port numbers are not reported or are reported in  
> separate records. NEW 5.1.7. flowId Description: An identifier of a  
> Flow that is unique within an Observation Domain and the Transport  
> Session. This Information Element can be used to distinguish  
> between different Flows if Flow Keys such as IP addresses and port  
> numbers are not reported or are reported in separate records. OLD  
> 5.1.11. commonPropertiesId Description: An identifier of a set of  
> common properties that is unique per Observation Domain. Typically,  
> this Information Element is used to link to information reported in  
> separate records. NEW: 5.1.11. commonPropertiesId Description: An  
> identifier of a set of common properties that is unique per  
> Observation Domain and Transport Session. Typically, this  
> Information Element is used to link to information reported in  
> separate records.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Wed Oct 11 12:04:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXgW3-0003HT-Cu; Wed, 11 Oct 2006 12:01:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgW1-0003F1-MX
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:01:05 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgW1-0003DQ-04
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:01:05 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9BG0wO4026993 for ; Wed, 11 Oct 2006 12:01:00 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9BFxsQC026919
	for ; Wed, 11 Oct 2006 11:59:54 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9BFxsoH026917;
	Wed, 11 Oct 2006 11:59:54 -0400 (EDT)
Received: from [172.28.173.116] (vpn-10-25-4-22.remote.cert.org [10.25.4.22])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9BFxnl4004220; Wed, 11 Oct 2006 11:59:52 -0400
In-Reply-To: <452CECC2.5080703@cisco.com>
References: <452CECC2.5080703@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Wed, 11 Oct 2006 08:39:55 -0700
To: Benoit Claise 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Benoit and all,

Excellent - this looks good to me, and addresses all the concerns I  
had with scoping templates and observation IDs (and as you point out,  
has the added benefit of minimal change to the protocol as it stands).

One point: do we want to be more pedantic about defining a Transport  
Session for UDP? Both the SCTP and TCP Transport Session definitions  
have temporal limits (the Association or the Connection lifetime,  
defined by each transport protocol itself), while UDP does not. I  
would suggest (from a past message to the list):

In UDP, the transport session is known as the UDP session, which is  
uniquely identified by the IP addresses and UDP ports used, within  
the time between the first UDP packet sent by the EP in the session  
and the timeout after the last template retransmission.

Thoughts?

- Brian

On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:

> Dear all,
>
> Trying to address the concerns posted on the mailing recently  
> regarding "observation domain, template, and session", Andrew,  
> Paul, and I sat down and worked out a compromise. We're proposing  
> to make template IDs unique per (Observation Domain ID, Session)  
> pair. And NOT to scope the Observation Domain to the communication  
> session between the Exporting Process and Collecting Process (as  
> proposed by Andrew initially)
> I think that this compromise will make everybody happy as this  
> solution is mainly a clarification, as opposed to a protocol design  
> change.
>
> Problem Statement.
> If I read the protocol draft now, one interpretation could be: as I  
> see that the Template Ids are unique per Observation Domain, and  
> that the Observation Domain Id are RECOMMENDED to be unique per  
> IPFIX Device, this implies that the several Exporting Processes of  
> the same IPFIX Device must synchronize the assignments of their  
> Template Ids (to make sure that the Template Id are unique per  
> Observation Domain). This might prove difficult/impossible in some  
> cases.
> Instead of imposing this, the other solution is to make the  
> template IDs unique per (Observation Domain ID, Session) pair.
> This makes sense as, logically, the template IDs have only a local  
> significance between E.P. and C.P.
> Note: I brought up the issue of load-balancing or backup where it  
> would be nice to have the same template IDs between two  
> connections. The solution in this case is to use a single E.P. when  
> load-balancing or backup is required.
>
> Please acknowledge that this compromise is fine with you.
>
> Note: 3 minor changes are required in the information elements  
> definitions in [IPFIX-INFO]
>
> Regards, Andrew, Paul, and Benoit.
>
> See below for the proposed changes.
>
> [IPFIX-PROTO]
>
> NEW:
> Transport Session
> In SCTP, the transport session is known as the SCTP association,  
> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
> TCP, the transport session is known as the TCP connection, which is  
> uniquely identified by the combination of IP addresses and TCP  
> ports used; In UDP, the transport session is known as the UDP  
> session, which is uniquely identified by the combination of IP  
> addresses and UDP ports used.
>
>
>
> OLD
> Template ID
>       Each of the newly generated Template Records is given a unique
>       Template ID.  This uniqueness is local to the Observation
>       Domain that generated the Template ID.  Template IDs 0-255 are
>       reserved for Template Sets, Options Template Sets, and other
>       reserved Sets yet to be created.  Template IDs of Data Sets
>       are numbered from 256 to 65535.  There are no constraints
>       regarding the order of the Template ID allocation.
>
>
> NEW:
> Template ID
>       Each of the newly generated Template Records is given a unique
>       Template ID.  This uniqueness is local to the Transport  
> Session and
>      Observation Domain that generated the Template ID.  Template  
> IDs 0-255 are
>       reserved for Template Sets, Options Template Sets, and other
>       reserved Sets yet to be created.  Template IDs of Data Sets
>       are numbered from 256 to 65535.  There are no constraints
>       regarding the order of the Template ID allocation.
>
> OLD (Section 4.4)
>      templateId              An identifier of a Template that
>                              locally unique to the Exporting
>                              Process.  This Information
>                              Element MUST be defined as a Scope
>                              Field.
> NEW
>      templateId              An identifier of a Template. This  
> Information
>                                    Element MUST be defined as a Scope
>                                    Field.
>
> Section 3.1
> OLD
> Observation Domain ID
> A 32-bit identifier of the Observation Domain that is locally  
> unique to the Exporting Process.  The Exporting Process uses the  
> Observation Domain ID to uniquely identify to the Collecting  
> Process the Observation Domain that metered the Flows.  It is  
> RECOMMENDED that this identifier is also unique per IPFIX Device.   
> Collecting Processes SHOULD use the combination of the Exporter  
> (exporterIPv4Address, exporterIPv6Address, or exportingProcessId)  
> and the Observation Domain ID field to separate different export  
> streams originating from the same Exporting Process.  The  
> Observation Domain ID SHOULD be 0 when no specific Observation  
> Domain ID is relevant for the entire IPFIX Message.  For example,  
> when exporting the Exporting Process Statistics, or in case of  
> hierarchy of Collector when aggregated data records are exported.
>
> NEW
> Observation Domain ID
> A 32-bit identifier of the Observation Domain that is locally  
> unique to the Exporting Process.  The Exporting Process uses the  
> Observation Domain ID to uniquely identify to the Collecting  
> Process the Observation Domain that metered the Flows.  It is  
> RECOMMENDED that this identifier is also unique per IPFIX Device.   
> Collecting Processes SHOULD use the Transport Session and the  
> Observation Domain ID field to separate different export streams  
> originating from the same Exporting Process.  The Observation  
> Domain ID SHOULD be 0 when no specific Observation Domain ID is  
> relevant for the entire IPFIX Message.  For example, when exporting  
> the Exporting Process Statistics, or in case of hierarchy of  
> Collector when aggregated data records are exported.
>
> Section 8, Template Management
> OLD
> The Exporting Process assigns and maintains the Template IDs for  
> the Exporter's Observation Domains. A newly created Template Record  
> is assigned an unused Template ID by the Exporting Process.
>
> NEW
> The Exporting Process assigns and maintains the Template IDs per  
> SCTP association for the Exporter's Observation Domains.  A newly  
> created Template Record is assigned an unused Template ID by the  
> Exporting Process.
>
> OLD
> A Template ID MUST be unique per Observation Domain. Different  
> Observation Domains from the same Exporter may use the same  
> Template ID value to refer to different Templates.
>
> NEW
> Different Observation Domains from the same SCTP association may  
> use the same Template ID value to refer to different Templates.
>
> OLD
> When the Exporting Process restarts, due to the SCTP association  
> shutdown, all Template assignments are lost and Template IDs MUST  
> be re-assigned.
>
> NEW
> When the SCTP association shuts down or the Exporting Process  
> restarts, all Template assignments are lost and Template IDs MUST  
> be re-assigned.
>
> Section 9, Collecting Process's side
> OLD
> Template IDs are unique per IPFIX Device and per Observation  
> Domain.  If the Collecting Process receives a Template which has  
> already been received but which has not previously been withdrawn  
> (i.e. a Template Record from the same Exporter Observation Domain  
> with the same Template ID), then the Collecting Process MUST  
> shutdown the association.
>
>
> NEW
> Template IDs are unique per SCTP association and per Observation  
> Domain.  If the Collecting Process receives a Template which has  
> already been received but which has not previously been withdrawn  
> (i.e. a Template Record from the same Exporter Observation Domain  
> with the same Template ID received on the SCTP association), then  
> the Collecting Process MUST shutdown the association.
>
> OLD
>
> If a Collecting Process receives a Template Withdraw Message, the  
> Collecting Process MUST delete the corresponding Template Records  
> associated with the specific Exporter and specific Observation  
> Domain, and stop decoding IPFIX Messages that use the withdrawn  
> Templates.
>
> If the Collecting Process receives a Template Withdraw message for  
> a Template Record it has not received before, it MUST reset the  
> SCTP association, discard the IPFIX Message, and SHOULD log the  
> error as it does for malformed IPFIX Messages.
>
> A Collecting Process that receives IPFIX Messages from several  
> Observation Domains from the same Exporter MUST be aware that the  
> uniqueness of the Template ID is not guaranteed across Observation  
> Domains.
>
> NEW
> If a Collecting Process receives a Template Withdraw Message, the  
> Collecting Process MUST delete the corresponding Template Records  
> associated with the specific SCTP association and specific  
> Observation Domain, and stop decoding IPFIX Messages that use the  
> withdrawn Templates.
> I
> f the Collecting Process receives a Template Withdraw message for a  
> Template Record it has not received before on this SCTP assocation,  
> it MUST reset the SCTP association, discard the IPFIX Message, and  
> SHOULD log the error as it does for malformed IPFIX Messages.
>
> A Collecting Process that receives IPFIX Messages from several  
> Observation Domains on the same Transport Session MUST be aware  
> that the uniqueness of the Template ID is not guaranteed across  
> Observation Domains.
>
> 10.3.7 Collecting Process
> OLD
> At any given time the Collecting Process SHOULD maintain the  
> following for all the current Template Records and Options Template  
> Records:  Template Definition, Last Received>.
>
> NEW
> Template IDs are unique per UDP session and per Observation  
> Domain.  At any given time the Collecting Process SHOULD maintain  
> the following for all the current Template Records and Options  
> Template Records:  Observation Domain ID, Template ID, Template Definition, Last  
> Received>.
>
>
> 10.4.2.2 Template Management
>
> Template IDs are unique per TCP connection and per Observation  
> Domain.  A Collecting Process MUST record all Template and Options  
> Template Records for the duration of the connection, as an  
> Exporting Process is not required to re-export Template Records.
>
>
> [IPFIX-INFO]
> NEWTransport Session
> In SCTP, the transport session is known as the SCTP association,  
> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
> TCP, the transport session is known as the TCP connection, which is  
> uniquely identified by the combination of IP addresses and TCP  
> ports used; In UDP, the transport session is known as the UDP  
> session, which is uniquely identified by the combination of IP  
> addresses and UDP ports used.
> OLD 5.1.8. templateId Description: An identifier of a Template that  
> is locally unique within an Observation Domain. NEW 5.1.8.  
> templateId Description: An identifier of a Template that is locally  
> unique within an Observation Domain and the Transport Session. OLD  
> 5.1.7. flowId Description: An identifier of a Flow that is unique  
> within an Observation Domain. This Information Element can be used  
> to distinguish between different Flows if Flow Keys such as IP  
> addresses and port numbers are not reported or are reported in  
> separate records. NEW 5.1.7. flowId Description: An identifier of a  
> Flow that is unique within an Observation Domain and the Transport  
> Session. This Information Element can be used to distinguish  
> between different Flows if Flow Keys such as IP addresses and port  
> numbers are not reported or are reported in separate records. OLD  
> 5.1.11. commonPropertiesId Description: An identifier of a set of  
> common properties that is unique per Observation Domain. Typically,  
> this Information Element is used to link to information reported in  
> separate records. NEW: 5.1.11. commonPropertiesId Description: An  
> identifier of a set of common properties that is unique per  
> Observation Domain and Transport Session. Typically, this  
> Information Element is used to link to information reported in  
> separate records.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Wed Oct 11 12:13:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXghR-0002Ed-QN; Wed, 11 Oct 2006 12:12:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXghR-0002EX-5u
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:12:53 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXghP-0004dX-Sg
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:12:53 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 11 Oct 2006 18:12:51 +0200
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.20060308/8.12.11) with ESMTP id
	k9BGCph5012951; Wed, 11 Oct 2006 18:12:51 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9BGComd001238; 
	Wed, 11 Oct 2006 18:12:50 +0200 (MEST)
Received: from [10.61.80.155] (ams3-vpn-dhcp4252.cisco.com [10.61.80.155])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA19698;
	Wed, 11 Oct 2006 17:12:49 +0100 (BST)
Message-ID: <452D1800.7010508@cisco.com>
Date: Wed, 11 Oct 2006 17:12:48 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=532; t=1160583171; x=1161447171;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20observation=20domain, =20template,
	=20and=20session=3A=2 0compromise;
	X=v=3Dcisco.com=3B=20h=3DQe/1wLq0bolv8CevZZxHTWF7Bmw=3D;
	b=CRT76D8NcdjWYSa13uW59HqvW9VTHSnJwsvWi9IumTQvCXVsjV3/6w5oRXKN9MibuWh+5Pve
	iGU1g4gR+obLu/739Xp2VfegsLXqFN2fLHfaid3NR9BmM9p7i+SxAqBO;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

> In UDP, the transport session is known as the UDP session, which is  
> uniquely identified by the IP addresses and UDP ports used, within  the 
> time between the first UDP packet sent by the EP in the session  and the 
> timeout after the last template retransmission.

Seems good to me. But change "last" to "latest" or "most recent".

Someone once asked me how we know it's the "last packet". We don't; we 
mean "last seen so far", aka "latest".

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Wed Oct 11 12:13:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXghR-0002Ed-QN; Wed, 11 Oct 2006 12:12:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXghR-0002EX-5u
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:12:53 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXghP-0004dX-Sg
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:12:53 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 11 Oct 2006 18:12:51 +0200
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.20060308/8.12.11) with ESMTP id
	k9BGCph5012951; Wed, 11 Oct 2006 18:12:51 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9BGComd001238; 
	Wed, 11 Oct 2006 18:12:50 +0200 (MEST)
Received: from [10.61.80.155] (ams3-vpn-dhcp4252.cisco.com [10.61.80.155])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA19698;
	Wed, 11 Oct 2006 17:12:49 +0100 (BST)
Message-ID: <452D1800.7010508@cisco.com>
Date: Wed, 11 Oct 2006 17:12:48 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=532; t=1160583171; x=1161447171;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20observation=20domain, =20template,
	=20and=20session=3A=2 0compromise;
	X=v=3Dcisco.com=3B=20h=3DQe/1wLq0bolv8CevZZxHTWF7Bmw=3D;
	b=CRT76D8NcdjWYSa13uW59HqvW9VTHSnJwsvWi9IumTQvCXVsjV3/6w5oRXKN9MibuWh+5Pve
	iGU1g4gR+obLu/739Xp2VfegsLXqFN2fLHfaid3NR9BmM9p7i+SxAqBO;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

> In UDP, the transport session is known as the UDP session, which is  
> uniquely identified by the IP addresses and UDP ports used, within  the 
> time between the first UDP packet sent by the EP in the session  and the 
> timeout after the last template retransmission.

Seems good to me. But change "last" to "latest" or "most recent".

Someone once asked me how we know it's the "last packet". We don't; we 
mean "last seen so far", aka "latest".

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Wed Oct 11 12:15:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXgjX-0003W3-UD; Wed, 11 Oct 2006 12:15:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgjW-0003Vx-BP
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:15:02 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgjV-0004st-2i
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:15:02 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9BGEwK4029883 for ; Wed, 11 Oct 2006 12:14:58 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9BGEcZO029870
	for ; Wed, 11 Oct 2006 12:14:38 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9BGEcbK029868;
	Wed, 11 Oct 2006 12:14:38 -0400 (EDT)
Received: from [172.28.173.116] (vpn-10-25-4-22.remote.cert.org [10.25.4.22])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9BGEbY5007835; Wed, 11 Oct 2006 12:14:37 -0400
In-Reply-To: <452D1800.7010508@cisco.com>
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452D1800.7010508@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <775B784D-37BC-4322-9E5C-283643AEBD7A@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Wed, 11 Oct 2006 09:14:03 -0700
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul,

Yep; this is much better.

- Brian

On Oct 11, 2006, at 9:12 AM, Paul Aitken wrote:

> Brian,
>
>> In UDP, the transport session is known as the UDP session, which  
>> is  uniquely identified by the IP addresses and UDP ports used,  
>> within  the time between the first UDP packet sent by the EP in  
>> the session  and the timeout after the last template retransmission.
>
> Seems good to me. But change "last" to "latest" or "most recent".
>
> Someone once asked me how we know it's the "last packet". We don't;  
> we mean "last seen so far", aka "latest".
>
> -- 
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.


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



From ipfix-bounces@ietf.org Wed Oct 11 12:15:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXgjX-0003W3-UD; Wed, 11 Oct 2006 12:15:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgjW-0003Vx-BP
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:15:02 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgjV-0004st-2i
	for ipfix@ietf.org; Wed, 11 Oct 2006 12:15:02 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9BGEwK4029883 for ; Wed, 11 Oct 2006 12:14:58 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9BGEcZO029870
	for ; Wed, 11 Oct 2006 12:14:38 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9BGEcbK029868;
	Wed, 11 Oct 2006 12:14:38 -0400 (EDT)
Received: from [172.28.173.116] (vpn-10-25-4-22.remote.cert.org [10.25.4.22])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9BGEbY5007835; Wed, 11 Oct 2006 12:14:37 -0400
In-Reply-To: <452D1800.7010508@cisco.com>
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452D1800.7010508@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <775B784D-37BC-4322-9E5C-283643AEBD7A@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Wed, 11 Oct 2006 09:14:03 -0700
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul,

Yep; this is much better.

- Brian

On Oct 11, 2006, at 9:12 AM, Paul Aitken wrote:

> Brian,
>
>> In UDP, the transport session is known as the UDP session, which  
>> is  uniquely identified by the IP addresses and UDP ports used,  
>> within  the time between the first UDP packet sent by the EP in  
>> the session  and the timeout after the last template retransmission.
>
> Seems good to me. But change "last" to "latest" or "most recent".
>
> Someone once asked me how we know it's the "last packet". We don't;  
> we mean "last seen so far", aka "latest".
>
> -- 
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.


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



From ipfix-bounces@ietf.org Wed Oct 11 13:05:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXhV8-00048U-E3; Wed, 11 Oct 2006 13:04:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhV6-00048L-JA
	for ipfix@ietf.org; Wed, 11 Oct 2006 13:04:12 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXhV4-0003m2-SP
	for ipfix@ietf.org; Wed, 11 Oct 2006 13:04:12 -0400
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
	k9BH49N11416; Wed, 11 Oct 2006 19:04:09 +0200 (CEST)
Received: from [10.61.65.22] (ams3-vpn-dhcp278.cisco.com [10.61.65.22])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9BH48P15389; Wed, 11 Oct 2006 19:04:08 +0200 (CEST)
Message-ID: <452D2408.3020300@cisco.com>
Date: Wed, 11 Oct 2006 19:04:08 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 025f8c5000216988bfe31585db759250
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,
> Benoit and all,
>
> Excellent - this looks good to me, and addresses all the concerns I 
> had with scoping templates and observation IDs (and as you point out, 
> has the added benefit of minimal change to the protocol as it stands).
Good.
>
> One point: do we want to be more pedantic about defining a Transport 
> Session for UDP? Both the SCTP and TCP Transport Session definitions 
> have temporal limits (the Association or the Connection lifetime, 
> defined by each transport protocol itself), while UDP does not. I 
> would suggest (from a past message to the list):
>
> In UDP, the transport session is known as the UDP session, which is 
> uniquely identified by the IP addresses and UDP ports used, within the 
> time between the first UDP packet sent by the EP in the session and 
> the timeout after the last template retransmission.
Which timeout? (options) template retransmission? template lifetime? 3 
times template lifetime?
Where: Exporter and/or Collector?

Regards, Benoit.
>
> Thoughts?
>
> - Brian
>
> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently 
>> regarding "observation domain, template, and session", Andrew, Paul, 
>> and I sat down and worked out a compromise. We're proposing to make 
>> template IDs unique per (Observation Domain ID, Session) pair. And 
>> NOT to scope the Observation Domain to the communication session 
>> between the Exporting Process and Collecting Process (as proposed by 
>> Andrew initially)
>> I think that this compromise will make everybody happy as this 
>> solution is mainly a clarification, as opposed to a protocol design 
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I 
>> see that the Template Ids are unique per Observation Domain, and that 
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX 
>> Device, this implies that the several Exporting Processes of the same 
>> IPFIX Device must synchronize the assignments of their Template Ids 
>> (to make sure that the Template Id are unique per Observation 
>> Domain). This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template 
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local 
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it 
>> would be nice to have the same template IDs between two connections. 
>> The solution in this case is to use a single E.P. when load-balancing 
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements 
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, 
>> which is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, 
>> the transport session is known as the TCP connection, which is 
>> uniquely identified by the combination of IP addresses and TCP ports 
>> used; In UDP, the transport session is known as the UDP session, 
>> which is uniquely identified by the combination of IP addresses and 
>> UDP ports used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session 
>> and
>>      Observation Domain that generated the Template ID.  Template IDs 
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This 
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting 
>> Processes SHOULD use the combination of the Exporter 
>> (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and 
>> the Observation Domain ID field to separate different export streams 
>> originating from the same Exporting Process.  The Observation Domain 
>> ID SHOULD be 0 when no specific Observation Domain ID is relevant for 
>> the entire IPFIX Message.  For example, when exporting the Exporting 
>> Process Statistics, or in case of hierarchy of Collector when 
>> aggregated data records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting 
>> Processes SHOULD use the Transport Session and the Observation Domain 
>> ID field to separate different export streams originating from the 
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when 
>> no specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the 
>> Exporter's Observation Domains. A newly created Template Record is 
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP 
>> association for the Exporter's Observation Domains.  A newly created 
>> Template Record is assigned an unused Template ID by the Exporting 
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different 
>> Observation Domains from the same Exporter may use the same Template 
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use 
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association 
>> shutdown, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process 
>> restarts, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain.  
>> If the Collecting Process receives a Template which has already been 
>> received but which has not previously been withdrawn (i.e. a Template 
>> Record from the same Exporter Observation Domain with the same 
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation 
>> Domain.  If the Collecting Process receives a Template which has 
>> already been received but which has not previously been withdrawn 
>> (i.e. a Template Record from the same Exporter Observation Domain 
>> with the same Template ID received on the SCTP association), then the 
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific Exporter and specific Observation 
>> Domain, and stop decoding IPFIX Messages that use the withdrawn 
>> Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before, it MUST reset the SCTP 
>> association, discard the IPFIX Message, and SHOULD log the error as 
>> it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains from the same Exporter MUST be aware that the 
>> uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific SCTP association and specific 
>> Observation Domain, and stop decoding IPFIX Messages that use the 
>> withdrawn Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before on this SCTP assocation, 
>> it MUST reset the SCTP association, discard the IPFIX Message, and 
>> SHOULD log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains on the same Transport Session MUST be aware that 
>> the uniqueness of the Template ID is not guaranteed across 
>> Observation Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the 
>> following for all the current Template Records and Options Template 
>> Records: > Template Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain.  
>> At any given time the Collecting Process SHOULD maintain the 
>> following for all the current Template Records and Options Template 
>> Records: > ID, Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation 
>> Domain.  A Collecting Process MUST record all Template and Options 
>> Template Records for the duration of the connection, as an Exporting 
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, 
>> which is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, 
>> the transport session is known as the TCP connection, which is 
>> uniquely identified by the combination of IP addresses and TCP ports 
>> used; In UDP, the transport session is known as the UDP session, 
>> which is uniquely identified by the combination of IP addresses and 
>> UDP ports used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that 
>> is locally unique within an Observation Domain. NEW 5.1.8. templateId 
>> Description: An identifier of a Template that is locally unique 
>> within an Observation Domain and the Transport Session. OLD 5.1.7. 
>> flowId Description: An identifier of a Flow that is unique within an 
>> Observation Domain. This Information Element can be used to 
>> distinguish between different Flows if Flow Keys such as IP addresses 
>> and port numbers are not reported or are reported in separate 
>> records. NEW 5.1.7. flowId Description: An identifier of a Flow that 
>> is unique within an Observation Domain and the Transport Session. 
>> This Information Element can be used to distinguish between different 
>> Flows if Flow Keys such as IP addresses and port numbers are not 
>> reported or are reported in separate records. OLD 5.1.11. 
>> commonPropertiesId Description: An identifier of a set of common 
>> properties that is unique per Observation Domain. Typically, this 
>> Information Element is used to link to information reported in 
>> separate records. NEW: 5.1.11. commonPropertiesId Description: An 
>> identifier of a set of common properties that is unique per 
>> Observation Domain and Transport Session. Typically, this Information 
>> Element is used to link to information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Wed Oct 11 13:05:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXhV8-00048U-E3; Wed, 11 Oct 2006 13:04:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhV6-00048L-JA
	for ipfix@ietf.org; Wed, 11 Oct 2006 13:04:12 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXhV4-0003m2-SP
	for ipfix@ietf.org; Wed, 11 Oct 2006 13:04:12 -0400
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
	k9BH49N11416; Wed, 11 Oct 2006 19:04:09 +0200 (CEST)
Received: from [10.61.65.22] (ams3-vpn-dhcp278.cisco.com [10.61.65.22])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9BH48P15389; Wed, 11 Oct 2006 19:04:08 +0200 (CEST)
Message-ID: <452D2408.3020300@cisco.com>
Date: Wed, 11 Oct 2006 19:04:08 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 025f8c5000216988bfe31585db759250
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,
> Benoit and all,
>
> Excellent - this looks good to me, and addresses all the concerns I 
> had with scoping templates and observation IDs (and as you point out, 
> has the added benefit of minimal change to the protocol as it stands).
Good.
>
> One point: do we want to be more pedantic about defining a Transport 
> Session for UDP? Both the SCTP and TCP Transport Session definitions 
> have temporal limits (the Association or the Connection lifetime, 
> defined by each transport protocol itself), while UDP does not. I 
> would suggest (from a past message to the list):
>
> In UDP, the transport session is known as the UDP session, which is 
> uniquely identified by the IP addresses and UDP ports used, within the 
> time between the first UDP packet sent by the EP in the session and 
> the timeout after the last template retransmission.
Which timeout? (options) template retransmission? template lifetime? 3 
times template lifetime?
Where: Exporter and/or Collector?

Regards, Benoit.
>
> Thoughts?
>
> - Brian
>
> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently 
>> regarding "observation domain, template, and session", Andrew, Paul, 
>> and I sat down and worked out a compromise. We're proposing to make 
>> template IDs unique per (Observation Domain ID, Session) pair. And 
>> NOT to scope the Observation Domain to the communication session 
>> between the Exporting Process and Collecting Process (as proposed by 
>> Andrew initially)
>> I think that this compromise will make everybody happy as this 
>> solution is mainly a clarification, as opposed to a protocol design 
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I 
>> see that the Template Ids are unique per Observation Domain, and that 
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX 
>> Device, this implies that the several Exporting Processes of the same 
>> IPFIX Device must synchronize the assignments of their Template Ids 
>> (to make sure that the Template Id are unique per Observation 
>> Domain). This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template 
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local 
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it 
>> would be nice to have the same template IDs between two connections. 
>> The solution in this case is to use a single E.P. when load-balancing 
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements 
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, 
>> which is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, 
>> the transport session is known as the TCP connection, which is 
>> uniquely identified by the combination of IP addresses and TCP ports 
>> used; In UDP, the transport session is known as the UDP session, 
>> which is uniquely identified by the combination of IP addresses and 
>> UDP ports used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session 
>> and
>>      Observation Domain that generated the Template ID.  Template IDs 
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This 
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting 
>> Processes SHOULD use the combination of the Exporter 
>> (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and 
>> the Observation Domain ID field to separate different export streams 
>> originating from the same Exporting Process.  The Observation Domain 
>> ID SHOULD be 0 when no specific Observation Domain ID is relevant for 
>> the entire IPFIX Message.  For example, when exporting the Exporting 
>> Process Statistics, or in case of hierarchy of Collector when 
>> aggregated data records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting 
>> Processes SHOULD use the Transport Session and the Observation Domain 
>> ID field to separate different export streams originating from the 
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when 
>> no specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the 
>> Exporter's Observation Domains. A newly created Template Record is 
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP 
>> association for the Exporter's Observation Domains.  A newly created 
>> Template Record is assigned an unused Template ID by the Exporting 
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different 
>> Observation Domains from the same Exporter may use the same Template 
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use 
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association 
>> shutdown, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process 
>> restarts, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain.  
>> If the Collecting Process receives a Template which has already been 
>> received but which has not previously been withdrawn (i.e. a Template 
>> Record from the same Exporter Observation Domain with the same 
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation 
>> Domain.  If the Collecting Process receives a Template which has 
>> already been received but which has not previously been withdrawn 
>> (i.e. a Template Record from the same Exporter Observation Domain 
>> with the same Template ID received on the SCTP association), then the 
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific Exporter and specific Observation 
>> Domain, and stop decoding IPFIX Messages that use the withdrawn 
>> Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before, it MUST reset the SCTP 
>> association, discard the IPFIX Message, and SHOULD log the error as 
>> it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains from the same Exporter MUST be aware that the 
>> uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific SCTP association and specific 
>> Observation Domain, and stop decoding IPFIX Messages that use the 
>> withdrawn Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before on this SCTP assocation, 
>> it MUST reset the SCTP association, discard the IPFIX Message, and 
>> SHOULD log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains on the same Transport Session MUST be aware that 
>> the uniqueness of the Template ID is not guaranteed across 
>> Observation Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the 
>> following for all the current Template Records and Options Template 
>> Records: > Template Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain.  
>> At any given time the Collecting Process SHOULD maintain the 
>> following for all the current Template Records and Options Template 
>> Records: > ID, Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation 
>> Domain.  A Collecting Process MUST record all Template and Options 
>> Template Records for the duration of the connection, as an Exporting 
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, 
>> which is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, 
>> the transport session is known as the TCP connection, which is 
>> uniquely identified by the combination of IP addresses and TCP ports 
>> used; In UDP, the transport session is known as the UDP session, 
>> which is uniquely identified by the combination of IP addresses and 
>> UDP ports used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that 
>> is locally unique within an Observation Domain. NEW 5.1.8. templateId 
>> Description: An identifier of a Template that is locally unique 
>> within an Observation Domain and the Transport Session. OLD 5.1.7. 
>> flowId Description: An identifier of a Flow that is unique within an 
>> Observation Domain. This Information Element can be used to 
>> distinguish between different Flows if Flow Keys such as IP addresses 
>> and port numbers are not reported or are reported in separate 
>> records. NEW 5.1.7. flowId Description: An identifier of a Flow that 
>> is unique within an Observation Domain and the Transport Session. 
>> This Information Element can be used to distinguish between different 
>> Flows if Flow Keys such as IP addresses and port numbers are not 
>> reported or are reported in separate records. OLD 5.1.11. 
>> commonPropertiesId Description: An identifier of a set of common 
>> properties that is unique per Observation Domain. Typically, this 
>> Information Element is used to link to information reported in 
>> separate records. NEW: 5.1.11. commonPropertiesId Description: An 
>> identifier of a set of common properties that is unique per 
>> Observation Domain and Transport Session. Typically, this Information 
>> Element is used to link to information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Thu Oct 12 04:31:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXvxA-0005xC-IH; Thu, 12 Oct 2006 04:30:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvx9-0005wu-Db
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:08 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvx6-0007in-6C
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:07 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 12 Oct 2006 10:29:35 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AY8CAJKYLUU
X-IronPort-AV: i="4.09,298,1157320800"; 
	d="scan'208"; a="113427517:sNHT9196157832"
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.20060308/8.12.11) with ESMTP id
	k9C8TYDs029171; Thu, 12 Oct 2006 10:29:34 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9C8TWmd008331; 
	Thu, 12 Oct 2006 10:29:34 +0200 (MEST)
Received: from [10.61.80.44] (ams3-vpn-dhcp4141.cisco.com [10.61.80.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA04163;
	Thu, 12 Oct 2006 09:29:31 +0100 (BST)
Message-ID: <452DFCCC.8020003@cisco.com>
Date: Thu, 12 Oct 2006 09:29:00 +0100
From: Andrew Johnson 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=16146; t=1160641774; x=1161505774;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andrjohn@cisco.com;
	z=From:Andrew=20Johnson=20
	|Subject:Re=3A=20[IPFIX]=20observation=20domain, =20template,
	=20and=20session=3A=2 0compromise;
	X=v=3Dcisco.com=3B=20h=3DgZxGvSV5b5FwTJSN+bdOW4Invrs=3D;
	b=mp4BqI7vTbCXdZx1h+3jzmfkjZUghyNn9Q6D1605WNcAKiQbAx9see1DEOps97cdbhu4BIqr
	xSS8qgjjQaMo32rhHqsrOxiBxKPyCu85e0BwTGHOWItyz/xbHprc++G9;
Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian Trammell wrote:
> Benoit and all,
> 
> Excellent - this looks good to me, and addresses all the concerns I had 
> with scoping templates and observation IDs (and as you point out, has 
> the added benefit of minimal change to the protocol as it stands).
> 
> One point: do we want to be more pedantic about defining a Transport 
> Session for UDP? Both the SCTP and TCP Transport Session definitions 
> have temporal limits (the Association or the Connection lifetime, 
> defined by each transport protocol itself), while UDP does not. I would 
> suggest (from a past message to the list):
> 
> In UDP, the transport session is known as the UDP session, which is 
> uniquely identified by the IP addresses and UDP ports used, within the 
> time between the first UDP packet sent by the EP in the session and the 
> timeout after the last template retransmission.
> 
> Thoughts?

In UDP the definition associated with a template ID has a certain
lifetime.  The lifetime is different on the the Exporting Process and
the Collecting Process.  I think we can simply extend the principle
to apply to all definitions associated with identifiers that are
scoped to the Transport Session.

I think only one section would need updated.


10.3.7  Collecting Process

OLD:
   The Collecting Process MUST associate a lifetime with each Template
   received via UDP.  Templates not refreshed by the Exporting Process
   within the lifetime are expired at the Collecting Process.  If the
   template is not refreshed by the Exporting Process before that
   lifetime has expired, the Collecting Process MUST discard the
   Template and any current and future associated Data Records.  In
   which case, an alarm MUST be logged.
   ...
   The Collecting Process SHOULD accept Data Records without the
   associated Template Record. If the Template Records have not been
   received at the time Data Records are received, the Collecting
   Process SHOULD store the Data Records for a short period of time and
   decode them after the Template Records are received.  The short
   period of time MUST be lower than the Template lifetime.

NEW:
   The Collecting Process MUST associate a lifetime with each Template
   (or another of definition of an identifier considered unique within
   the Transport Session) received via UDP.  Templates (and similar
   definitions) not refreshed by the Exporting Process within the
   lifetime are expired at the Collecting Process.  If the Template
   (or other definition) is not refreshed before that lifetime has
   expired, the Collecting Process MUST discard that definition
   and any current and future associated Data Records.  In which case,
   an alarm MUST be logged.
   ...
   The Collecting Process SHOULD accept Data Records without the
   associated Template Record (or other definitions) required to decode
   the Data Record. If the Template Records (or other definitions such as
   Common Properties) have not been received at the time Data Records
   are received, the Collecting Process SHOULD store the Data Records
   for a short period of time and decode them after the Template Records
   (or other definitions) are received. The short period of time MUST be
   lower than the lifetime of definitions associated with identifiers
   considered unique within the UDP session. 


regards

Andrew 


> 
> - Brian
> 
> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
> 
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently 
>> regarding "observation domain, template, and session", Andrew, Paul, 
>> and I sat down and worked out a compromise. We're proposing to make 
>> template IDs unique per (Observation Domain ID, Session) pair. And NOT 
>> to scope the Observation Domain to the communication session between 
>> the Exporting Process and Collecting Process (as proposed by Andrew 
>> initially)
>> I think that this compromise will make everybody happy as this 
>> solution is mainly a clarification, as opposed to a protocol design 
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I 
>> see that the Template Ids are unique per Observation Domain, and that 
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX 
>> Device, this implies that the several Exporting Processes of the same 
>> IPFIX Device must synchronize the assignments of their Template Ids 
>> (to make sure that the Template Id are unique per Observation Domain). 
>> This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template 
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local 
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it 
>> would be nice to have the same template IDs between two connections. 
>> The solution in this case is to use a single E.P. when load-balancing 
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements 
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, which 
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
>> transport session is known as the TCP connection, which is uniquely 
>> identified by the combination of IP addresses and TCP ports used; In 
>> UDP, the transport session is known as the UDP session, which is 
>> uniquely identified by the combination of IP addresses and UDP ports 
>> used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session and
>>      Observation Domain that generated the Template ID.  Template IDs 
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This 
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting Processes 
>> SHOULD use the combination of the Exporter (exporterIPv4Address, 
>> exporterIPv6Address, or exportingProcessId) and the Observation Domain 
>> ID field to separate different export streams originating from the 
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no 
>> specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting Processes 
>> SHOULD use the Transport Session and the Observation Domain ID field 
>> to separate different export streams originating from the same 
>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no 
>> specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the 
>> Exporter's Observation Domains. A newly created Template Record is 
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP 
>> association for the Exporter's Observation Domains.  A newly created 
>> Template Record is assigned an unused Template ID by the Exporting 
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different 
>> Observation Domains from the same Exporter may use the same Template 
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use 
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association 
>> shutdown, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process 
>> restarts, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain.  
>> If the Collecting Process receives a Template which has already been 
>> received but which has not previously been withdrawn (i.e. a Template 
>> Record from the same Exporter Observation Domain with the same 
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation 
>> Domain.  If the Collecting Process receives a Template which has 
>> already been received but which has not previously been withdrawn 
>> (i.e. a Template Record from the same Exporter Observation Domain with 
>> the same Template ID received on the SCTP association), then the 
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific Exporter and specific Observation Domain, 
>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before, it MUST reset the SCTP 
>> association, discard the IPFIX Message, and SHOULD log the error as it 
>> does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains from the same Exporter MUST be aware that the 
>> uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific SCTP association and specific Observation 
>> Domain, and stop decoding IPFIX Messages that use the withdrawn 
>> Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before on this SCTP assocation, it 
>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD 
>> log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains on the same Transport Session MUST be aware that 
>> the uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the following 
>> for all the current Template Records and Options Template Records: 
>> > Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain.  
>> At any given time the Collecting Process SHOULD maintain the following 
>> for all the current Template Records and Options Template Records: 
>> > Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation 
>> Domain.  A Collecting Process MUST record all Template and Options 
>> Template Records for the duration of the connection, as an Exporting 
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, which 
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
>> transport session is known as the TCP connection, which is uniquely 
>> identified by the combination of IP addresses and TCP ports used; In 
>> UDP, the transport session is known as the UDP session, which is 
>> uniquely identified by the combination of IP addresses and UDP ports 
>> used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that is 
>> locally unique within an Observation Domain. NEW 5.1.8. templateId 
>> Description: An identifier of a Template that is locally unique within 
>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId 
>> Description: An identifier of a Flow that is unique within an 
>> Observation Domain. This Information Element can be used to 
>> distinguish between different Flows if Flow Keys such as IP addresses 
>> and port numbers are not reported or are reported in separate records. 
>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique 
>> within an Observation Domain and the Transport Session. This 
>> Information Element can be used to distinguish between different Flows 
>> if Flow Keys such as IP addresses and port numbers are not reported or 
>> are reported in separate records. OLD 5.1.11. commonPropertiesId 
>> Description: An identifier of a set of common properties that is 
>> unique per Observation Domain. Typically, this Information Element is 
>> used to link to information reported in separate records. NEW: 5.1.11. 
>> commonPropertiesId Description: An identifier of a set of common 
>> properties that is unique per Observation Domain and Transport 
>> Session. Typically, this Information Element is used to link to 
>> information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

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



From ipfix-bounces@ietf.org Thu Oct 12 04:31:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXvxA-0005xC-IH; Thu, 12 Oct 2006 04:30:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvx9-0005wu-Db
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:08 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvx6-0007in-6C
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:07 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 12 Oct 2006 10:29:35 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AY8CAJKYLUU
X-IronPort-AV: i="4.09,298,1157320800"; 
	d="scan'208"; a="113427517:sNHT9196157832"
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.20060308/8.12.11) with ESMTP id
	k9C8TYDs029171; Thu, 12 Oct 2006 10:29:34 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9C8TWmd008331; 
	Thu, 12 Oct 2006 10:29:34 +0200 (MEST)
Received: from [10.61.80.44] (ams3-vpn-dhcp4141.cisco.com [10.61.80.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA04163;
	Thu, 12 Oct 2006 09:29:31 +0100 (BST)
Message-ID: <452DFCCC.8020003@cisco.com>
Date: Thu, 12 Oct 2006 09:29:00 +0100
From: Andrew Johnson 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=16146; t=1160641774; x=1161505774;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andrjohn@cisco.com;
	z=From:Andrew=20Johnson=20
	|Subject:Re=3A=20[IPFIX]=20observation=20domain, =20template,
	=20and=20session=3A=2 0compromise;
	X=v=3Dcisco.com=3B=20h=3DgZxGvSV5b5FwTJSN+bdOW4Invrs=3D;
	b=mp4BqI7vTbCXdZx1h+3jzmfkjZUghyNn9Q6D1605WNcAKiQbAx9see1DEOps97cdbhu4BIqr
	xSS8qgjjQaMo32rhHqsrOxiBxKPyCu85e0BwTGHOWItyz/xbHprc++G9;
Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian Trammell wrote:
> Benoit and all,
> 
> Excellent - this looks good to me, and addresses all the concerns I had 
> with scoping templates and observation IDs (and as you point out, has 
> the added benefit of minimal change to the protocol as it stands).
> 
> One point: do we want to be more pedantic about defining a Transport 
> Session for UDP? Both the SCTP and TCP Transport Session definitions 
> have temporal limits (the Association or the Connection lifetime, 
> defined by each transport protocol itself), while UDP does not. I would 
> suggest (from a past message to the list):
> 
> In UDP, the transport session is known as the UDP session, which is 
> uniquely identified by the IP addresses and UDP ports used, within the 
> time between the first UDP packet sent by the EP in the session and the 
> timeout after the last template retransmission.
> 
> Thoughts?

In UDP the definition associated with a template ID has a certain
lifetime.  The lifetime is different on the the Exporting Process and
the Collecting Process.  I think we can simply extend the principle
to apply to all definitions associated with identifiers that are
scoped to the Transport Session.

I think only one section would need updated.


10.3.7  Collecting Process

OLD:
   The Collecting Process MUST associate a lifetime with each Template
   received via UDP.  Templates not refreshed by the Exporting Process
   within the lifetime are expired at the Collecting Process.  If the
   template is not refreshed by the Exporting Process before that
   lifetime has expired, the Collecting Process MUST discard the
   Template and any current and future associated Data Records.  In
   which case, an alarm MUST be logged.
   ...
   The Collecting Process SHOULD accept Data Records without the
   associated Template Record. If the Template Records have not been
   received at the time Data Records are received, the Collecting
   Process SHOULD store the Data Records for a short period of time and
   decode them after the Template Records are received.  The short
   period of time MUST be lower than the Template lifetime.

NEW:
   The Collecting Process MUST associate a lifetime with each Template
   (or another of definition of an identifier considered unique within
   the Transport Session) received via UDP.  Templates (and similar
   definitions) not refreshed by the Exporting Process within the
   lifetime are expired at the Collecting Process.  If the Template
   (or other definition) is not refreshed before that lifetime has
   expired, the Collecting Process MUST discard that definition
   and any current and future associated Data Records.  In which case,
   an alarm MUST be logged.
   ...
   The Collecting Process SHOULD accept Data Records without the
   associated Template Record (or other definitions) required to decode
   the Data Record. If the Template Records (or other definitions such as
   Common Properties) have not been received at the time Data Records
   are received, the Collecting Process SHOULD store the Data Records
   for a short period of time and decode them after the Template Records
   (or other definitions) are received. The short period of time MUST be
   lower than the lifetime of definitions associated with identifiers
   considered unique within the UDP session. 


regards

Andrew 


> 
> - Brian
> 
> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
> 
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently 
>> regarding "observation domain, template, and session", Andrew, Paul, 
>> and I sat down and worked out a compromise. We're proposing to make 
>> template IDs unique per (Observation Domain ID, Session) pair. And NOT 
>> to scope the Observation Domain to the communication session between 
>> the Exporting Process and Collecting Process (as proposed by Andrew 
>> initially)
>> I think that this compromise will make everybody happy as this 
>> solution is mainly a clarification, as opposed to a protocol design 
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I 
>> see that the Template Ids are unique per Observation Domain, and that 
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX 
>> Device, this implies that the several Exporting Processes of the same 
>> IPFIX Device must synchronize the assignments of their Template Ids 
>> (to make sure that the Template Id are unique per Observation Domain). 
>> This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template 
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local 
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it 
>> would be nice to have the same template IDs between two connections. 
>> The solution in this case is to use a single E.P. when load-balancing 
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements 
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, which 
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
>> transport session is known as the TCP connection, which is uniquely 
>> identified by the combination of IP addresses and TCP ports used; In 
>> UDP, the transport session is known as the UDP session, which is 
>> uniquely identified by the combination of IP addresses and UDP ports 
>> used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session and
>>      Observation Domain that generated the Template ID.  Template IDs 
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This 
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting Processes 
>> SHOULD use the combination of the Exporter (exporterIPv4Address, 
>> exporterIPv6Address, or exportingProcessId) and the Observation Domain 
>> ID field to separate different export streams originating from the 
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no 
>> specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique 
>> to the Exporting Process.  The Exporting Process uses the Observation 
>> Domain ID to uniquely identify to the Collecting Process the 
>> Observation Domain that metered the Flows.  It is RECOMMENDED that 
>> this identifier is also unique per IPFIX Device.  Collecting Processes 
>> SHOULD use the Transport Session and the Observation Domain ID field 
>> to separate different export streams originating from the same 
>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no 
>> specific Observation Domain ID is relevant for the entire IPFIX 
>> Message.  For example, when exporting the Exporting Process 
>> Statistics, or in case of hierarchy of Collector when aggregated data 
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the 
>> Exporter's Observation Domains. A newly created Template Record is 
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP 
>> association for the Exporter's Observation Domains.  A newly created 
>> Template Record is assigned an unused Template ID by the Exporting 
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different 
>> Observation Domains from the same Exporter may use the same Template 
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use 
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association 
>> shutdown, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process 
>> restarts, all Template assignments are lost and Template IDs MUST be 
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain.  
>> If the Collecting Process receives a Template which has already been 
>> received but which has not previously been withdrawn (i.e. a Template 
>> Record from the same Exporter Observation Domain with the same 
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation 
>> Domain.  If the Collecting Process receives a Template which has 
>> already been received but which has not previously been withdrawn 
>> (i.e. a Template Record from the same Exporter Observation Domain with 
>> the same Template ID received on the SCTP association), then the 
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific Exporter and specific Observation Domain, 
>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before, it MUST reset the SCTP 
>> association, discard the IPFIX Message, and SHOULD log the error as it 
>> does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains from the same Exporter MUST be aware that the 
>> uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the 
>> Collecting Process MUST delete the corresponding Template Records 
>> associated with the specific SCTP association and specific Observation 
>> Domain, and stop decoding IPFIX Messages that use the withdrawn 
>> Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a 
>> Template Record it has not received before on this SCTP assocation, it 
>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD 
>> log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several 
>> Observation Domains on the same Transport Session MUST be aware that 
>> the uniqueness of the Template ID is not guaranteed across Observation 
>> Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the following 
>> for all the current Template Records and Options Template Records: 
>> > Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain.  
>> At any given time the Collecting Process SHOULD maintain the following 
>> for all the current Template Records and Options Template Records: 
>> > Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation 
>> Domain.  A Collecting Process MUST record all Template and Options 
>> Template Records for the duration of the connection, as an Exporting 
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, which 
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the 
>> transport session is known as the TCP connection, which is uniquely 
>> identified by the combination of IP addresses and TCP ports used; In 
>> UDP, the transport session is known as the UDP session, which is 
>> uniquely identified by the combination of IP addresses and UDP ports 
>> used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that is 
>> locally unique within an Observation Domain. NEW 5.1.8. templateId 
>> Description: An identifier of a Template that is locally unique within 
>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId 
>> Description: An identifier of a Flow that is unique within an 
>> Observation Domain. This Information Element can be used to 
>> distinguish between different Flows if Flow Keys such as IP addresses 
>> and port numbers are not reported or are reported in separate records. 
>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique 
>> within an Observation Domain and the Transport Session. This 
>> Information Element can be used to distinguish between different Flows 
>> if Flow Keys such as IP addresses and port numbers are not reported or 
>> are reported in separate records. OLD 5.1.11. commonPropertiesId 
>> Description: An identifier of a set of common properties that is 
>> unique per Observation Domain. Typically, this Information Element is 
>> used to link to information reported in separate records. NEW: 5.1.11. 
>> commonPropertiesId Description: An identifier of a set of common 
>> properties that is unique per Observation Domain and Transport 
>> Session. Typically, this Information Element is used to link to 
>> information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

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



From ipfix-bounces@ietf.org Thu Oct 12 04:31:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXvxY-0006kh-WB; Thu, 12 Oct 2006 04:30:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvxY-0006kc-4Q
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:32 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvxU-0008E4-UI
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:31 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7A7CF125
	for ; Thu, 12 Oct 2006 10:30:27 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
	by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 14922-04 for ; Thu, 12 Oct 2006 10:30:25 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D304511C
	for ; Thu, 12 Oct 2006 10:30:24 +0200 (MST)
Message-ID: <452DFD63.7050900@informatik.uni-tuebingen.de>
Date: Thu, 12 Oct 2006 10:31:31 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4515df9441674711565101d9d5c4f63f
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Brian, All,

I also agree with the proposed changes.

Brian Trammell wrote:
> One point: do we want to be more pedantic about defining a Transport
> Session for UDP? Both the SCTP and TCP Transport Session definitions
> have temporal limits (the Association or the Connection lifetime,
> defined by each transport protocol itself), while UDP does not. I would
> suggest (from a past message to the list):
> 
> In UDP, the transport session is known as the UDP session, which is
> uniquely identified by the IP addresses and UDP ports used, within the
> time between the first UDP packet sent by the EP in the session and the
> timeout after the last template retransmission.

Fine with me. So using UDP, both templates and obervation domains are
"soft states" with limited lifetime unless they are renewed.

One question which is orthogonal but related:
The proposed IPFIX configuration data model
http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
covers the case when the observation domain ID is configurable.
Currently, the observation domain ID is a parameter of the observation
point.
What are your opinions? Is this the right place?
Or do you prefer to have an observation domain ID paramater per
exporting process?
Or both (so it can be adapted to the implementation of the device)?

Regards,
Gerhard



> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
> 
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently
>> regarding "observation domain, template, and session", Andrew, Paul,
>> and I sat down and worked out a compromise. We're proposing to make
>> template IDs unique per (Observation Domain ID, Session) pair. And NOT
>> to scope the Observation Domain to the communication session between
>> the Exporting Process and Collecting Process (as proposed by Andrew
>> initially)
>> I think that this compromise will make everybody happy as this
>> solution is mainly a clarification, as opposed to a protocol design
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I
>> see that the Template Ids are unique per Observation Domain, and that
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX
>> Device, this implies that the several Exporting Processes of the same
>> IPFIX Device must synchronize the assignments of their Template Ids
>> (to make sure that the Template Id are unique per Observation Domain).
>> This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it
>> would be nice to have the same template IDs between two connections.
>> The solution in this case is to use a single E.P. when load-balancing
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, which
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>> transport session is known as the TCP connection, which is uniquely
>> identified by the combination of IP addresses and TCP ports used; In
>> UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the combination of IP addresses and UDP ports
>> used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session and
>>      Observation Domain that generated the Template ID.  Template IDs
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique
>> to the Exporting Process.  The Exporting Process uses the Observation
>> Domain ID to uniquely identify to the Collecting Process the
>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>> this identifier is also unique per IPFIX Device.  Collecting Processes
>> SHOULD use the combination of the Exporter (exporterIPv4Address,
>> exporterIPv6Address, or exportingProcessId) and the Observation Domain
>> ID field to separate different export streams originating from the
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>> specific Observation Domain ID is relevant for the entire IPFIX
>> Message.  For example, when exporting the Exporting Process
>> Statistics, or in case of hierarchy of Collector when aggregated data
>> records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique
>> to the Exporting Process.  The Exporting Process uses the Observation
>> Domain ID to uniquely identify to the Collecting Process the
>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>> this identifier is also unique per IPFIX Device.  Collecting Processes
>> SHOULD use the Transport Session and the Observation Domain ID field
>> to separate different export streams originating from the same
>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>> specific Observation Domain ID is relevant for the entire IPFIX
>> Message.  For example, when exporting the Exporting Process
>> Statistics, or in case of hierarchy of Collector when aggregated data
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the
>> Exporter's Observation Domains. A newly created Template Record is
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP
>> association for the Exporter's Observation Domains.  A newly created
>> Template Record is assigned an unused Template ID by the Exporting
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different
>> Observation Domains from the same Exporter may use the same Template
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association
>> shutdown, all Template assignments are lost and Template IDs MUST be
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process
>> restarts, all Template assignments are lost and Template IDs MUST be
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain. 
>> If the Collecting Process receives a Template which has already been
>> received but which has not previously been withdrawn (i.e. a Template
>> Record from the same Exporter Observation Domain with the same
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation
>> Domain.  If the Collecting Process receives a Template which has
>> already been received but which has not previously been withdrawn
>> (i.e. a Template Record from the same Exporter Observation Domain with
>> the same Template ID received on the SCTP association), then the
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the
>> Collecting Process MUST delete the corresponding Template Records
>> associated with the specific Exporter and specific Observation Domain,
>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a
>> Template Record it has not received before, it MUST reset the SCTP
>> association, discard the IPFIX Message, and SHOULD log the error as it
>> does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several
>> Observation Domains from the same Exporter MUST be aware that the
>> uniqueness of the Template ID is not guaranteed across Observation
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the
>> Collecting Process MUST delete the corresponding Template Records
>> associated with the specific SCTP association and specific Observation
>> Domain, and stop decoding IPFIX Messages that use the withdrawn
>> Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a
>> Template Record it has not received before on this SCTP assocation, it
>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
>> log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several
>> Observation Domains on the same Transport Session MUST be aware that
>> the uniqueness of the Template ID is not guaranteed across Observation
>> Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the following
>> for all the current Template Records and Options Template Records:
>> > Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain. 
>> At any given time the Collecting Process SHOULD maintain the following
>> for all the current Template Records and Options Template Records:
>> > Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation
>> Domain.  A Collecting Process MUST record all Template and Options
>> Template Records for the duration of the connection, as an Exporting
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, which
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>> transport session is known as the TCP connection, which is uniquely
>> identified by the combination of IP addresses and TCP ports used; In
>> UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the combination of IP addresses and UDP ports
>> used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that is
>> locally unique within an Observation Domain. NEW 5.1.8. templateId
>> Description: An identifier of a Template that is locally unique within
>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId
>> Description: An identifier of a Flow that is unique within an
>> Observation Domain. This Information Element can be used to
>> distinguish between different Flows if Flow Keys such as IP addresses
>> and port numbers are not reported or are reported in separate records.
>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
>> within an Observation Domain and the Transport Session. This
>> Information Element can be used to distinguish between different Flows
>> if Flow Keys such as IP addresses and port numbers are not reported or
>> are reported in separate records. OLD 5.1.11. commonPropertiesId
>> Description: An identifier of a set of common properties that is
>> unique per Observation Domain. Typically, this Information Element is
>> used to link to information reported in separate records. NEW: 5.1.11.
>> commonPropertiesId Description: An identifier of a set of common
>> properties that is unique per Observation Domain and Transport
>> Session. Typically, this Information Element is used to link to
>> information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Thu Oct 12 04:31:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXvxY-0006kh-WB; Thu, 12 Oct 2006 04:30:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvxY-0006kc-4Q
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:32 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvxU-0008E4-UI
	for ipfix@ietf.org; Thu, 12 Oct 2006 04:30:31 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7A7CF125
	for ; Thu, 12 Oct 2006 10:30:27 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
	by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 14922-04 for ; Thu, 12 Oct 2006 10:30:25 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D304511C
	for ; Thu, 12 Oct 2006 10:30:24 +0200 (MST)
Message-ID: <452DFD63.7050900@informatik.uni-tuebingen.de>
Date: Thu, 12 Oct 2006 10:31:31 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
In-Reply-To: <1BD78849-5790-42C6-9898-43577BC33288@cert.org>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4515df9441674711565101d9d5c4f63f
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Brian, All,

I also agree with the proposed changes.

Brian Trammell wrote:
> One point: do we want to be more pedantic about defining a Transport
> Session for UDP? Both the SCTP and TCP Transport Session definitions
> have temporal limits (the Association or the Connection lifetime,
> defined by each transport protocol itself), while UDP does not. I would
> suggest (from a past message to the list):
> 
> In UDP, the transport session is known as the UDP session, which is
> uniquely identified by the IP addresses and UDP ports used, within the
> time between the first UDP packet sent by the EP in the session and the
> timeout after the last template retransmission.

Fine with me. So using UDP, both templates and obervation domains are
"soft states" with limited lifetime unless they are renewed.

One question which is orthogonal but related:
The proposed IPFIX configuration data model
http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
covers the case when the observation domain ID is configurable.
Currently, the observation domain ID is a parameter of the observation
point.
What are your opinions? Is this the right place?
Or do you prefer to have an observation domain ID paramater per
exporting process?
Or both (so it can be adapted to the implementation of the device)?

Regards,
Gerhard



> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
> 
>> Dear all,
>>
>> Trying to address the concerns posted on the mailing recently
>> regarding "observation domain, template, and session", Andrew, Paul,
>> and I sat down and worked out a compromise. We're proposing to make
>> template IDs unique per (Observation Domain ID, Session) pair. And NOT
>> to scope the Observation Domain to the communication session between
>> the Exporting Process and Collecting Process (as proposed by Andrew
>> initially)
>> I think that this compromise will make everybody happy as this
>> solution is mainly a clarification, as opposed to a protocol design
>> change.
>>
>> Problem Statement.
>> If I read the protocol draft now, one interpretation could be: as I
>> see that the Template Ids are unique per Observation Domain, and that
>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX
>> Device, this implies that the several Exporting Processes of the same
>> IPFIX Device must synchronize the assignments of their Template Ids
>> (to make sure that the Template Id are unique per Observation Domain).
>> This might prove difficult/impossible in some cases.
>> Instead of imposing this, the other solution is to make the template
>> IDs unique per (Observation Domain ID, Session) pair.
>> This makes sense as, logically, the template IDs have only a local
>> significance between E.P. and C.P.
>> Note: I brought up the issue of load-balancing or backup where it
>> would be nice to have the same template IDs between two connections.
>> The solution in this case is to use a single E.P. when load-balancing
>> or backup is required.
>>
>> Please acknowledge that this compromise is fine with you.
>>
>> Note: 3 minor changes are required in the information elements
>> definitions in [IPFIX-INFO]
>>
>> Regards, Andrew, Paul, and Benoit.
>>
>> See below for the proposed changes.
>>
>> [IPFIX-PROTO]
>>
>> NEW:
>> Transport Session
>> In SCTP, the transport session is known as the SCTP association, which
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>> transport session is known as the TCP connection, which is uniquely
>> identified by the combination of IP addresses and TCP ports used; In
>> UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the combination of IP addresses and UDP ports
>> used.
>>
>>
>>
>> OLD
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Observation
>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>>
>> NEW:
>> Template ID
>>       Each of the newly generated Template Records is given a unique
>>       Template ID.  This uniqueness is local to the Transport Session and
>>      Observation Domain that generated the Template ID.  Template IDs
>> 0-255 are
>>       reserved for Template Sets, Options Template Sets, and other
>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>       are numbered from 256 to 65535.  There are no constraints
>>       regarding the order of the Template ID allocation.
>>
>> OLD (Section 4.4)
>>      templateId              An identifier of a Template that
>>                              locally unique to the Exporting
>>                              Process.  This Information
>>                              Element MUST be defined as a Scope
>>                              Field.
>> NEW
>>      templateId              An identifier of a Template. This
>> Information
>>                                    Element MUST be defined as a Scope
>>                                    Field.
>>
>> Section 3.1
>> OLD
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique
>> to the Exporting Process.  The Exporting Process uses the Observation
>> Domain ID to uniquely identify to the Collecting Process the
>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>> this identifier is also unique per IPFIX Device.  Collecting Processes
>> SHOULD use the combination of the Exporter (exporterIPv4Address,
>> exporterIPv6Address, or exportingProcessId) and the Observation Domain
>> ID field to separate different export streams originating from the
>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>> specific Observation Domain ID is relevant for the entire IPFIX
>> Message.  For example, when exporting the Exporting Process
>> Statistics, or in case of hierarchy of Collector when aggregated data
>> records are exported.
>>
>> NEW
>> Observation Domain ID
>> A 32-bit identifier of the Observation Domain that is locally unique
>> to the Exporting Process.  The Exporting Process uses the Observation
>> Domain ID to uniquely identify to the Collecting Process the
>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>> this identifier is also unique per IPFIX Device.  Collecting Processes
>> SHOULD use the Transport Session and the Observation Domain ID field
>> to separate different export streams originating from the same
>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>> specific Observation Domain ID is relevant for the entire IPFIX
>> Message.  For example, when exporting the Exporting Process
>> Statistics, or in case of hierarchy of Collector when aggregated data
>> records are exported.
>>
>> Section 8, Template Management
>> OLD
>> The Exporting Process assigns and maintains the Template IDs for the
>> Exporter's Observation Domains. A newly created Template Record is
>> assigned an unused Template ID by the Exporting Process.
>>
>> NEW
>> The Exporting Process assigns and maintains the Template IDs per SCTP
>> association for the Exporter's Observation Domains.  A newly created
>> Template Record is assigned an unused Template ID by the Exporting
>> Process.
>>
>> OLD
>> A Template ID MUST be unique per Observation Domain. Different
>> Observation Domains from the same Exporter may use the same Template
>> ID value to refer to different Templates.
>>
>> NEW
>> Different Observation Domains from the same SCTP association may use
>> the same Template ID value to refer to different Templates.
>>
>> OLD
>> When the Exporting Process restarts, due to the SCTP association
>> shutdown, all Template assignments are lost and Template IDs MUST be
>> re-assigned.
>>
>> NEW
>> When the SCTP association shuts down or the Exporting Process
>> restarts, all Template assignments are lost and Template IDs MUST be
>> re-assigned.
>>
>> Section 9, Collecting Process's side
>> OLD
>> Template IDs are unique per IPFIX Device and per Observation Domain. 
>> If the Collecting Process receives a Template which has already been
>> received but which has not previously been withdrawn (i.e. a Template
>> Record from the same Exporter Observation Domain with the same
>> Template ID), then the Collecting Process MUST shutdown the association.
>>
>>
>> NEW
>> Template IDs are unique per SCTP association and per Observation
>> Domain.  If the Collecting Process receives a Template which has
>> already been received but which has not previously been withdrawn
>> (i.e. a Template Record from the same Exporter Observation Domain with
>> the same Template ID received on the SCTP association), then the
>> Collecting Process MUST shutdown the association.
>>
>> OLD
>>
>> If a Collecting Process receives a Template Withdraw Message, the
>> Collecting Process MUST delete the corresponding Template Records
>> associated with the specific Exporter and specific Observation Domain,
>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>
>> If the Collecting Process receives a Template Withdraw message for a
>> Template Record it has not received before, it MUST reset the SCTP
>> association, discard the IPFIX Message, and SHOULD log the error as it
>> does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several
>> Observation Domains from the same Exporter MUST be aware that the
>> uniqueness of the Template ID is not guaranteed across Observation
>> Domains.
>>
>> NEW
>> If a Collecting Process receives a Template Withdraw Message, the
>> Collecting Process MUST delete the corresponding Template Records
>> associated with the specific SCTP association and specific Observation
>> Domain, and stop decoding IPFIX Messages that use the withdrawn
>> Templates.
>> I
>> f the Collecting Process receives a Template Withdraw message for a
>> Template Record it has not received before on this SCTP assocation, it
>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
>> log the error as it does for malformed IPFIX Messages.
>>
>> A Collecting Process that receives IPFIX Messages from several
>> Observation Domains on the same Transport Session MUST be aware that
>> the uniqueness of the Template ID is not guaranteed across Observation
>> Domains.
>>
>> 10.3.7 Collecting Process
>> OLD
>> At any given time the Collecting Process SHOULD maintain the following
>> for all the current Template Records and Options Template Records:
>> > Definition, Last Received>.
>>
>> NEW
>> Template IDs are unique per UDP session and per Observation Domain. 
>> At any given time the Collecting Process SHOULD maintain the following
>> for all the current Template Records and Options Template Records:
>> > Template ID, Template Definition, Last Received>.
>>
>>
>> 10.4.2.2 Template Management
>>
>> Template IDs are unique per TCP connection and per Observation
>> Domain.  A Collecting Process MUST record all Template and Options
>> Template Records for the duration of the connection, as an Exporting
>> Process is not required to re-export Template Records.
>>
>>
>> [IPFIX-INFO]
>> NEWTransport Session
>> In SCTP, the transport session is known as the SCTP association, which
>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>> transport session is known as the TCP connection, which is uniquely
>> identified by the combination of IP addresses and TCP ports used; In
>> UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the combination of IP addresses and UDP ports
>> used.
>> OLD 5.1.8. templateId Description: An identifier of a Template that is
>> locally unique within an Observation Domain. NEW 5.1.8. templateId
>> Description: An identifier of a Template that is locally unique within
>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId
>> Description: An identifier of a Flow that is unique within an
>> Observation Domain. This Information Element can be used to
>> distinguish between different Flows if Flow Keys such as IP addresses
>> and port numbers are not reported or are reported in separate records.
>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
>> within an Observation Domain and the Transport Session. This
>> Information Element can be used to distinguish between different Flows
>> if Flow Keys such as IP addresses and port numbers are not reported or
>> are reported in separate records. OLD 5.1.11. commonPropertiesId
>> Description: An identifier of a set of common properties that is
>> unique per Observation Domain. Typically, this Information Element is
>> used to link to information reported in separate records. NEW: 5.1.11.
>> commonPropertiesId Description: An identifier of a set of common
>> properties that is unique per Observation Domain and Transport
>> Session. Typically, this Information Element is used to link to
>> information reported in separate records.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Thu Oct 12 07:52:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXz53-0001Pg-JU; Thu, 12 Oct 2006 07:50:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXz52-0001PZ-AS
	for ipfix@ietf.org; Thu, 12 Oct 2006 07:50:28 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXz50-0001V8-09
	for ipfix@ietf.org; Thu, 12 Oct 2006 07:50:28 -0400
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
	k9CBoOk15506; Thu, 12 Oct 2006 13:50:25 +0200 (CEST)
Received: from [10.61.64.78] (ams3-vpn-dhcp78.cisco.com [10.61.64.78])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9CBoNP09219; Thu, 12 Oct 2006 13:50:23 +0200 (CEST)
Message-ID: <452E2BFE.1020300@cisco.com>
Date: Thu, 12 Oct 2006 13:50:22 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Gerhard Muenz 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452DFD63.7050900@informatik.uni-tuebingen.de>
In-Reply-To: <452DFD63.7050900@informatik.uni-tuebingen.de>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: cb592aae7f4601895f35714165597859
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0864678861=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0864678861==
Content-Type: multipart/alternative;
	boundary="------------050608050303020504030302"

This is a multi-part message in MIME format.
--------------050608050303020504030302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gerhard,
> Dear Brian, All,
>
> I also agree with the proposed changes.
>
> Brian Trammell wrote:
>   
>> One point: do we want to be more pedantic about defining a Transport
>> Session for UDP? Both the SCTP and TCP Transport Session definitions
>> have temporal limits (the Association or the Connection lifetime,
>> defined by each transport protocol itself), while UDP does not. I would
>> suggest (from a past message to the list):
>>
>> In UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the IP addresses and UDP ports used, within the
>> time between the first UDP packet sent by the EP in the session and the
>> timeout after the last template retransmission.
>>     
>
> Fine with me. So using UDP, both templates and obervation domains are
> "soft states" with limited lifetime unless they are renewed.
>
> One question which is orthogonal but related:
> The proposed IPFIX configuration data model
> http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
> covers the case when the observation domain ID is configurable.
> Currently, the observation domain ID is a parameter of the observation
> point.
> What are your opinions? Is this the right place?
> Or do you prefer to have an observation domain ID paramater per
> exporting process?
> Or both (so it can be adapted to the implementation of the device)?
>   
My view is that, on a router, the Observation Domain Id should be the 
slot Id (available in the ENTITY-MIB)

Regards, Benoit.
> Regards,
> Gerhard
>
>
>
>   
>> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>>
>>     
>>> Dear all,
>>>
>>> Trying to address the concerns posted on the mailing recently
>>> regarding "observation domain, template, and session", Andrew, Paul,
>>> and I sat down and worked out a compromise. We're proposing to make
>>> template IDs unique per (Observation Domain ID, Session) pair. And NOT
>>> to scope the Observation Domain to the communication session between
>>> the Exporting Process and Collecting Process (as proposed by Andrew
>>> initially)
>>> I think that this compromise will make everybody happy as this
>>> solution is mainly a clarification, as opposed to a protocol design
>>> change.
>>>
>>> Problem Statement.
>>> If I read the protocol draft now, one interpretation could be: as I
>>> see that the Template Ids are unique per Observation Domain, and that
>>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX
>>> Device, this implies that the several Exporting Processes of the same
>>> IPFIX Device must synchronize the assignments of their Template Ids
>>> (to make sure that the Template Id are unique per Observation Domain).
>>> This might prove difficult/impossible in some cases.
>>> Instead of imposing this, the other solution is to make the template
>>> IDs unique per (Observation Domain ID, Session) pair.
>>> This makes sense as, logically, the template IDs have only a local
>>> significance between E.P. and C.P.
>>> Note: I brought up the issue of load-balancing or backup where it
>>> would be nice to have the same template IDs between two connections.
>>> The solution in this case is to use a single E.P. when load-balancing
>>> or backup is required.
>>>
>>> Please acknowledge that this compromise is fine with you.
>>>
>>> Note: 3 minor changes are required in the information elements
>>> definitions in [IPFIX-INFO]
>>>
>>> Regards, Andrew, Paul, and Benoit.
>>>
>>> See below for the proposed changes.
>>>
>>> [IPFIX-PROTO]
>>>
>>> NEW:
>>> Transport Session
>>> In SCTP, the transport session is known as the SCTP association, which
>>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>>> transport session is known as the TCP connection, which is uniquely
>>> identified by the combination of IP addresses and TCP ports used; In
>>> UDP, the transport session is known as the UDP session, which is
>>> uniquely identified by the combination of IP addresses and UDP ports
>>> used.
>>>
>>>
>>>
>>> OLD
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Observation
>>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>>
>>> NEW:
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Transport Session and
>>>      Observation Domain that generated the Template ID.  Template IDs
>>> 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>> OLD (Section 4.4)
>>>      templateId              An identifier of a Template that
>>>                              locally unique to the Exporting
>>>                              Process.  This Information
>>>                              Element MUST be defined as a Scope
>>>                              Field.
>>> NEW
>>>      templateId              An identifier of a Template. This
>>> Information
>>>                                    Element MUST be defined as a Scope
>>>                                    Field.
>>>
>>> Section 3.1
>>> OLD
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally unique
>>> to the Exporting Process.  The Exporting Process uses the Observation
>>> Domain ID to uniquely identify to the Collecting Process the
>>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>>> this identifier is also unique per IPFIX Device.  Collecting Processes
>>> SHOULD use the combination of the Exporter (exporterIPv4Address,
>>> exporterIPv6Address, or exportingProcessId) and the Observation Domain
>>> ID field to separate different export streams originating from the
>>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>>> specific Observation Domain ID is relevant for the entire IPFIX
>>> Message.  For example, when exporting the Exporting Process
>>> Statistics, or in case of hierarchy of Collector when aggregated data
>>> records are exported.
>>>
>>> NEW
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally unique
>>> to the Exporting Process.  The Exporting Process uses the Observation
>>> Domain ID to uniquely identify to the Collecting Process the
>>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>>> this identifier is also unique per IPFIX Device.  Collecting Processes
>>> SHOULD use the Transport Session and the Observation Domain ID field
>>> to separate different export streams originating from the same
>>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>>> specific Observation Domain ID is relevant for the entire IPFIX
>>> Message.  For example, when exporting the Exporting Process
>>> Statistics, or in case of hierarchy of Collector when aggregated data
>>> records are exported.
>>>
>>> Section 8, Template Management
>>> OLD
>>> The Exporting Process assigns and maintains the Template IDs for the
>>> Exporter's Observation Domains. A newly created Template Record is
>>> assigned an unused Template ID by the Exporting Process.
>>>
>>> NEW
>>> The Exporting Process assigns and maintains the Template IDs per SCTP
>>> association for the Exporter's Observation Domains.  A newly created
>>> Template Record is assigned an unused Template ID by the Exporting
>>> Process.
>>>
>>> OLD
>>> A Template ID MUST be unique per Observation Domain. Different
>>> Observation Domains from the same Exporter may use the same Template
>>> ID value to refer to different Templates.
>>>
>>> NEW
>>> Different Observation Domains from the same SCTP association may use
>>> the same Template ID value to refer to different Templates.
>>>
>>> OLD
>>> When the Exporting Process restarts, due to the SCTP association
>>> shutdown, all Template assignments are lost and Template IDs MUST be
>>> re-assigned.
>>>
>>> NEW
>>> When the SCTP association shuts down or the Exporting Process
>>> restarts, all Template assignments are lost and Template IDs MUST be
>>> re-assigned.
>>>
>>> Section 9, Collecting Process's side
>>> OLD
>>> Template IDs are unique per IPFIX Device and per Observation Domain. 
>>> If the Collecting Process receives a Template which has already been
>>> received but which has not previously been withdrawn (i.e. a Template
>>> Record from the same Exporter Observation Domain with the same
>>> Template ID), then the Collecting Process MUST shutdown the association.
>>>
>>>
>>> NEW
>>> Template IDs are unique per SCTP association and per Observation
>>> Domain.  If the Collecting Process receives a Template which has
>>> already been received but which has not previously been withdrawn
>>> (i.e. a Template Record from the same Exporter Observation Domain with
>>> the same Template ID received on the SCTP association), then the
>>> Collecting Process MUST shutdown the association.
>>>
>>> OLD
>>>
>>> If a Collecting Process receives a Template Withdraw Message, the
>>> Collecting Process MUST delete the corresponding Template Records
>>> associated with the specific Exporter and specific Observation Domain,
>>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>>
>>> If the Collecting Process receives a Template Withdraw message for a
>>> Template Record it has not received before, it MUST reset the SCTP
>>> association, discard the IPFIX Message, and SHOULD log the error as it
>>> does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several
>>> Observation Domains from the same Exporter MUST be aware that the
>>> uniqueness of the Template ID is not guaranteed across Observation
>>> Domains.
>>>
>>> NEW
>>> If a Collecting Process receives a Template Withdraw Message, the
>>> Collecting Process MUST delete the corresponding Template Records
>>> associated with the specific SCTP association and specific Observation
>>> Domain, and stop decoding IPFIX Messages that use the withdrawn
>>> Templates.
>>> I
>>> f the Collecting Process receives a Template Withdraw message for a
>>> Template Record it has not received before on this SCTP assocation, it
>>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
>>> log the error as it does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several
>>> Observation Domains on the same Transport Session MUST be aware that
>>> the uniqueness of the Template ID is not guaranteed across Observation
>>> Domains.
>>>
>>> 10.3.7 Collecting Process
>>> OLD
>>> At any given time the Collecting Process SHOULD maintain the following
>>> for all the current Template Records and Options Template Records:
>>> >> Definition, Last Received>.
>>>
>>> NEW
>>> Template IDs are unique per UDP session and per Observation Domain. 
>>> At any given time the Collecting Process SHOULD maintain the following
>>> for all the current Template Records and Options Template Records:
>>> >> Template ID, Template Definition, Last Received>.
>>>
>>>
>>> 10.4.2.2 Template Management
>>>
>>> Template IDs are unique per TCP connection and per Observation
>>> Domain.  A Collecting Process MUST record all Template and Options
>>> Template Records for the duration of the connection, as an Exporting
>>> Process is not required to re-export Template Records.
>>>
>>>
>>> [IPFIX-INFO]
>>> NEWTransport Session
>>> In SCTP, the transport session is known as the SCTP association, which
>>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>>> transport session is known as the TCP connection, which is uniquely
>>> identified by the combination of IP addresses and TCP ports used; In
>>> UDP, the transport session is known as the UDP session, which is
>>> uniquely identified by the combination of IP addresses and UDP ports
>>> used.
>>> OLD 5.1.8. templateId Description: An identifier of a Template that is
>>> locally unique within an Observation Domain. NEW 5.1.8. templateId
>>> Description: An identifier of a Template that is locally unique within
>>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId
>>> Description: An identifier of a Flow that is unique within an
>>> Observation Domain. This Information Element can be used to
>>> distinguish between different Flows if Flow Keys such as IP addresses
>>> and port numbers are not reported or are reported in separate records.
>>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
>>> within an Observation Domain and the Transport Session. This
>>> Information Element can be used to distinguish between different Flows
>>> if Flow Keys such as IP addresses and port numbers are not reported or
>>> are reported in separate records. OLD 5.1.11. commonPropertiesId
>>> Description: An identifier of a set of common properties that is
>>> unique per Observation Domain. Typically, this Information Element is
>>> used to link to information reported in separate records. NEW: 5.1.11.
>>> commonPropertiesId Description: An identifier of a set of common
>>> properties that is unique per Observation Domain and Transport
>>> Session. Typically, this Information Element is used to link to
>>> information reported in separate records.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>>>       
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>     
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Gerhard,


  
Dear Brian, All,

I also agree with the proposed changes.

Brian Trammell wrote:
  

  

    
One point: do we want to be more pedantic about defining a Transport
Session for UDP? Both the SCTP and TCP Transport Session definitions
have temporal limits (the Association or the Connection lifetime,
defined by each transport protocol itself), while UDP does not. I would
suggest (from a past message to the list):

In UDP, the transport session is known as the UDP session, which is
uniquely identified by the IP addresses and UDP ports used, within the
time between the first UDP packet sent by the EP in the session and the
timeout after the last template retransmission.
    

  

  

Fine with me. So using UDP, both templates and obervation domains are
"soft states" with limited lifetime unless they are renewed.

One question which is orthogonal but related:
The proposed IPFIX configuration data model
http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
covers the case when the observation domain ID is configurable.
Currently, the observation domain ID is a parameter of the observation
point.
What are your opinions? Is this the right place?
Or do you prefer to have an observation domain ID paramater per
exporting process?
Or both (so it can be adapted to the implementation of the device)?
  



My view is that, on a router, the Observation Domain Id should be the
slot Id (available in the ENTITY-MIB)



Regards, Benoit.



  
Regards,
Gerhard



  

  

    
On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:

    

    

      
Dear all,

Trying to address the concerns posted on the mailing recently
regarding "observation domain, template, and session", Andrew, Paul,
and I sat down and worked out a compromise. We're proposing to make
template IDs unique per (Observation Domain ID, Session) pair. And NOT
to scope the Observation Domain to the communication session between
the Exporting Process and Collecting Process (as proposed by Andrew
initially)
I think that this compromise will make everybody happy as this
solution is mainly a clarification, as opposed to a protocol design
change.

Problem Statement.
If I read the protocol draft now, one interpretation could be: as I
see that the Template Ids are unique per Observation Domain, and that
the Observation Domain Id are RECOMMENDED to be unique per IPFIX
Device, this implies that the several Exporting Processes of the same
IPFIX Device must synchronize the assignments of their Template Ids
(to make sure that the Template Id are unique per Observation Domain).
This might prove difficult/impossible in some cases.
Instead of imposing this, the other solution is to make the template
IDs unique per (Observation Domain ID, Session) pair.
This makes sense as, logically, the template IDs have only a local
significance between E.P. and C.P.
Note: I brought up the issue of load-balancing or backup where it
would be nice to have the same template IDs between two connections.
The solution in this case is to use a single E.P. when load-balancing
or backup is required.

Please acknowledge that this compromise is fine with you.

Note: 3 minor changes are required in the information elements
definitions in [IPFIX-INFO]

Regards, Andrew, Paul, and Benoit.

See below for the proposed changes.

[IPFIX-PROTO]

NEW:
Transport Session
In SCTP, the transport session is known as the SCTP association, which
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
transport session is known as the TCP connection, which is uniquely
identified by the combination of IP addresses and TCP ports used; In
UDP, the transport session is known as the UDP session, which is
uniquely identified by the combination of IP addresses and UDP ports
used.



OLD
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Observation
      Domain that generated the Template ID.  Template IDs 0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.


NEW:
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Transport Session and
     Observation Domain that generated the Template ID.  Template IDs
0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.

OLD (Section 4.4)
     templateId              An identifier of a Template that
                             locally unique to the Exporting
                             Process.  This Information
                             Element MUST be defined as a Scope
                             Field.
NEW
     templateId              An identifier of a Template. This
Information
                                   Element MUST be defined as a Scope
                                   Field.

Section 3.1
OLD
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique
to the Exporting Process.  The Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain that metered the Flows.  It is RECOMMENDED that
this identifier is also unique per IPFIX Device.  Collecting Processes
SHOULD use the combination of the Exporter (exporterIPv4Address,
exporterIPv6Address, or exportingProcessId) and the Observation Domain
ID field to separate different export streams originating from the
same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX
Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when aggregated data
records are exported.

NEW
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique
to the Exporting Process.  The Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain that metered the Flows.  It is RECOMMENDED that
this identifier is also unique per IPFIX Device.  Collecting Processes
SHOULD use the Transport Session and the Observation Domain ID field
to separate different export streams originating from the same
Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX
Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when aggregated data
records are exported.

Section 8, Template Management
OLD
The Exporting Process assigns and maintains the Template IDs for the
Exporter's Observation Domains. A newly created Template Record is
assigned an unused Template ID by the Exporting Process.

NEW
The Exporting Process assigns and maintains the Template IDs per SCTP
association for the Exporter's Observation Domains.  A newly created
Template Record is assigned an unused Template ID by the Exporting
Process.

OLD
A Template ID MUST be unique per Observation Domain. Different
Observation Domains from the same Exporter may use the same Template
ID value to refer to different Templates.

NEW
Different Observation Domains from the same SCTP association may use
the same Template ID value to refer to different Templates.

OLD
When the Exporting Process restarts, due to the SCTP association
shutdown, all Template assignments are lost and Template IDs MUST be
re-assigned.

NEW
When the SCTP association shuts down or the Exporting Process
restarts, all Template assignments are lost and Template IDs MUST be
re-assigned.

Section 9, Collecting Process's side
OLD
Template IDs are unique per IPFIX Device and per Observation Domain. 
If the Collecting Process receives a Template which has already been
received but which has not previously been withdrawn (i.e. a Template
Record from the same Exporter Observation Domain with the same
Template ID), then the Collecting Process MUST shutdown the association.


NEW
Template IDs are unique per SCTP association and per Observation
Domain.  If the Collecting Process receives a Template which has
already been received but which has not previously been withdrawn
(i.e. a Template Record from the same Exporter Observation Domain with
the same Template ID received on the SCTP association), then the
Collecting Process MUST shutdown the association.

OLD

If a Collecting Process receives a Template Withdraw Message, the
Collecting Process MUST delete the corresponding Template Records
associated with the specific Exporter and specific Observation Domain,
and stop decoding IPFIX Messages that use the withdrawn Templates.

If the Collecting Process receives a Template Withdraw message for a
Template Record it has not received before, it MUST reset the SCTP
association, discard the IPFIX Message, and SHOULD log the error as it
does for malformed IPFIX Messages.

A Collecting Process that receives IPFIX Messages from several
Observation Domains from the same Exporter MUST be aware that the
uniqueness of the Template ID is not guaranteed across Observation
Domains.

NEW
If a Collecting Process receives a Template Withdraw Message, the
Collecting Process MUST delete the corresponding Template Records
associated with the specific SCTP association and specific Observation
Domain, and stop decoding IPFIX Messages that use the withdrawn
Templates.
I
f the Collecting Process receives a Template Withdraw message for a
Template Record it has not received before on this SCTP assocation, it
MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
log the error as it does for malformed IPFIX Messages.

A Collecting Process that receives IPFIX Messages from several
Observation Domains on the same Transport Session MUST be aware that
the uniqueness of the Template ID is not guaranteed across Observation
Domains.

10.3.7 Collecting Process
OLD
At any given time the Collecting Process SHOULD maintain the following
for all the current Template Records and Options Template Records:
<Exporting Process, Observation Domain ID, Template ID, Template
Definition, Last Received>.

NEW
Template IDs are unique per UDP session and per Observation Domain. 
At any given time the Collecting Process SHOULD maintain the following
for all the current Template Records and Options Template Records:
<IPFIX Device, Exporter source UDP port, Observation Domain ID,
Template ID, Template Definition, Last Received>.


10.4.2.2 Template Management

Template IDs are unique per TCP connection and per Observation
Domain.  A Collecting Process MUST record all Template and Options
Template Records for the duration of the connection, as an Exporting
Process is not required to re-export Template Records.


[IPFIX-INFO]
NEWTransport Session
In SCTP, the transport session is known as the SCTP association, which
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
transport session is known as the TCP connection, which is uniquely
identified by the combination of IP addresses and TCP ports used; In
UDP, the transport session is known as the UDP session, which is
uniquely identified by the combination of IP addresses and UDP ports
used.
OLD 5.1.8. templateId Description: An identifier of a Template that is
locally unique within an Observation Domain. NEW 5.1.8. templateId
Description: An identifier of a Template that is locally unique within
an Observation Domain and the Transport Session. OLD 5.1.7. flowId
Description: An identifier of a Flow that is unique within an
Observation Domain. This Information Element can be used to
distinguish between different Flows if Flow Keys such as IP addresses
and port numbers are not reported or are reported in separate records.
NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
within an Observation Domain and the Transport Session. This
Information Element can be used to distinguish between different Flows
if Flow Keys such as IP addresses and port numbers are not reported or
are reported in separate records. OLD 5.1.11. commonPropertiesId
Description: An identifier of a set of common properties that is
unique per Observation Domain. Typically, this Information Element is
used to link to information reported in separate records. NEW: 5.1.11.
commonPropertiesId Description: An identifier of a set of common
properties that is unique per Observation Domain and Transport
Session. Typically, this Information Element is used to link to
information reported in separate records.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix
      

    

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

  

  


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








--------------050608050303020504030302--


--===============0864678861==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0864678861==--




From ipfix-bounces@ietf.org Thu Oct 12 07:52:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXz53-0001Pg-JU; Thu, 12 Oct 2006 07:50:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GXz52-0001PZ-AS
	for ipfix@ietf.org; Thu, 12 Oct 2006 07:50:28 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXz50-0001V8-09
	for ipfix@ietf.org; Thu, 12 Oct 2006 07:50:28 -0400
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
	k9CBoOk15506; Thu, 12 Oct 2006 13:50:25 +0200 (CEST)
Received: from [10.61.64.78] (ams3-vpn-dhcp78.cisco.com [10.61.64.78])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9CBoNP09219; Thu, 12 Oct 2006 13:50:23 +0200 (CEST)
Message-ID: <452E2BFE.1020300@cisco.com>
Date: Thu, 12 Oct 2006 13:50:22 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Gerhard Muenz 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452DFD63.7050900@informatik.uni-tuebingen.de>
In-Reply-To: <452DFD63.7050900@informatik.uni-tuebingen.de>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: cb592aae7f4601895f35714165597859
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0864678861=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0864678861==
Content-Type: multipart/alternative;
	boundary="------------050608050303020504030302"

This is a multi-part message in MIME format.
--------------050608050303020504030302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gerhard,
> Dear Brian, All,
>
> I also agree with the proposed changes.
>
> Brian Trammell wrote:
>   
>> One point: do we want to be more pedantic about defining a Transport
>> Session for UDP? Both the SCTP and TCP Transport Session definitions
>> have temporal limits (the Association or the Connection lifetime,
>> defined by each transport protocol itself), while UDP does not. I would
>> suggest (from a past message to the list):
>>
>> In UDP, the transport session is known as the UDP session, which is
>> uniquely identified by the IP addresses and UDP ports used, within the
>> time between the first UDP packet sent by the EP in the session and the
>> timeout after the last template retransmission.
>>     
>
> Fine with me. So using UDP, both templates and obervation domains are
> "soft states" with limited lifetime unless they are renewed.
>
> One question which is orthogonal but related:
> The proposed IPFIX configuration data model
> http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
> covers the case when the observation domain ID is configurable.
> Currently, the observation domain ID is a parameter of the observation
> point.
> What are your opinions? Is this the right place?
> Or do you prefer to have an observation domain ID paramater per
> exporting process?
> Or both (so it can be adapted to the implementation of the device)?
>   
My view is that, on a router, the Observation Domain Id should be the 
slot Id (available in the ENTITY-MIB)

Regards, Benoit.
> Regards,
> Gerhard
>
>
>
>   
>> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>>
>>     
>>> Dear all,
>>>
>>> Trying to address the concerns posted on the mailing recently
>>> regarding "observation domain, template, and session", Andrew, Paul,
>>> and I sat down and worked out a compromise. We're proposing to make
>>> template IDs unique per (Observation Domain ID, Session) pair. And NOT
>>> to scope the Observation Domain to the communication session between
>>> the Exporting Process and Collecting Process (as proposed by Andrew
>>> initially)
>>> I think that this compromise will make everybody happy as this
>>> solution is mainly a clarification, as opposed to a protocol design
>>> change.
>>>
>>> Problem Statement.
>>> If I read the protocol draft now, one interpretation could be: as I
>>> see that the Template Ids are unique per Observation Domain, and that
>>> the Observation Domain Id are RECOMMENDED to be unique per IPFIX
>>> Device, this implies that the several Exporting Processes of the same
>>> IPFIX Device must synchronize the assignments of their Template Ids
>>> (to make sure that the Template Id are unique per Observation Domain).
>>> This might prove difficult/impossible in some cases.
>>> Instead of imposing this, the other solution is to make the template
>>> IDs unique per (Observation Domain ID, Session) pair.
>>> This makes sense as, logically, the template IDs have only a local
>>> significance between E.P. and C.P.
>>> Note: I brought up the issue of load-balancing or backup where it
>>> would be nice to have the same template IDs between two connections.
>>> The solution in this case is to use a single E.P. when load-balancing
>>> or backup is required.
>>>
>>> Please acknowledge that this compromise is fine with you.
>>>
>>> Note: 3 minor changes are required in the information elements
>>> definitions in [IPFIX-INFO]
>>>
>>> Regards, Andrew, Paul, and Benoit.
>>>
>>> See below for the proposed changes.
>>>
>>> [IPFIX-PROTO]
>>>
>>> NEW:
>>> Transport Session
>>> In SCTP, the transport session is known as the SCTP association, which
>>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>>> transport session is known as the TCP connection, which is uniquely
>>> identified by the combination of IP addresses and TCP ports used; In
>>> UDP, the transport session is known as the UDP session, which is
>>> uniquely identified by the combination of IP addresses and UDP ports
>>> used.
>>>
>>>
>>>
>>> OLD
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Observation
>>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>>
>>> NEW:
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Transport Session and
>>>      Observation Domain that generated the Template ID.  Template IDs
>>> 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>> OLD (Section 4.4)
>>>      templateId              An identifier of a Template that
>>>                              locally unique to the Exporting
>>>                              Process.  This Information
>>>                              Element MUST be defined as a Scope
>>>                              Field.
>>> NEW
>>>      templateId              An identifier of a Template. This
>>> Information
>>>                                    Element MUST be defined as a Scope
>>>                                    Field.
>>>
>>> Section 3.1
>>> OLD
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally unique
>>> to the Exporting Process.  The Exporting Process uses the Observation
>>> Domain ID to uniquely identify to the Collecting Process the
>>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>>> this identifier is also unique per IPFIX Device.  Collecting Processes
>>> SHOULD use the combination of the Exporter (exporterIPv4Address,
>>> exporterIPv6Address, or exportingProcessId) and the Observation Domain
>>> ID field to separate different export streams originating from the
>>> same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>>> specific Observation Domain ID is relevant for the entire IPFIX
>>> Message.  For example, when exporting the Exporting Process
>>> Statistics, or in case of hierarchy of Collector when aggregated data
>>> records are exported.
>>>
>>> NEW
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally unique
>>> to the Exporting Process.  The Exporting Process uses the Observation
>>> Domain ID to uniquely identify to the Collecting Process the
>>> Observation Domain that metered the Flows.  It is RECOMMENDED that
>>> this identifier is also unique per IPFIX Device.  Collecting Processes
>>> SHOULD use the Transport Session and the Observation Domain ID field
>>> to separate different export streams originating from the same
>>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no
>>> specific Observation Domain ID is relevant for the entire IPFIX
>>> Message.  For example, when exporting the Exporting Process
>>> Statistics, or in case of hierarchy of Collector when aggregated data
>>> records are exported.
>>>
>>> Section 8, Template Management
>>> OLD
>>> The Exporting Process assigns and maintains the Template IDs for the
>>> Exporter's Observation Domains. A newly created Template Record is
>>> assigned an unused Template ID by the Exporting Process.
>>>
>>> NEW
>>> The Exporting Process assigns and maintains the Template IDs per SCTP
>>> association for the Exporter's Observation Domains.  A newly created
>>> Template Record is assigned an unused Template ID by the Exporting
>>> Process.
>>>
>>> OLD
>>> A Template ID MUST be unique per Observation Domain. Different
>>> Observation Domains from the same Exporter may use the same Template
>>> ID value to refer to different Templates.
>>>
>>> NEW
>>> Different Observation Domains from the same SCTP association may use
>>> the same Template ID value to refer to different Templates.
>>>
>>> OLD
>>> When the Exporting Process restarts, due to the SCTP association
>>> shutdown, all Template assignments are lost and Template IDs MUST be
>>> re-assigned.
>>>
>>> NEW
>>> When the SCTP association shuts down or the Exporting Process
>>> restarts, all Template assignments are lost and Template IDs MUST be
>>> re-assigned.
>>>
>>> Section 9, Collecting Process's side
>>> OLD
>>> Template IDs are unique per IPFIX Device and per Observation Domain. 
>>> If the Collecting Process receives a Template which has already been
>>> received but which has not previously been withdrawn (i.e. a Template
>>> Record from the same Exporter Observation Domain with the same
>>> Template ID), then the Collecting Process MUST shutdown the association.
>>>
>>>
>>> NEW
>>> Template IDs are unique per SCTP association and per Observation
>>> Domain.  If the Collecting Process receives a Template which has
>>> already been received but which has not previously been withdrawn
>>> (i.e. a Template Record from the same Exporter Observation Domain with
>>> the same Template ID received on the SCTP association), then the
>>> Collecting Process MUST shutdown the association.
>>>
>>> OLD
>>>
>>> If a Collecting Process receives a Template Withdraw Message, the
>>> Collecting Process MUST delete the corresponding Template Records
>>> associated with the specific Exporter and specific Observation Domain,
>>> and stop decoding IPFIX Messages that use the withdrawn Templates.
>>>
>>> If the Collecting Process receives a Template Withdraw message for a
>>> Template Record it has not received before, it MUST reset the SCTP
>>> association, discard the IPFIX Message, and SHOULD log the error as it
>>> does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several
>>> Observation Domains from the same Exporter MUST be aware that the
>>> uniqueness of the Template ID is not guaranteed across Observation
>>> Domains.
>>>
>>> NEW
>>> If a Collecting Process receives a Template Withdraw Message, the
>>> Collecting Process MUST delete the corresponding Template Records
>>> associated with the specific SCTP association and specific Observation
>>> Domain, and stop decoding IPFIX Messages that use the withdrawn
>>> Templates.
>>> I
>>> f the Collecting Process receives a Template Withdraw message for a
>>> Template Record it has not received before on this SCTP assocation, it
>>> MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
>>> log the error as it does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several
>>> Observation Domains on the same Transport Session MUST be aware that
>>> the uniqueness of the Template ID is not guaranteed across Observation
>>> Domains.
>>>
>>> 10.3.7 Collecting Process
>>> OLD
>>> At any given time the Collecting Process SHOULD maintain the following
>>> for all the current Template Records and Options Template Records:
>>> >> Definition, Last Received>.
>>>
>>> NEW
>>> Template IDs are unique per UDP session and per Observation Domain. 
>>> At any given time the Collecting Process SHOULD maintain the following
>>> for all the current Template Records and Options Template Records:
>>> >> Template ID, Template Definition, Last Received>.
>>>
>>>
>>> 10.4.2.2 Template Management
>>>
>>> Template IDs are unique per TCP connection and per Observation
>>> Domain.  A Collecting Process MUST record all Template and Options
>>> Template Records for the duration of the connection, as an Exporting
>>> Process is not required to re-export Template Records.
>>>
>>>
>>> [IPFIX-INFO]
>>> NEWTransport Session
>>> In SCTP, the transport session is known as the SCTP association, which
>>> is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
>>> transport session is known as the TCP connection, which is uniquely
>>> identified by the combination of IP addresses and TCP ports used; In
>>> UDP, the transport session is known as the UDP session, which is
>>> uniquely identified by the combination of IP addresses and UDP ports
>>> used.
>>> OLD 5.1.8. templateId Description: An identifier of a Template that is
>>> locally unique within an Observation Domain. NEW 5.1.8. templateId
>>> Description: An identifier of a Template that is locally unique within
>>> an Observation Domain and the Transport Session. OLD 5.1.7. flowId
>>> Description: An identifier of a Flow that is unique within an
>>> Observation Domain. This Information Element can be used to
>>> distinguish between different Flows if Flow Keys such as IP addresses
>>> and port numbers are not reported or are reported in separate records.
>>> NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
>>> within an Observation Domain and the Transport Session. This
>>> Information Element can be used to distinguish between different Flows
>>> if Flow Keys such as IP addresses and port numbers are not reported or
>>> are reported in separate records. OLD 5.1.11. commonPropertiesId
>>> Description: An identifier of a set of common properties that is
>>> unique per Observation Domain. Typically, this Information Element is
>>> used to link to information reported in separate records. NEW: 5.1.11.
>>> commonPropertiesId Description: An identifier of a set of common
>>> properties that is unique per Observation Domain and Transport
>>> Session. Typically, this Information Element is used to link to
>>> information reported in separate records.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>>>       
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>     
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Gerhard,


  
Dear Brian, All,

I also agree with the proposed changes.

Brian Trammell wrote:
  

  

    
One point: do we want to be more pedantic about defining a Transport
Session for UDP? Both the SCTP and TCP Transport Session definitions
have temporal limits (the Association or the Connection lifetime,
defined by each transport protocol itself), while UDP does not. I would
suggest (from a past message to the list):

In UDP, the transport session is known as the UDP session, which is
uniquely identified by the IP addresses and UDP ports used, within the
time between the first UDP packet sent by the EP in the session and the
timeout after the last template retransmission.
    

  

  

Fine with me. So using UDP, both templates and obervation domains are
"soft states" with limited lifetime unless they are renewed.

One question which is orthogonal but related:
The proposed IPFIX configuration data model
http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/draft-muenz-ipfix-configuration-00.txt
covers the case when the observation domain ID is configurable.
Currently, the observation domain ID is a parameter of the observation
point.
What are your opinions? Is this the right place?
Or do you prefer to have an observation domain ID paramater per
exporting process?
Or both (so it can be adapted to the implementation of the device)?
  



My view is that, on a router, the Observation Domain Id should be the
slot Id (available in the ENTITY-MIB)



Regards, Benoit.



  
Regards,
Gerhard



  

  

    
On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:

    

    

      
Dear all,

Trying to address the concerns posted on the mailing recently
regarding "observation domain, template, and session", Andrew, Paul,
and I sat down and worked out a compromise. We're proposing to make
template IDs unique per (Observation Domain ID, Session) pair. And NOT
to scope the Observation Domain to the communication session between
the Exporting Process and Collecting Process (as proposed by Andrew
initially)
I think that this compromise will make everybody happy as this
solution is mainly a clarification, as opposed to a protocol design
change.

Problem Statement.
If I read the protocol draft now, one interpretation could be: as I
see that the Template Ids are unique per Observation Domain, and that
the Observation Domain Id are RECOMMENDED to be unique per IPFIX
Device, this implies that the several Exporting Processes of the same
IPFIX Device must synchronize the assignments of their Template Ids
(to make sure that the Template Id are unique per Observation Domain).
This might prove difficult/impossible in some cases.
Instead of imposing this, the other solution is to make the template
IDs unique per (Observation Domain ID, Session) pair.
This makes sense as, logically, the template IDs have only a local
significance between E.P. and C.P.
Note: I brought up the issue of load-balancing or backup where it
would be nice to have the same template IDs between two connections.
The solution in this case is to use a single E.P. when load-balancing
or backup is required.

Please acknowledge that this compromise is fine with you.

Note: 3 minor changes are required in the information elements
definitions in [IPFIX-INFO]

Regards, Andrew, Paul, and Benoit.

See below for the proposed changes.

[IPFIX-PROTO]

NEW:
Transport Session
In SCTP, the transport session is known as the SCTP association, which
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
transport session is known as the TCP connection, which is uniquely
identified by the combination of IP addresses and TCP ports used; In
UDP, the transport session is known as the UDP session, which is
uniquely identified by the combination of IP addresses and UDP ports
used.



OLD
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Observation
      Domain that generated the Template ID.  Template IDs 0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.


NEW:
Template ID
      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Transport Session and
     Observation Domain that generated the Template ID.  Template IDs
0-255 are
      reserved for Template Sets, Options Template Sets, and other
      reserved Sets yet to be created.  Template IDs of Data Sets
      are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.

OLD (Section 4.4)
     templateId              An identifier of a Template that
                             locally unique to the Exporting
                             Process.  This Information
                             Element MUST be defined as a Scope
                             Field.
NEW
     templateId              An identifier of a Template. This
Information
                                   Element MUST be defined as a Scope
                                   Field.

Section 3.1
OLD
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique
to the Exporting Process.  The Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain that metered the Flows.  It is RECOMMENDED that
this identifier is also unique per IPFIX Device.  Collecting Processes
SHOULD use the combination of the Exporter (exporterIPv4Address,
exporterIPv6Address, or exportingProcessId) and the Observation Domain
ID field to separate different export streams originating from the
same Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX
Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when aggregated data
records are exported.

NEW
Observation Domain ID
A 32-bit identifier of the Observation Domain that is locally unique
to the Exporting Process.  The Exporting Process uses the Observation
Domain ID to uniquely identify to the Collecting Process the
Observation Domain that metered the Flows.  It is RECOMMENDED that
this identifier is also unique per IPFIX Device.  Collecting Processes
SHOULD use the Transport Session and the Observation Domain ID field
to separate different export streams originating from the same
Exporting Process.  The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX
Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when aggregated data
records are exported.

Section 8, Template Management
OLD
The Exporting Process assigns and maintains the Template IDs for the
Exporter's Observation Domains. A newly created Template Record is
assigned an unused Template ID by the Exporting Process.

NEW
The Exporting Process assigns and maintains the Template IDs per SCTP
association for the Exporter's Observation Domains.  A newly created
Template Record is assigned an unused Template ID by the Exporting
Process.

OLD
A Template ID MUST be unique per Observation Domain. Different
Observation Domains from the same Exporter may use the same Template
ID value to refer to different Templates.

NEW
Different Observation Domains from the same SCTP association may use
the same Template ID value to refer to different Templates.

OLD
When the Exporting Process restarts, due to the SCTP association
shutdown, all Template assignments are lost and Template IDs MUST be
re-assigned.

NEW
When the SCTP association shuts down or the Exporting Process
restarts, all Template assignments are lost and Template IDs MUST be
re-assigned.

Section 9, Collecting Process's side
OLD
Template IDs are unique per IPFIX Device and per Observation Domain. 
If the Collecting Process receives a Template which has already been
received but which has not previously been withdrawn (i.e. a Template
Record from the same Exporter Observation Domain with the same
Template ID), then the Collecting Process MUST shutdown the association.


NEW
Template IDs are unique per SCTP association and per Observation
Domain.  If the Collecting Process receives a Template which has
already been received but which has not previously been withdrawn
(i.e. a Template Record from the same Exporter Observation Domain with
the same Template ID received on the SCTP association), then the
Collecting Process MUST shutdown the association.

OLD

If a Collecting Process receives a Template Withdraw Message, the
Collecting Process MUST delete the corresponding Template Records
associated with the specific Exporter and specific Observation Domain,
and stop decoding IPFIX Messages that use the withdrawn Templates.

If the Collecting Process receives a Template Withdraw message for a
Template Record it has not received before, it MUST reset the SCTP
association, discard the IPFIX Message, and SHOULD log the error as it
does for malformed IPFIX Messages.

A Collecting Process that receives IPFIX Messages from several
Observation Domains from the same Exporter MUST be aware that the
uniqueness of the Template ID is not guaranteed across Observation
Domains.

NEW
If a Collecting Process receives a Template Withdraw Message, the
Collecting Process MUST delete the corresponding Template Records
associated with the specific SCTP association and specific Observation
Domain, and stop decoding IPFIX Messages that use the withdrawn
Templates.
I
f the Collecting Process receives a Template Withdraw message for a
Template Record it has not received before on this SCTP assocation, it
MUST reset the SCTP association, discard the IPFIX Message, and SHOULD
log the error as it does for malformed IPFIX Messages.

A Collecting Process that receives IPFIX Messages from several
Observation Domains on the same Transport Session MUST be aware that
the uniqueness of the Template ID is not guaranteed across Observation
Domains.

10.3.7 Collecting Process
OLD
At any given time the Collecting Process SHOULD maintain the following
for all the current Template Records and Options Template Records:
<Exporting Process, Observation Domain ID, Template ID, Template
Definition, Last Received>.

NEW
Template IDs are unique per UDP session and per Observation Domain. 
At any given time the Collecting Process SHOULD maintain the following
for all the current Template Records and Options Template Records:
<IPFIX Device, Exporter source UDP port, Observation Domain ID,
Template ID, Template Definition, Last Received>.


10.4.2.2 Template Management

Template IDs are unique per TCP connection and per Observation
Domain.  A Collecting Process MUST record all Template and Options
Template Records for the duration of the connection, as an Exporting
Process is not required to re-export Template Records.


[IPFIX-INFO]
NEWTransport Session
In SCTP, the transport session is known as the SCTP association, which
is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, the
transport session is known as the TCP connection, which is uniquely
identified by the combination of IP addresses and TCP ports used; In
UDP, the transport session is known as the UDP session, which is
uniquely identified by the combination of IP addresses and UDP ports
used.
OLD 5.1.8. templateId Description: An identifier of a Template that is
locally unique within an Observation Domain. NEW 5.1.8. templateId
Description: An identifier of a Template that is locally unique within
an Observation Domain and the Transport Session. OLD 5.1.7. flowId
Description: An identifier of a Flow that is unique within an
Observation Domain. This Information Element can be used to
distinguish between different Flows if Flow Keys such as IP addresses
and port numbers are not reported or are reported in separate records.
NEW 5.1.7. flowId Description: An identifier of a Flow that is unique
within an Observation Domain and the Transport Session. This
Information Element can be used to distinguish between different Flows
if Flow Keys such as IP addresses and port numbers are not reported or
are reported in separate records. OLD 5.1.11. commonPropertiesId
Description: An identifier of a set of common properties that is
unique per Observation Domain. Typically, this Information Element is
used to link to information reported in separate records. NEW: 5.1.11.
commonPropertiesId Description: An identifier of a set of common
properties that is unique per Observation Domain and Transport
Session. Typically, this Information Element is used to link to
information reported in separate records.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix
      

    

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

  

  


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








--------------050608050303020504030302--


--===============0864678861==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0864678861==--




From ipfix-bounces@ietf.org Thu Oct 12 10:07:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY1CU-0006Ve-JU; Thu, 12 Oct 2006 10:06:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1CT-0006T3-IW
	for ipfix@ietf.org; Thu, 12 Oct 2006 10:06:17 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1CR-0002Yu-5b
	for ipfix@ietf.org; Thu, 12 Oct 2006 10:06:17 -0400
Received: from [10.147.65.153] (luz@kaitos [10.147.65.153])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id
	k9CE4pd12537; Thu, 12 Oct 2006 16:04:51 +0200 (MEST)
Message-ID: <452E4BCB.1090900@fokus.fraunhofer.de>
Date: Thu, 12 Oct 2006 16:06:03 +0200
From: Lutz Mark 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
MIME-Version: 1.0
To: Benoit Claise 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
In-Reply-To: <452CECC2.5080703@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Benoit,

> Please acknowledge that this compromise is fine with you.

perfect.

Best regards,
Lutz



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



From ipfix-bounces@ietf.org Thu Oct 12 10:07:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY1CU-0006Ve-JU; Thu, 12 Oct 2006 10:06:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1CT-0006T3-IW
	for ipfix@ietf.org; Thu, 12 Oct 2006 10:06:17 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1CR-0002Yu-5b
	for ipfix@ietf.org; Thu, 12 Oct 2006 10:06:17 -0400
Received: from [10.147.65.153] (luz@kaitos [10.147.65.153])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id
	k9CE4pd12537; Thu, 12 Oct 2006 16:04:51 +0200 (MEST)
Message-ID: <452E4BCB.1090900@fokus.fraunhofer.de>
Date: Thu, 12 Oct 2006 16:06:03 +0200
From: Lutz Mark 
User-Agent: Thunderbird 1.5.0.7 (X11/20060915)
MIME-Version: 1.0
To: Benoit Claise 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
References: <452CECC2.5080703@cisco.com>
In-Reply-To: <452CECC2.5080703@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Benoit,

> Please acknowledge that this compromise is fine with you.

perfect.

Best regards,
Lutz



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



From ipfix-bounces@ietf.org Thu Oct 12 11:41:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY2f8-0001h9-03; Thu, 12 Oct 2006 11:39:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2f7-0001h4-3I
	for ipfix@ietf.org; Thu, 12 Oct 2006 11:39:57 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2f5-00074D-Me
	for ipfix@ietf.org; Thu, 12 Oct 2006 11:39:57 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9CFcgd22665
	for ; Thu, 12 Oct 2006 17:38:42 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Oct 2006 17:40:00 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1475481@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPFIX Interop Event
Thread-Index: AcbuFK3DdFoV5dHiQEqmIotONR0QOg==
From: "Zseby, Tanja" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [IPFIX] IPFIX Interop Event
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear IPFIX Implementers,

we organize a further IPFIX Interoperability testing event.=20

Date: November 29-30 (Wed/Thu)
Location: Fraunhofer FOKUS, Berlin, Germany

We will also offer a VPN for remote testing for those who cannot attend
in person.

The tests will mainly focus on SCTP and security aspects (TLS/IPsec).

If you want to participate (either attend the meeting or participate by
VPN), please send an email by Nov 5 to:=20
Carsten.Schmoll@fokus.fraunhofer.de

Kind regards,
Tanja

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



From ipfix-bounces@ietf.org Thu Oct 12 11:41:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY2f8-0001h9-03; Thu, 12 Oct 2006 11:39:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2f7-0001h4-3I
	for ipfix@ietf.org; Thu, 12 Oct 2006 11:39:57 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2f5-00074D-Me
	for ipfix@ietf.org; Thu, 12 Oct 2006 11:39:57 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9CFcgd22665
	for ; Thu, 12 Oct 2006 17:38:42 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Oct 2006 17:40:00 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1475481@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPFIX Interop Event
Thread-Index: AcbuFK3DdFoV5dHiQEqmIotONR0QOg==
From: "Zseby, Tanja" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [IPFIX] IPFIX Interop Event
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear IPFIX Implementers,

we organize a further IPFIX Interoperability testing event.=20

Date: November 29-30 (Wed/Thu)
Location: Fraunhofer FOKUS, Berlin, Germany

We will also offer a VPN for remote testing for those who cannot attend
in person.

The tests will mainly focus on SCTP and security aspects (TLS/IPsec).

If you want to participate (either attend the meeting or participate by
VPN), please send an email by Nov 5 to:=20
Carsten.Schmoll@fokus.fraunhofer.de

Kind regards,
Tanja

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



From ipfix-bounces@ietf.org Thu Oct 12 13:18:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY49x-0002Vs-1H; Thu, 12 Oct 2006 13:15:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY49w-0002Vh-2X
	for ipfix@ietf.org; Thu, 12 Oct 2006 13:15:52 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY49u-0007Mj-Lm
	for ipfix@ietf.org; Thu, 12 Oct 2006 13:15:52 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9CHEbd05731
	for ; Thu, 12 Oct 2006 19:14:37 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Oct 2006 19:15:56 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1475494@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPFIX Interop
Thread-Index: AcbuIhQ2s65tHHFnSKefttvxQB9AhA==
From: "Zseby, Tanja" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Subject: [IPFIX] IPFIX Interop
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi again,

because it was asked:
"we" is Fraunhofer FOKUS supported by other co-authors of the
Implementation Guidelines. The last 2 interop events were organized
together with the MOME project consortium. Since the MOME project has
finished, we are now organizing the event on our own. Apart from testing
implementations, a further goal is to utilize some outcome of the event
(e.g. common mistakes, problems with interpretation of the protocol
draft etc.) as input to improve/extend the implementation guidelines.

Kind regards,
Tanja

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



From ipfix-bounces@ietf.org Thu Oct 12 13:18:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY49x-0002Vs-1H; Thu, 12 Oct 2006 13:15:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY49w-0002Vh-2X
	for ipfix@ietf.org; Thu, 12 Oct 2006 13:15:52 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY49u-0007Mj-Lm
	for ipfix@ietf.org; Thu, 12 Oct 2006 13:15:52 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9CHEbd05731
	for ; Thu, 12 Oct 2006 19:14:37 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Oct 2006 19:15:56 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1475494@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPFIX Interop
Thread-Index: AcbuIhQ2s65tHHFnSKefttvxQB9AhA==
From: "Zseby, Tanja" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Subject: [IPFIX] IPFIX Interop
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi again,

because it was asked:
"we" is Fraunhofer FOKUS supported by other co-authors of the
Implementation Guidelines. The last 2 interop events were organized
together with the MOME project consortium. Since the MOME project has
finished, we are now organizing the event on our own. Apart from testing
implementations, a further goal is to utilize some outcome of the event
(e.g. common mistakes, problems with interpretation of the protocol
draft etc.) as input to improve/extend the implementation guidelines.

Kind regards,
Tanja

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



From ipfix-bounces@ietf.org Thu Oct 12 14:45:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY5Xb-0007ZW-J9; Thu, 12 Oct 2006 14:44:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5XZ-0007ZI-TB
	for ipfix@ietf.org; Thu, 12 Oct 2006 14:44:21 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY5XZ-00037K-5m
	for ipfix@ietf.org; Thu, 12 Oct 2006 14:44:21 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9CIiCUP026821 for ; Thu, 12 Oct 2006 14:44:16 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9CIglgL026771
	for ; Thu, 12 Oct 2006 14:42:47 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9CIglQf026769;
	Thu, 12 Oct 2006 14:42:47 -0400 (EDT)
Received: from [172.28.172.190] (vpn-10-25-4-2.remote.cert.org [10.25.4.2])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP
	id k9CIgkD0019473; Thu, 12 Oct 2006 14:42:46 -0400
In-Reply-To: <452DFCCC.8020003@cisco.com>
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452DFCCC.8020003@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <35A35C63-2790-447E-B38B-02ADF564A9BB@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Thu, 12 Oct 2006 11:42:10 -0700
To: Andrew Johnson 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d9ae72af46718088458d214998cc683
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Andrew and all,

Looks good to me!

Cheers,

Brian

On Oct 12, 2006, at 1:29 AM, Andrew Johnson wrote:

> Brian Trammell wrote:
>> Benoit and all,
>> Excellent - this looks good to me, and addresses all the concerns  
>> I had with scoping templates and observation IDs (and as you point  
>> out, has the added benefit of minimal change to the protocol as it  
>> stands).
>> One point: do we want to be more pedantic about defining a  
>> Transport Session for UDP? Both the SCTP and TCP Transport Session  
>> definitions have temporal limits (the Association or the  
>> Connection lifetime, defined by each transport protocol itself),  
>> while UDP does not. I would suggest (from a past message to the  
>> list):
>> In UDP, the transport session is known as the UDP session, which  
>> is uniquely identified by the IP addresses and UDP ports used,  
>> within the time between the first UDP packet sent by the EP in the  
>> session and the timeout after the last template retransmission.
>> Thoughts?
>
> In UDP the definition associated with a template ID has a certain
> lifetime.  The lifetime is different on the the Exporting Process and
> the Collecting Process.  I think we can simply extend the principle
> to apply to all definitions associated with identifiers that are
> scoped to the Transport Session.
>
> I think only one section would need updated.
>
>
> 10.3.7  Collecting Process
>
> OLD:
>   The Collecting Process MUST associate a lifetime with each Template
>   received via UDP.  Templates not refreshed by the Exporting Process
>   within the lifetime are expired at the Collecting Process.  If the
>   template is not refreshed by the Exporting Process before that
>   lifetime has expired, the Collecting Process MUST discard the
>   Template and any current and future associated Data Records.  In
>   which case, an alarm MUST be logged.
>   ...
>   The Collecting Process SHOULD accept Data Records without the
>   associated Template Record. If the Template Records have not been
>   received at the time Data Records are received, the Collecting
>   Process SHOULD store the Data Records for a short period of time and
>   decode them after the Template Records are received.  The short
>   period of time MUST be lower than the Template lifetime.
>
> NEW:
>   The Collecting Process MUST associate a lifetime with each Template
>   (or another of definition of an identifier considered unique within
>   the Transport Session) received via UDP.  Templates (and similar
>   definitions) not refreshed by the Exporting Process within the
>   lifetime are expired at the Collecting Process.  If the Template
>   (or other definition) is not refreshed before that lifetime has
>   expired, the Collecting Process MUST discard that definition
>   and any current and future associated Data Records.  In which case,
>   an alarm MUST be logged.
>   ...
>   The Collecting Process SHOULD accept Data Records without the
>   associated Template Record (or other definitions) required to decode
>   the Data Record. If the Template Records (or other definitions  
> such as
>   Common Properties) have not been received at the time Data Records
>   are received, the Collecting Process SHOULD store the Data Records
>   for a short period of time and decode them after the Template  
> Records
>   (or other definitions) are received. The short period of time  
> MUST be
>   lower than the lifetime of definitions associated with identifiers
>   considered unique within the UDP session.
>
> regards
>
> Andrew
>
>> - Brian
>> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>>> Dear all,
>>>
>>> Trying to address the concerns posted on the mailing recently  
>>> regarding "observation domain, template, and session", Andrew,  
>>> Paul, and I sat down and worked out a compromise. We're proposing  
>>> to make template IDs unique per (Observation Domain ID, Session)  
>>> pair. And NOT to scope the Observation Domain to the  
>>> communication session between the Exporting Process and  
>>> Collecting Process (as proposed by Andrew initially)
>>> I think that this compromise will make everybody happy as this  
>>> solution is mainly a clarification, as opposed to a protocol  
>>> design change.
>>>
>>> Problem Statement.
>>> If I read the protocol draft now, one interpretation could be: as  
>>> I see that the Template Ids are unique per Observation Domain,  
>>> and that the Observation Domain Id are RECOMMENDED to be unique  
>>> per IPFIX Device, this implies that the several Exporting  
>>> Processes of the same IPFIX Device must synchronize the  
>>> assignments of their Template Ids (to make sure that the Template  
>>> Id are unique per Observation Domain). This might prove difficult/ 
>>> impossible in some cases.
>>> Instead of imposing this, the other solution is to make the  
>>> template IDs unique per (Observation Domain ID, Session) pair.
>>> This makes sense as, logically, the template IDs have only a  
>>> local significance between E.P. and C.P.
>>> Note: I brought up the issue of load-balancing or backup where it  
>>> would be nice to have the same template IDs between two  
>>> connections. The solution in this case is to use a single E.P.  
>>> when load-balancing or backup is required.
>>>
>>> Please acknowledge that this compromise is fine with you.
>>>
>>> Note: 3 minor changes are required in the information elements  
>>> definitions in [IPFIX-INFO]
>>>
>>> Regards, Andrew, Paul, and Benoit.
>>>
>>> See below for the proposed changes.
>>>
>>> [IPFIX-PROTO]
>>>
>>> NEW:
>>> Transport Session
>>> In SCTP, the transport session is known as the SCTP association,  
>>> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
>>> TCP, the transport session is known as the TCP connection, which  
>>> is uniquely identified by the combination of IP addresses and TCP  
>>> ports used; In UDP, the transport session is known as the UDP  
>>> session, which is uniquely identified by the combination of IP  
>>> addresses and UDP ports used.
>>>
>>>
>>>
>>> OLD
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Observation
>>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>>
>>> NEW:
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Transport  
>>> Session and
>>>      Observation Domain that generated the Template ID.  Template  
>>> IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>> OLD (Section 4.4)
>>>      templateId              An identifier of a Template that
>>>                              locally unique to the Exporting
>>>                              Process.  This Information
>>>                              Element MUST be defined as a Scope
>>>                              Field.
>>> NEW
>>>      templateId              An identifier of a Template. This  
>>> Information
>>>                                    Element MUST be defined as a  
>>> Scope
>>>                                    Field.
>>>
>>> Section 3.1
>>> OLD
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally  
>>> unique to the Exporting Process.  The Exporting Process uses the  
>>> Observation Domain ID to uniquely identify to the Collecting  
>>> Process the Observation Domain that metered the Flows.  It is  
>>> RECOMMENDED that this identifier is also unique per IPFIX  
>>> Device.  Collecting Processes SHOULD use the combination of the  
>>> Exporter (exporterIPv4Address, exporterIPv6Address, or  
>>> exportingProcessId) and the Observation Domain ID field to  
>>> separate different export streams originating from the same  
>>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no  
>>> specific Observation Domain ID is relevant for the entire IPFIX  
>>> Message.  For example, when exporting the Exporting Process  
>>> Statistics, or in case of hierarchy of Collector when aggregated  
>>> data records are exported.
>>>
>>> NEW
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally  
>>> unique to the Exporting Process.  The Exporting Process uses the  
>>> Observation Domain ID to uniquely identify to the Collecting  
>>> Process the Observation Domain that metered the Flows.  It is  
>>> RECOMMENDED that this identifier is also unique per IPFIX  
>>> Device.  Collecting Processes SHOULD use the Transport Session  
>>> and the Observation Domain ID field to separate different export  
>>> streams originating from the same Exporting Process.  The  
>>> Observation Domain ID SHOULD be 0 when no specific Observation  
>>> Domain ID is relevant for the entire IPFIX Message.  For example,  
>>> when exporting the Exporting Process Statistics, or in case of  
>>> hierarchy of Collector when aggregated data records are exported.
>>>
>>> Section 8, Template Management
>>> OLD
>>> The Exporting Process assigns and maintains the Template IDs for  
>>> the Exporter's Observation Domains. A newly created Template  
>>> Record is assigned an unused Template ID by the Exporting Process.
>>>
>>> NEW
>>> The Exporting Process assigns and maintains the Template IDs per  
>>> SCTP association for the Exporter's Observation Domains.  A newly  
>>> created Template Record is assigned an unused Template ID by the  
>>> Exporting Process.
>>>
>>> OLD
>>> A Template ID MUST be unique per Observation Domain. Different  
>>> Observation Domains from the same Exporter may use the same  
>>> Template ID value to refer to different Templates.
>>>
>>> NEW
>>> Different Observation Domains from the same SCTP association may  
>>> use the same Template ID value to refer to different Templates.
>>>
>>> OLD
>>> When the Exporting Process restarts, due to the SCTP association  
>>> shutdown, all Template assignments are lost and Template IDs MUST  
>>> be re-assigned.
>>>
>>> NEW
>>> When the SCTP association shuts down or the Exporting Process  
>>> restarts, all Template assignments are lost and Template IDs MUST  
>>> be re-assigned.
>>>
>>> Section 9, Collecting Process's side
>>> OLD
>>> Template IDs are unique per IPFIX Device and per Observation  
>>> Domain.  If the Collecting Process receives a Template which has  
>>> already been received but which has not previously been withdrawn  
>>> (i.e. a Template Record from the same Exporter Observation Domain  
>>> with the same Template ID), then the Collecting Process MUST  
>>> shutdown the association.
>>>
>>>
>>> NEW
>>> Template IDs are unique per SCTP association and per Observation  
>>> Domain.  If the Collecting Process receives a Template which has  
>>> already been received but which has not previously been withdrawn  
>>> (i.e. a Template Record from the same Exporter Observation Domain  
>>> with the same Template ID received on the SCTP association), then  
>>> the Collecting Process MUST shutdown the association.
>>>
>>> OLD
>>>
>>> If a Collecting Process receives a Template Withdraw Message, the  
>>> Collecting Process MUST delete the corresponding Template Records  
>>> associated with the specific Exporter and specific Observation  
>>> Domain, and stop decoding IPFIX Messages that use the withdrawn  
>>> Templates.
>>>
>>> If the Collecting Process receives a Template Withdraw message  
>>> for a Template Record it has not received before, it MUST reset  
>>> the SCTP association, discard the IPFIX Message, and SHOULD log  
>>> the error as it does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several  
>>> Observation Domains from the same Exporter MUST be aware that the  
>>> uniqueness of the Template ID is not guaranteed across  
>>> Observation Domains.
>>>
>>> NEW
>>> If a Collecting Process receives a Template Withdraw Message, the  
>>> Collecting Process MUST delete the corresponding Template Records  
>>> associated with the specific SCTP association and specific  
>>> Observation Domain, and stop decoding IPFIX Messages that use the  
>>> withdrawn Templates.
>>> I
>>> f the Collecting Process receives a Template Withdraw message for  
>>> a Template Record it has not received before on this SCTP  
>>> assocation, it MUST reset the SCTP association, discard the IPFIX  
>>> Message, and SHOULD log the error as it does for malformed IPFIX  
>>> Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several  
>>> Observation Domains on the same Transport Session MUST be aware  
>>> that the uniqueness of the Template ID is not guaranteed across  
>>> Observation Domains.
>>>
>>> 10.3.7 Collecting Process
>>> OLD
>>> At any given time the Collecting Process SHOULD maintain the  
>>> following for all the current Template Records and Options  
>>> Template Records: >> Template ID, Template Definition, Last Received>.
>>>
>>> NEW
>>> Template IDs are unique per UDP session and per Observation  
>>> Domain.  At any given time the Collecting Process SHOULD maintain  
>>> the following for all the current Template Records and Options  
>>> Template Records: >> Observation Domain ID, Template ID, Template Definition, Last  
>>> Received>.
>>>
>>>
>>> 10.4.2.2 Template Management
>>>
>>> Template IDs are unique per TCP connection and per Observation  
>>> Domain.  A Collecting Process MUST record all Template and  
>>> Options Template Records for the duration of the connection, as  
>>> an Exporting Process is not required to re-export Template Records.
>>>
>>>
>>> [IPFIX-INFO]
>>> NEWTransport Session
>>> In SCTP, the transport session is known as the SCTP association,  
>>> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
>>> TCP, the transport session is known as the TCP connection, which  
>>> is uniquely identified by the combination of IP addresses and TCP  
>>> ports used; In UDP, the transport session is known as the UDP  
>>> session, which is uniquely identified by the combination of IP  
>>> addresses and UDP ports used.
>>> OLD 5.1.8. templateId Description: An identifier of a Template  
>>> that is locally unique within an Observation Domain. NEW 5.1.8.  
>>> templateId Description: An identifier of a Template that is  
>>> locally unique within an Observation Domain and the Transport  
>>> Session. OLD 5.1.7. flowId Description: An identifier of a Flow  
>>> that is unique within an Observation Domain. This Information  
>>> Element can be used to distinguish between different Flows if  
>>> Flow Keys such as IP addresses and port numbers are not reported  
>>> or are reported in separate records. NEW 5.1.7. flowId  
>>> Description: An identifier of a Flow that is unique within an  
>>> Observation Domain and the Transport Session. This Information  
>>> Element can be used to distinguish between different Flows if  
>>> Flow Keys such as IP addresses and port numbers are not reported  
>>> or are reported in separate records. OLD 5.1.11.  
>>> commonPropertiesId Description: An identifier of a set of common  
>>> properties that is unique per Observation Domain. Typically, this  
>>> Information Element is used to link to information reported in  
>>> separate records. NEW: 5.1.11. commonPropertiesId Description: An  
>>> identifier of a set of common properties that is unique per  
>>> Observation Domain and Transport Session. Typically, this  
>>> Information Element is used to link to information reported in  
>>> separate records.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Thu Oct 12 14:45:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY5Xb-0007ZW-J9; Thu, 12 Oct 2006 14:44:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5XZ-0007ZI-TB
	for ipfix@ietf.org; Thu, 12 Oct 2006 14:44:21 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY5XZ-00037K-5m
	for ipfix@ietf.org; Thu, 12 Oct 2006 14:44:21 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9CIiCUP026821 for ; Thu, 12 Oct 2006 14:44:16 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9CIglgL026771
	for ; Thu, 12 Oct 2006 14:42:47 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9CIglQf026769;
	Thu, 12 Oct 2006 14:42:47 -0400 (EDT)
Received: from [172.28.172.190] (vpn-10-25-4-2.remote.cert.org [10.25.4.2])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP
	id k9CIgkD0019473; Thu, 12 Oct 2006 14:42:46 -0400
In-Reply-To: <452DFCCC.8020003@cisco.com>
References: <452CECC2.5080703@cisco.com>
	<1BD78849-5790-42C6-9898-43577BC33288@cert.org>
	<452DFCCC.8020003@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <35A35C63-2790-447E-B38B-02ADF564A9BB@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] observation domain, template, and session: compromise
Date: Thu, 12 Oct 2006 11:42:10 -0700
To: Andrew Johnson 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d9ae72af46718088458d214998cc683
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Andrew and all,

Looks good to me!

Cheers,

Brian

On Oct 12, 2006, at 1:29 AM, Andrew Johnson wrote:

> Brian Trammell wrote:
>> Benoit and all,
>> Excellent - this looks good to me, and addresses all the concerns  
>> I had with scoping templates and observation IDs (and as you point  
>> out, has the added benefit of minimal change to the protocol as it  
>> stands).
>> One point: do we want to be more pedantic about defining a  
>> Transport Session for UDP? Both the SCTP and TCP Transport Session  
>> definitions have temporal limits (the Association or the  
>> Connection lifetime, defined by each transport protocol itself),  
>> while UDP does not. I would suggest (from a past message to the  
>> list):
>> In UDP, the transport session is known as the UDP session, which  
>> is uniquely identified by the IP addresses and UDP ports used,  
>> within the time between the first UDP packet sent by the EP in the  
>> session and the timeout after the last template retransmission.
>> Thoughts?
>
> In UDP the definition associated with a template ID has a certain
> lifetime.  The lifetime is different on the the Exporting Process and
> the Collecting Process.  I think we can simply extend the principle
> to apply to all definitions associated with identifiers that are
> scoped to the Transport Session.
>
> I think only one section would need updated.
>
>
> 10.3.7  Collecting Process
>
> OLD:
>   The Collecting Process MUST associate a lifetime with each Template
>   received via UDP.  Templates not refreshed by the Exporting Process
>   within the lifetime are expired at the Collecting Process.  If the
>   template is not refreshed by the Exporting Process before that
>   lifetime has expired, the Collecting Process MUST discard the
>   Template and any current and future associated Data Records.  In
>   which case, an alarm MUST be logged.
>   ...
>   The Collecting Process SHOULD accept Data Records without the
>   associated Template Record. If the Template Records have not been
>   received at the time Data Records are received, the Collecting
>   Process SHOULD store the Data Records for a short period of time and
>   decode them after the Template Records are received.  The short
>   period of time MUST be lower than the Template lifetime.
>
> NEW:
>   The Collecting Process MUST associate a lifetime with each Template
>   (or another of definition of an identifier considered unique within
>   the Transport Session) received via UDP.  Templates (and similar
>   definitions) not refreshed by the Exporting Process within the
>   lifetime are expired at the Collecting Process.  If the Template
>   (or other definition) is not refreshed before that lifetime has
>   expired, the Collecting Process MUST discard that definition
>   and any current and future associated Data Records.  In which case,
>   an alarm MUST be logged.
>   ...
>   The Collecting Process SHOULD accept Data Records without the
>   associated Template Record (or other definitions) required to decode
>   the Data Record. If the Template Records (or other definitions  
> such as
>   Common Properties) have not been received at the time Data Records
>   are received, the Collecting Process SHOULD store the Data Records
>   for a short period of time and decode them after the Template  
> Records
>   (or other definitions) are received. The short period of time  
> MUST be
>   lower than the lifetime of definitions associated with identifiers
>   considered unique within the UDP session.
>
> regards
>
> Andrew
>
>> - Brian
>> On Oct 11, 2006, at 6:08 AM, Benoit Claise wrote:
>>> Dear all,
>>>
>>> Trying to address the concerns posted on the mailing recently  
>>> regarding "observation domain, template, and session", Andrew,  
>>> Paul, and I sat down and worked out a compromise. We're proposing  
>>> to make template IDs unique per (Observation Domain ID, Session)  
>>> pair. And NOT to scope the Observation Domain to the  
>>> communication session between the Exporting Process and  
>>> Collecting Process (as proposed by Andrew initially)
>>> I think that this compromise will make everybody happy as this  
>>> solution is mainly a clarification, as opposed to a protocol  
>>> design change.
>>>
>>> Problem Statement.
>>> If I read the protocol draft now, one interpretation could be: as  
>>> I see that the Template Ids are unique per Observation Domain,  
>>> and that the Observation Domain Id are RECOMMENDED to be unique  
>>> per IPFIX Device, this implies that the several Exporting  
>>> Processes of the same IPFIX Device must synchronize the  
>>> assignments of their Template Ids (to make sure that the Template  
>>> Id are unique per Observation Domain). This might prove difficult/ 
>>> impossible in some cases.
>>> Instead of imposing this, the other solution is to make the  
>>> template IDs unique per (Observation Domain ID, Session) pair.
>>> This makes sense as, logically, the template IDs have only a  
>>> local significance between E.P. and C.P.
>>> Note: I brought up the issue of load-balancing or backup where it  
>>> would be nice to have the same template IDs between two  
>>> connections. The solution in this case is to use a single E.P.  
>>> when load-balancing or backup is required.
>>>
>>> Please acknowledge that this compromise is fine with you.
>>>
>>> Note: 3 minor changes are required in the information elements  
>>> definitions in [IPFIX-INFO]
>>>
>>> Regards, Andrew, Paul, and Benoit.
>>>
>>> See below for the proposed changes.
>>>
>>> [IPFIX-PROTO]
>>>
>>> NEW:
>>> Transport Session
>>> In SCTP, the transport session is known as the SCTP association,  
>>> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
>>> TCP, the transport session is known as the TCP connection, which  
>>> is uniquely identified by the combination of IP addresses and TCP  
>>> ports used; In UDP, the transport session is known as the UDP  
>>> session, which is uniquely identified by the combination of IP  
>>> addresses and UDP ports used.
>>>
>>>
>>>
>>> OLD
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Observation
>>>       Domain that generated the Template ID.  Template IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>>
>>> NEW:
>>> Template ID
>>>       Each of the newly generated Template Records is given a unique
>>>       Template ID.  This uniqueness is local to the Transport  
>>> Session and
>>>      Observation Domain that generated the Template ID.  Template  
>>> IDs 0-255 are
>>>       reserved for Template Sets, Options Template Sets, and other
>>>       reserved Sets yet to be created.  Template IDs of Data Sets
>>>       are numbered from 256 to 65535.  There are no constraints
>>>       regarding the order of the Template ID allocation.
>>>
>>> OLD (Section 4.4)
>>>      templateId              An identifier of a Template that
>>>                              locally unique to the Exporting
>>>                              Process.  This Information
>>>                              Element MUST be defined as a Scope
>>>                              Field.
>>> NEW
>>>      templateId              An identifier of a Template. This  
>>> Information
>>>                                    Element MUST be defined as a  
>>> Scope
>>>                                    Field.
>>>
>>> Section 3.1
>>> OLD
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally  
>>> unique to the Exporting Process.  The Exporting Process uses the  
>>> Observation Domain ID to uniquely identify to the Collecting  
>>> Process the Observation Domain that metered the Flows.  It is  
>>> RECOMMENDED that this identifier is also unique per IPFIX  
>>> Device.  Collecting Processes SHOULD use the combination of the  
>>> Exporter (exporterIPv4Address, exporterIPv6Address, or  
>>> exportingProcessId) and the Observation Domain ID field to  
>>> separate different export streams originating from the same  
>>> Exporting Process.  The Observation Domain ID SHOULD be 0 when no  
>>> specific Observation Domain ID is relevant for the entire IPFIX  
>>> Message.  For example, when exporting the Exporting Process  
>>> Statistics, or in case of hierarchy of Collector when aggregated  
>>> data records are exported.
>>>
>>> NEW
>>> Observation Domain ID
>>> A 32-bit identifier of the Observation Domain that is locally  
>>> unique to the Exporting Process.  The Exporting Process uses the  
>>> Observation Domain ID to uniquely identify to the Collecting  
>>> Process the Observation Domain that metered the Flows.  It is  
>>> RECOMMENDED that this identifier is also unique per IPFIX  
>>> Device.  Collecting Processes SHOULD use the Transport Session  
>>> and the Observation Domain ID field to separate different export  
>>> streams originating from the same Exporting Process.  The  
>>> Observation Domain ID SHOULD be 0 when no specific Observation  
>>> Domain ID is relevant for the entire IPFIX Message.  For example,  
>>> when exporting the Exporting Process Statistics, or in case of  
>>> hierarchy of Collector when aggregated data records are exported.
>>>
>>> Section 8, Template Management
>>> OLD
>>> The Exporting Process assigns and maintains the Template IDs for  
>>> the Exporter's Observation Domains. A newly created Template  
>>> Record is assigned an unused Template ID by the Exporting Process.
>>>
>>> NEW
>>> The Exporting Process assigns and maintains the Template IDs per  
>>> SCTP association for the Exporter's Observation Domains.  A newly  
>>> created Template Record is assigned an unused Template ID by the  
>>> Exporting Process.
>>>
>>> OLD
>>> A Template ID MUST be unique per Observation Domain. Different  
>>> Observation Domains from the same Exporter may use the same  
>>> Template ID value to refer to different Templates.
>>>
>>> NEW
>>> Different Observation Domains from the same SCTP association may  
>>> use the same Template ID value to refer to different Templates.
>>>
>>> OLD
>>> When the Exporting Process restarts, due to the SCTP association  
>>> shutdown, all Template assignments are lost and Template IDs MUST  
>>> be re-assigned.
>>>
>>> NEW
>>> When the SCTP association shuts down or the Exporting Process  
>>> restarts, all Template assignments are lost and Template IDs MUST  
>>> be re-assigned.
>>>
>>> Section 9, Collecting Process's side
>>> OLD
>>> Template IDs are unique per IPFIX Device and per Observation  
>>> Domain.  If the Collecting Process receives a Template which has  
>>> already been received but which has not previously been withdrawn  
>>> (i.e. a Template Record from the same Exporter Observation Domain  
>>> with the same Template ID), then the Collecting Process MUST  
>>> shutdown the association.
>>>
>>>
>>> NEW
>>> Template IDs are unique per SCTP association and per Observation  
>>> Domain.  If the Collecting Process receives a Template which has  
>>> already been received but which has not previously been withdrawn  
>>> (i.e. a Template Record from the same Exporter Observation Domain  
>>> with the same Template ID received on the SCTP association), then  
>>> the Collecting Process MUST shutdown the association.
>>>
>>> OLD
>>>
>>> If a Collecting Process receives a Template Withdraw Message, the  
>>> Collecting Process MUST delete the corresponding Template Records  
>>> associated with the specific Exporter and specific Observation  
>>> Domain, and stop decoding IPFIX Messages that use the withdrawn  
>>> Templates.
>>>
>>> If the Collecting Process receives a Template Withdraw message  
>>> for a Template Record it has not received before, it MUST reset  
>>> the SCTP association, discard the IPFIX Message, and SHOULD log  
>>> the error as it does for malformed IPFIX Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several  
>>> Observation Domains from the same Exporter MUST be aware that the  
>>> uniqueness of the Template ID is not guaranteed across  
>>> Observation Domains.
>>>
>>> NEW
>>> If a Collecting Process receives a Template Withdraw Message, the  
>>> Collecting Process MUST delete the corresponding Template Records  
>>> associated with the specific SCTP association and specific  
>>> Observation Domain, and stop decoding IPFIX Messages that use the  
>>> withdrawn Templates.
>>> I
>>> f the Collecting Process receives a Template Withdraw message for  
>>> a Template Record it has not received before on this SCTP  
>>> assocation, it MUST reset the SCTP association, discard the IPFIX  
>>> Message, and SHOULD log the error as it does for malformed IPFIX  
>>> Messages.
>>>
>>> A Collecting Process that receives IPFIX Messages from several  
>>> Observation Domains on the same Transport Session MUST be aware  
>>> that the uniqueness of the Template ID is not guaranteed across  
>>> Observation Domains.
>>>
>>> 10.3.7 Collecting Process
>>> OLD
>>> At any given time the Collecting Process SHOULD maintain the  
>>> following for all the current Template Records and Options  
>>> Template Records: >> Template ID, Template Definition, Last Received>.
>>>
>>> NEW
>>> Template IDs are unique per UDP session and per Observation  
>>> Domain.  At any given time the Collecting Process SHOULD maintain  
>>> the following for all the current Template Records and Options  
>>> Template Records: >> Observation Domain ID, Template ID, Template Definition, Last  
>>> Received>.
>>>
>>>
>>> 10.4.2.2 Template Management
>>>
>>> Template IDs are unique per TCP connection and per Observation  
>>> Domain.  A Collecting Process MUST record all Template and  
>>> Options Template Records for the duration of the connection, as  
>>> an Exporting Process is not required to re-export Template Records.
>>>
>>>
>>> [IPFIX-INFO]
>>> NEWTransport Session
>>> In SCTP, the transport session is known as the SCTP association,  
>>> which is uniquely identified by the SCTP endpoints [RFC2960]; in  
>>> TCP, the transport session is known as the TCP connection, which  
>>> is uniquely identified by the combination of IP addresses and TCP  
>>> ports used; In UDP, the transport session is known as the UDP  
>>> session, which is uniquely identified by the combination of IP  
>>> addresses and UDP ports used.
>>> OLD 5.1.8. templateId Description: An identifier of a Template  
>>> that is locally unique within an Observation Domain. NEW 5.1.8.  
>>> templateId Description: An identifier of a Template that is  
>>> locally unique within an Observation Domain and the Transport  
>>> Session. OLD 5.1.7. flowId Description: An identifier of a Flow  
>>> that is unique within an Observation Domain. This Information  
>>> Element can be used to distinguish between different Flows if  
>>> Flow Keys such as IP addresses and port numbers are not reported  
>>> or are reported in separate records. NEW 5.1.7. flowId  
>>> Description: An identifier of a Flow that is unique within an  
>>> Observation Domain and the Transport Session. This Information  
>>> Element can be used to distinguish between different Flows if  
>>> Flow Keys such as IP addresses and port numbers are not reported  
>>> or are reported in separate records. OLD 5.1.11.  
>>> commonPropertiesId Description: An identifier of a set of common  
>>> properties that is unique per Observation Domain. Typically, this  
>>> Information Element is used to link to information reported in  
>>> separate records. NEW: 5.1.11. commonPropertiesId Description: An  
>>> identifier of a set of common properties that is unique per  
>>> Observation Domain and Transport Session. Typically, this  
>>> Information Element is used to link to information reported in  
>>> separate records.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Fri Oct 13 15:51:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GYT2w-0007GC-Vn; Fri, 13 Oct 2006 15:50:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GYT2h-00071z-14; Fri, 13 Oct 2006 15:50:03 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GYT2g-0001yJ-CO; Fri, 13 Oct 2006 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5575C328E4;
	Fri, 13 Oct 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GYT2g-0000yn-5c; Fri, 13 Oct 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Fri, 13 Oct 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-protocol-23.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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 Protocol for the Exchange of IP Traffic Flow Information
	Author(s)	: B. Claise
	Filename	: draft-ietf-ipfix-protocol-23.txt
	Pages		: 63
	Date		: 2006-10-13
	
This document specifies the IPFIX protocol that serves for 
   transmitting IP traffic flow information over the network.  In order 
   to transmit IP traffic flow information from an exporting process to 
   an information collecting process, a common representation of flow 
   data and a standard means of communicating them is required. This 
   document describes how the IPFIX data and templates records are 
   carried over a number of transport protocols from an IPFIX exporting 
   process to an IPFIX collecting process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-protocol-23.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-13114759.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-23.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-13114759.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--





From ipfix-bounces@ietf.org Fri Oct 13 15:51:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GYT2w-0007GC-Vn; Fri, 13 Oct 2006 15:50:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GYT2h-00071z-14; Fri, 13 Oct 2006 15:50:03 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GYT2g-0001yJ-CO; Fri, 13 Oct 2006 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5575C328E4;
	Fri, 13 Oct 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GYT2g-0000yn-5c; Fri, 13 Oct 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Fri, 13 Oct 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-protocol-23.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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 Protocol for the Exchange of IP Traffic Flow Information
	Author(s)	: B. Claise
	Filename	: draft-ietf-ipfix-protocol-23.txt
	Pages		: 63
	Date		: 2006-10-13
	
This document specifies the IPFIX protocol that serves for 
   transmitting IP traffic flow information over the network.  In order 
   to transmit IP traffic flow information from an exporting process to 
   an information collecting process, a common representation of flow 
   data and a standard means of communicating them is required. This 
   document describes how the IPFIX data and templates records are 
   carried over a number of transport protocols from an IPFIX exporting 
   process to an IPFIX collecting process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-protocol-23.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-13114759.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-23.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-13114759.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--





From ipfix-bounces@ietf.org Sun Oct 15 03:19:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ0GQ-0005Fb-Mj; Sun, 15 Oct 2006 03:18:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0GP-0005FW-T2
	for ipfix@ietf.org; Sun, 15 Oct 2006 03:18:25 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ0GL-0005yr-SO
	for ipfix@ietf.org; Sun, 15 Oct 2006 03:18:25 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 7015E1BAC9E;
	Sun, 15 Oct 2006 09:18:19 +0200 (CEST)
Date: Sun, 15 Oct 2006 09:18:13 +0200
From: Juergen Quittek 
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Message-ID: <3698BB5BA217DA9BAB358D82@[61.213.6.135]>
In-Reply-To: <45251A10.9060300@sfc.wide.ad.jp>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul,

What do you think we would loose if we allow sending 64 bit sysuptimes?
We would still be backwards compatible with NetFlowv9 (that uses 32 bit
sysuptimes) but at the same time allow for longer values if required,
for example, at devices without an absolute clock being set.

Thanks,

    Juergen


--On 05.10.2006 23:43 Uhr +0900 Hitoshi Irino wrote:

> Dear paul,
>
> Paul Aitken wrote:
>> Brian, Hotishi-san,
>>
>>>> In any case, I'd recommend to the WG that the SysUpTime IEs be
>>>> redefined as 64 bits.
>>>
>>> Thank you for your suggestion,
>>> I also agree to extend data type of SysUpTime IEs to unsigned64.
>>
>> I disagree.
>>
>> The main advantage of sending sysuptime in netflow v9 is to save space,
>> since each flow contains two 32 bit quantities (start and end time) that
>> are referenced to another two 32-bit quantities (sysUpTime and UNIX
>> Secs) in the header.
>>
>> IPFIX doesn't have sysuptime in the header (only Export time), so you
>> have to send a seperate systemInitTimeMilliseconds. Sending that per
>> flow would be wasteful. Perhaps it could be sent as an option.
>
> I know that systemInitTimeMilliseconds can be sent in option.
> Do you suggest that exporter update systemInitTimeMilliseconds whenever SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.)
> But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" are different.
> (systemInitTimeMilliseconds is defined as "The absolute timestamp of the last (re-)initialization of the IFPIX Device")
>
>> Sending 64 bit sysuptimes completely negates that advantage. At that
>> point you'd be far better sending the absolute flowStart* and flowEnd*
>> IEs which are also 64 bits, but which saves you from performing any
>> calculations to convert the relative sysuptimes to absolute values.
>
> But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime whose data type are unsgined64.
> Therefore, I think 64 bit sysuptimes do not negates that advantage.
>
> If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, and the new IE should be sent with systemInitTimeMilliseconds in option.
>
> regards,
> Hitoshi Irino
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Sun Oct 15 03:19:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ0GQ-0005Fb-Mj; Sun, 15 Oct 2006 03:18:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0GP-0005FW-T2
	for ipfix@ietf.org; Sun, 15 Oct 2006 03:18:25 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ0GL-0005yr-SO
	for ipfix@ietf.org; Sun, 15 Oct 2006 03:18:25 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 7015E1BAC9E;
	Sun, 15 Oct 2006 09:18:19 +0200 (CEST)
Date: Sun, 15 Oct 2006 09:18:13 +0200
From: Juergen Quittek 
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Message-ID: <3698BB5BA217DA9BAB358D82@[61.213.6.135]>
In-Reply-To: <45251A10.9060300@sfc.wide.ad.jp>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul,

What do you think we would loose if we allow sending 64 bit sysuptimes?
We would still be backwards compatible with NetFlowv9 (that uses 32 bit
sysuptimes) but at the same time allow for longer values if required,
for example, at devices without an absolute clock being set.

Thanks,

    Juergen


--On 05.10.2006 23:43 Uhr +0900 Hitoshi Irino wrote:

> Dear paul,
>
> Paul Aitken wrote:
>> Brian, Hotishi-san,
>>
>>>> In any case, I'd recommend to the WG that the SysUpTime IEs be
>>>> redefined as 64 bits.
>>>
>>> Thank you for your suggestion,
>>> I also agree to extend data type of SysUpTime IEs to unsigned64.
>>
>> I disagree.
>>
>> The main advantage of sending sysuptime in netflow v9 is to save space,
>> since each flow contains two 32 bit quantities (start and end time) that
>> are referenced to another two 32-bit quantities (sysUpTime and UNIX
>> Secs) in the header.
>>
>> IPFIX doesn't have sysuptime in the header (only Export time), so you
>> have to send a seperate systemInitTimeMilliseconds. Sending that per
>> flow would be wasteful. Perhaps it could be sent as an option.
>
> I know that systemInitTimeMilliseconds can be sent in option.
> Do you suggest that exporter update systemInitTimeMilliseconds whenever SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.)
> But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" are different.
> (systemInitTimeMilliseconds is defined as "The absolute timestamp of the last (re-)initialization of the IFPIX Device")
>
>> Sending 64 bit sysuptimes completely negates that advantage. At that
>> point you'd be far better sending the absolute flowStart* and flowEnd*
>> IEs which are also 64 bits, but which saves you from performing any
>> calculations to convert the relative sysuptimes to absolute values.
>
> But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime whose data type are unsgined64.
> Therefore, I think 64 bit sysuptimes do not negates that advantage.
>
> If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, and the new IE should be sent with systemInitTimeMilliseconds in option.
>
> regards,
> Hitoshi Irino
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Sun Oct 15 04:01:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ0vL-0003o7-CH; Sun, 15 Oct 2006 04:00:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0vJ-0003nx-VD
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:00:41 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ0vD-0003mf-Gj
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:00:41 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 6F8A31BAC9E;
	Sun, 15 Oct 2006 10:00:31 +0200 (CEST)
Date: Sun, 15 Oct 2006 10:00:26 +0200
From: Juergen Quittek 
To: Lutz Mark , Paul Aitken 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
Message-ID: <2742A316245C642E5AE60DB5@[61.213.6.135]>
In-Reply-To: <452A68E5.7070203@lehe.de>
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul and Lutz,

Here is a brief summary of the situation so far.

We have three IEs related to fragmentation:

#54=A0 fragmentIdentification=A0unsigned32=A0
#88=A0 fragmentOffset=A0unsigned16=A0
#197=A0fragmentFlags=A0unsigned8=A0
=A0=A0
Currently, all three can be used for IPv4 as well as for IPv6.

Now, you request to split fragmentIdentification into two IEs,
one specific for IPv4 and one for specific for IPv6.

The only argument for this that I read so far is saving bandwidth
if you have to report mixed traffic with IPv4 and IPv6, because
the pure IPv4 identifier has half the length of the IPv6 identifier.

Still I do not get this argument:

  1. If you have only IPv4 traffic, you can use reduced encoding and
     waste no bandwidth.

  2. If you report IPv6 traffic only, there is no issue.

  3. If you report mixed traffic, then the current IEs give you two
     options:
     a) Either use a single template for reporting IPv4 and IPv6.
        This implies a waste of 16 bits per IPv4 record
     b) You use different templates for IPv4 and IPv6 records.
        Then you would use 16 bit encoding for the IPv4 record
        and 32 bit encoding for the IPv6 record.

If we split fragmentIdentification into fragmentIdentificationIPv4
and fragmentIdentificationIPv6, then the only achievement would be
that 3.a) is not possible anymore.

Is this what you want to achieve or am I somehow mistaken?
Are there other arguments for the split that I have ignored?

Thanks,

    Juergen


--On 09.10.2006 17:21 Uhr +0200 Lutz Mark wrote:

>
>> I think I would prefer to go back to #54 =3D IPv4 ID (coming from the
>> netflow v9 definition) and create a new fragmentIdentificationIPv6 IE.
>
> I support this. We had this discussion before:
> http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html
>
> I still prefer to use a name that
> makes it clear that this info is
> part of the IPv6 extension header.
>
> Best regards,
> Lutz
>
>
>
>



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



From ipfix-bounces@ietf.org Sun Oct 15 04:01:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ0vL-0003o7-CH; Sun, 15 Oct 2006 04:00:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0vJ-0003nx-VD
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:00:41 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ0vD-0003mf-Gj
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:00:41 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 6F8A31BAC9E;
	Sun, 15 Oct 2006 10:00:31 +0200 (CEST)
Date: Sun, 15 Oct 2006 10:00:26 +0200
From: Juergen Quittek 
To: Lutz Mark , Paul Aitken 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
Message-ID: <2742A316245C642E5AE60DB5@[61.213.6.135]>
In-Reply-To: <452A68E5.7070203@lehe.de>
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Paul and Lutz,

Here is a brief summary of the situation so far.

We have three IEs related to fragmentation:

#54=A0 fragmentIdentification=A0unsigned32=A0
#88=A0 fragmentOffset=A0unsigned16=A0
#197=A0fragmentFlags=A0unsigned8=A0
=A0=A0
Currently, all three can be used for IPv4 as well as for IPv6.

Now, you request to split fragmentIdentification into two IEs,
one specific for IPv4 and one for specific for IPv6.

The only argument for this that I read so far is saving bandwidth
if you have to report mixed traffic with IPv4 and IPv6, because
the pure IPv4 identifier has half the length of the IPv6 identifier.

Still I do not get this argument:

  1. If you have only IPv4 traffic, you can use reduced encoding and
     waste no bandwidth.

  2. If you report IPv6 traffic only, there is no issue.

  3. If you report mixed traffic, then the current IEs give you two
     options:
     a) Either use a single template for reporting IPv4 and IPv6.
        This implies a waste of 16 bits per IPv4 record
     b) You use different templates for IPv4 and IPv6 records.
        Then you would use 16 bit encoding for the IPv4 record
        and 32 bit encoding for the IPv6 record.

If we split fragmentIdentification into fragmentIdentificationIPv4
and fragmentIdentificationIPv6, then the only achievement would be
that 3.a) is not possible anymore.

Is this what you want to achieve or am I somehow mistaken?
Are there other arguments for the split that I have ignored?

Thanks,

    Juergen


--On 09.10.2006 17:21 Uhr +0200 Lutz Mark wrote:

>
>> I think I would prefer to go back to #54 =3D IPv4 ID (coming from the
>> netflow v9 definition) and create a new fragmentIdentificationIPv6 IE.
>
> I support this. We had this discussion before:
> http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html
>
> I still prefer to use a name that
> makes it clear that this info is
> part of the IPv6 extension header.
>
> Best regards,
> Lutz
>
>
>
>



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



From ipfix-bounces@ietf.org Sun Oct 15 04:23:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ1GV-0002hK-Aj; Sun, 15 Oct 2006 04:22:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ1GU-0002bD-DJ
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:22:34 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ1GO-0001Pe-CA
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:22:34 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 89E371BAC9E;
	Sun, 15 Oct 2006 10:22:26 +0200 (CEST)
Date: Sun, 15 Oct 2006 10:22:21 +0200
From: Juergen Quittek 
To: Lutz Mark , Paul Aitken 
Subject: Re: [IPFIX] IPFIX totalLength?
Message-ID: <42C6DB58A53456C327DD88B5@[61.213.6.135]>
In-Reply-To: <452A6D41.1040707@fokus.fraunhofer.de>
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Lutz and Paul,

--On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:

>
>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>> could not find one.
>>
>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>
>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>> "IPtotalLength" IE.

I agree that we should provide an IE for reporting this information.

Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
that can be applied to all IP packets? I have a preference for the generic one,
because it gives us more options when applying it.

The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
because the maximum jumbo payload length is 2^32 - 1 and with the additional
40 octets from the header we exceed what can be represented by 32 bits.

> yes, and to make it complete we need packetTotalLength to
> be able to count link layer bytes also.

We have already #312 dataLinkFrameSize in the PSAMP info model.
I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
to converge before submitting a new version.  But you can find the
set of IEs that is under discussion for PSAMP-INFO at the IPFIX
Info Model Browser at .
PSAMP-INFO elements have IDs >= 300.

Thanks,

    Juergen



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



From ipfix-bounces@ietf.org Sun Oct 15 04:23:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ1GV-0002hK-Aj; Sun, 15 Oct 2006 04:22:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ1GU-0002bD-DJ
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:22:34 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ1GO-0001Pe-CA
	for ipfix@ietf.org; Sun, 15 Oct 2006 04:22:34 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 89E371BAC9E;
	Sun, 15 Oct 2006 10:22:26 +0200 (CEST)
Date: Sun, 15 Oct 2006 10:22:21 +0200
From: Juergen Quittek 
To: Lutz Mark , Paul Aitken 
Subject: Re: [IPFIX] IPFIX totalLength?
Message-ID: <42C6DB58A53456C327DD88B5@[61.213.6.135]>
In-Reply-To: <452A6D41.1040707@fokus.fraunhofer.de>
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Lutz and Paul,

--On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:

>
>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>> could not find one.
>>
>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>
>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>> "IPtotalLength" IE.

I agree that we should provide an IE for reporting this information.

Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
that can be applied to all IP packets? I have a preference for the generic one,
because it gives us more options when applying it.

The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
because the maximum jumbo payload length is 2^32 - 1 and with the additional
40 octets from the header we exceed what can be represented by 32 bits.

> yes, and to make it complete we need packetTotalLength to
> be able to count link layer bytes also.

We have already #312 dataLinkFrameSize in the PSAMP info model.
I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
to converge before submitting a new version.  But you can find the
set of IEs that is under discussion for PSAMP-INFO at the IPFIX
Info Model Browser at .
PSAMP-INFO elements have IDs >= 300.

Thanks,

    Juergen



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



From ipfix-bounces@ietf.org Sun Oct 15 11:00:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ7Rm-0004FE-4f; Sun, 15 Oct 2006 10:58:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ7Rk-0004F9-JA
	for ipfix@ietf.org; Sun, 15 Oct 2006 10:58:36 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ7Ri-0004oS-73
	for ipfix@ietf.org; Sun, 15 Oct 2006 10:58:36 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 16:58:35 +0200
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.20060308/8.12.11) with ESMTP id
	k9FEwXkC000370; Sun, 15 Oct 2006 16:58:33 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FEwTmd019866; 
	Sun, 15 Oct 2006 16:58:30 +0200 (MEST)
Received: from [10.61.65.69] (ams3-vpn-dhcp325.cisco.com [10.61.65.69])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA29339;
	Sun, 15 Oct 2006 15:58:28 +0100 (BST)
Message-ID: <45324C91.5090507@cisco.com>
Date: Sun, 15 Oct 2006 15:58:25 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
In-Reply-To: <3698BB5BA217DA9BAB358D82@[61.213.6.135]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=3312; t=1160924313; x=1161788313;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=Vc6LvhIfLcNOsFdBegi2w0dw1Ukqp3KxjgcDiwbkUl9JzAdw6jyfbU+pckfm6Uo9YszLSBSA
	nXufc2/2kOm43k1PHi3icYXFpCY+U5VsFUZkDBkpSLv1IPrgktJEgsTW;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

> What do you think we would loose if we allow sending 64 bit sysuptimes?

I already explained my objection quite clearly, and I didn't hear a good 
counter argument yet.

To reiterate:

The advantage of sending sysuptimes is they're only 32 bits long.

In netflow v9 they reference the sysuptime in the message header. But 
this has been removed from the IPFIX header, so when using IPFIX you 
must also send systemInitTimeMilliseconds (an additional 64 bits).

Sending flowStartSysUpTime, flowEndSysUpTime and 
systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is 
no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 
+ 64 = 128 bits) (or even sending the equivalent Micro or Nano IEs, 
which are also 64 bits each).

In fact, it's more of an overhead due to the convertion of the relative 
sysuptimes to absolute times.

The only saving to be made is if systemInitTimeMilliseconds can be sent 
seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits 
per flow, though still with the conversion overhead.

What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 
192 bits per flow *plus* the additional overhead of conversion, which is 
clearly a lot less efficient than sending flowStartMilliseconds and 
flowEndMilliseconds (64 + 64 = 128 bits, with no conversion required).

Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 
= 128 bits per flow (so equivalent to flowStartMilliseconds and 
flowEndMilliseconds) but still with the conversion overhead.

So it quite simply doesn't make any sense to extend sysuptimes to 64 
bits; there's no advantage to be gained at all.

Rather, implimentations should move to the use of absolute 
flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit 
flowStartSysUpTime and flowEndSysUpTime for backwards compatability.


> We would still be backwards compatible with NetFlowv9 (that uses 32 bit
> sysuptimes) but at the same time allow for longer values if required,
> for example, at devices without an absolute clock being set.

A device without an absolute clock is problematic for a different 
reason. Observed traffic could be retained in the device's cache for 
some time before being exported (eg, if the exporter runs once per 
minute), or stuck in an IPC queue, or stuck in the export stack, or 
delayed in the network between the exporter and collector.

So it could be difficult (I hesitate to say "impossible") for the 
collecting device to convert the relative sysuptimes to absolute times 
with any sort of accuracy without knowing the systemInitTimeMilliseconds.

Whereas the use of sysuptime IEs in netflow v9 was always relative to a 
sysuptime and absolute time in the message header, so it was always 
possible to convert the sysuptimes with accuracy.

Since the header sysuptime doesn't exist in IPFIX, and since sending of 
relative times alone seems insufficient (except for the most trivial of 
monitoring), I think we should discourage the sending of the 
flowStartSysUpTime and flowEndSysUpTime IEs without also sending 
systemInitTimeMilliseconds.

Do you know of any such implimentation today?

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Sun Oct 15 11:00:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ7Rm-0004FE-4f; Sun, 15 Oct 2006 10:58:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ7Rk-0004F9-JA
	for ipfix@ietf.org; Sun, 15 Oct 2006 10:58:36 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ7Ri-0004oS-73
	for ipfix@ietf.org; Sun, 15 Oct 2006 10:58:36 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 16:58:35 +0200
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.20060308/8.12.11) with ESMTP id
	k9FEwXkC000370; Sun, 15 Oct 2006 16:58:33 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FEwTmd019866; 
	Sun, 15 Oct 2006 16:58:30 +0200 (MEST)
Received: from [10.61.65.69] (ams3-vpn-dhcp325.cisco.com [10.61.65.69])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA29339;
	Sun, 15 Oct 2006 15:58:28 +0100 (BST)
Message-ID: <45324C91.5090507@cisco.com>
Date: Sun, 15 Oct 2006 15:58:25 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
In-Reply-To: <3698BB5BA217DA9BAB358D82@[61.213.6.135]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=3312; t=1160924313; x=1161788313;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=Vc6LvhIfLcNOsFdBegi2w0dw1Ukqp3KxjgcDiwbkUl9JzAdw6jyfbU+pckfm6Uo9YszLSBSA
	nXufc2/2kOm43k1PHi3icYXFpCY+U5VsFUZkDBkpSLv1IPrgktJEgsTW;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

> What do you think we would loose if we allow sending 64 bit sysuptimes?

I already explained my objection quite clearly, and I didn't hear a good 
counter argument yet.

To reiterate:

The advantage of sending sysuptimes is they're only 32 bits long.

In netflow v9 they reference the sysuptime in the message header. But 
this has been removed from the IPFIX header, so when using IPFIX you 
must also send systemInitTimeMilliseconds (an additional 64 bits).

Sending flowStartSysUpTime, flowEndSysUpTime and 
systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is 
no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 
+ 64 = 128 bits) (or even sending the equivalent Micro or Nano IEs, 
which are also 64 bits each).

In fact, it's more of an overhead due to the convertion of the relative 
sysuptimes to absolute times.

The only saving to be made is if systemInitTimeMilliseconds can be sent 
seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits 
per flow, though still with the conversion overhead.

What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 
192 bits per flow *plus* the additional overhead of conversion, which is 
clearly a lot less efficient than sending flowStartMilliseconds and 
flowEndMilliseconds (64 + 64 = 128 bits, with no conversion required).

Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 
= 128 bits per flow (so equivalent to flowStartMilliseconds and 
flowEndMilliseconds) but still with the conversion overhead.

So it quite simply doesn't make any sense to extend sysuptimes to 64 
bits; there's no advantage to be gained at all.

Rather, implimentations should move to the use of absolute 
flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit 
flowStartSysUpTime and flowEndSysUpTime for backwards compatability.


> We would still be backwards compatible with NetFlowv9 (that uses 32 bit
> sysuptimes) but at the same time allow for longer values if required,
> for example, at devices without an absolute clock being set.

A device without an absolute clock is problematic for a different 
reason. Observed traffic could be retained in the device's cache for 
some time before being exported (eg, if the exporter runs once per 
minute), or stuck in an IPC queue, or stuck in the export stack, or 
delayed in the network between the exporter and collector.

So it could be difficult (I hesitate to say "impossible") for the 
collecting device to convert the relative sysuptimes to absolute times 
with any sort of accuracy without knowing the systemInitTimeMilliseconds.

Whereas the use of sysuptime IEs in netflow v9 was always relative to a 
sysuptime and absolute time in the message header, so it was always 
possible to convert the sysuptimes with accuracy.

Since the header sysuptime doesn't exist in IPFIX, and since sending of 
relative times alone seems insufficient (except for the most trivial of 
monitoring), I think we should discourage the sending of the 
flowStartSysUpTime and flowEndSysUpTime IEs without also sending 
systemInitTimeMilliseconds.

Do you know of any such implimentation today?

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Sun Oct 15 12:37:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ8xn-00081q-B8; Sun, 15 Oct 2006 12:35:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ8xm-00081j-JR
	for ipfix@ietf.org; Sun, 15 Oct 2006 12:35:46 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ8xl-0000aU-62
	for ipfix@ietf.org; Sun, 15 Oct 2006 12:35:46 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 18:35:45 +0200
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.20060308/8.12.11) with ESMTP id
	k9FGZi58006563; Sun, 15 Oct 2006 18:35:44 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FGZimd003648; 
	Sun, 15 Oct 2006 18:35:44 +0200 (MEST)
Received: from [10.61.81.58] (ams3-vpn-dhcp4411.cisco.com [10.61.81.58])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA04316;
	Sun, 15 Oct 2006 17:35:42 +0100 (BST)
Message-ID: <45326340.3080106@cisco.com>
Date: Sun, 15 Oct 2006 17:35:12 +0100
From: Andrew Johnson 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] IPFIX totalLength?
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
	<42C6DB58A53456C327DD88B5@[61.213.6.135]>
In-Reply-To: <42C6DB58A53456C327DD88B5@[61.213.6.135]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2499; t=1160930144; x=1161794144;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andrjohn@cisco.com;
	z=From:Andrew=20Johnson=20
	|Subject:Re=3A=20[IPFIX]=20IPFIX=20totalLength?;
	X=v=3Dcisco.com=3B=20h=3DtMuNWw/b3a5w1UMrtMfJ357aGNs=3D;
	b=IFRvyarBeEndMykAbtrwAB4ON+fhGrnQOKZigsq57wGwuMvBCl9e+4ViTLPYAoxfNUdfPffD
	ngG4dPH8ShirQ0xMiOX/suZP2gnoN4sRFoMOlQ8dlVnUlLu6ghTXkFdo;
Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen Quittek wrote:
> Hi Lutz and Paul,
> 
> --On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:
> 
>>
>>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>>> could not find one.
>>>
>>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>>
>>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>>> "IPtotalLength" IE.
> 
> I agree that we should provide an IE for reporting this information.
> 
> Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
> that can be applied to all IP packets? I have a preference for the generic one,
> because it gives us more options when applying it.

I do not think we want a specific one.  We have a specific totalLengthIPv4 as
that is a field found in the IPv4 header.  This is consistent with having a
specific payloadLengthIPv6 (found in the IPv6 header) and a generic
ipPayloadLength.

I think the meaning of this new IE will be consistent with minimumPacketLength
and maximumPacketLength fields:
  ...  The packet length includes the IP header(s) length and the IP payload
  length.

However, packetLength seems a misleading name and ipTotalLength would be
more appropriate.  With this in mind, perhaps the aforementioned fields
could be renamed to minimumIpTotalLength and maximumIpTotalLength.


> The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
> because the maximum jumbo payload length is 2^32 - 1 and with the additional
> 40 octets from the header we exceed what can be represented by 32 bits.

This seems reasonable.  Note that the above min/max fields have a data type
of unsigned16, which seems woefully short.


>> yes, and to make it complete we need packetTotalLength to
>> be able to count link layer bytes also.

I think this proves the point about packetLength being a misleading name :-)

regards

Andrew


> We have already #312 dataLinkFrameSize in the PSAMP info model.
> I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
> to converge before submitting a new version.  But you can find the
> set of IEs that is under discussion for PSAMP-INFO at the IPFIX
> Info Model Browser at .
> PSAMP-INFO elements have IDs >= 300.
> 
> Thanks,
> 
>    Juergen
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

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



From ipfix-bounces@ietf.org Sun Oct 15 12:37:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZ8xn-00081q-B8; Sun, 15 Oct 2006 12:35:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ8xm-00081j-JR
	for ipfix@ietf.org; Sun, 15 Oct 2006 12:35:46 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ8xl-0000aU-62
	for ipfix@ietf.org; Sun, 15 Oct 2006 12:35:46 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 18:35:45 +0200
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.20060308/8.12.11) with ESMTP id
	k9FGZi58006563; Sun, 15 Oct 2006 18:35:44 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FGZimd003648; 
	Sun, 15 Oct 2006 18:35:44 +0200 (MEST)
Received: from [10.61.81.58] (ams3-vpn-dhcp4411.cisco.com [10.61.81.58])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA04316;
	Sun, 15 Oct 2006 17:35:42 +0100 (BST)
Message-ID: <45326340.3080106@cisco.com>
Date: Sun, 15 Oct 2006 17:35:12 +0100
From: Andrew Johnson 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] IPFIX totalLength?
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
	<42C6DB58A53456C327DD88B5@[61.213.6.135]>
In-Reply-To: <42C6DB58A53456C327DD88B5@[61.213.6.135]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2499; t=1160930144; x=1161794144;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andrjohn@cisco.com;
	z=From:Andrew=20Johnson=20
	|Subject:Re=3A=20[IPFIX]=20IPFIX=20totalLength?;
	X=v=3Dcisco.com=3B=20h=3DtMuNWw/b3a5w1UMrtMfJ357aGNs=3D;
	b=IFRvyarBeEndMykAbtrwAB4ON+fhGrnQOKZigsq57wGwuMvBCl9e+4ViTLPYAoxfNUdfPffD
	ngG4dPH8ShirQ0xMiOX/suZP2gnoN4sRFoMOlQ8dlVnUlLu6ghTXkFdo;
Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen Quittek wrote:
> Hi Lutz and Paul,
> 
> --On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:
> 
>>
>>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>>> could not find one.
>>>
>>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>>
>>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>>> "IPtotalLength" IE.
> 
> I agree that we should provide an IE for reporting this information.
> 
> Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
> that can be applied to all IP packets? I have a preference for the generic one,
> because it gives us more options when applying it.

I do not think we want a specific one.  We have a specific totalLengthIPv4 as
that is a field found in the IPv4 header.  This is consistent with having a
specific payloadLengthIPv6 (found in the IPv6 header) and a generic
ipPayloadLength.

I think the meaning of this new IE will be consistent with minimumPacketLength
and maximumPacketLength fields:
  ...  The packet length includes the IP header(s) length and the IP payload
  length.

However, packetLength seems a misleading name and ipTotalLength would be
more appropriate.  With this in mind, perhaps the aforementioned fields
could be renamed to minimumIpTotalLength and maximumIpTotalLength.


> The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
> because the maximum jumbo payload length is 2^32 - 1 and with the additional
> 40 octets from the header we exceed what can be represented by 32 bits.

This seems reasonable.  Note that the above min/max fields have a data type
of unsigned16, which seems woefully short.


>> yes, and to make it complete we need packetTotalLength to
>> be able to count link layer bytes also.

I think this proves the point about packetLength being a misleading name :-)

regards

Andrew


> We have already #312 dataLinkFrameSize in the PSAMP info model.
> I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
> to converge before submitting a new version.  But you can find the
> set of IEs that is under discussion for PSAMP-INFO at the IPFIX
> Info Model Browser at .
> PSAMP-INFO elements have IDs >= 300.
> 
> Thanks,
> 
>    Juergen
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

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



From ipfix-bounces@ietf.org Sun Oct 15 13:57:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZADG-0001Cz-Bw; Sun, 15 Oct 2006 13:55:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZADE-00018s-Sq
	for ipfix@ietf.org; Sun, 15 Oct 2006 13:55:48 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZADA-0000ZF-OF
	for ipfix@ietf.org; Sun, 15 Oct 2006 13:55:48 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 7DEC31BACA1;
	Sun, 15 Oct 2006 19:55:40 +0200 (CEST)
Date: Sun, 15 Oct 2006 19:55:35 +0200
From: Juergen Quittek 
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Message-ID: <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
In-Reply-To: <45324C91.5090507@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Paul,

--On 15.10.2006 15:58 Uhr +0100 Paul Aitken wrote:

> Juergen,
>
>> What do you think we would loose if we allow sending 64 bit sysuptimes?
>
> I already explained my objection quite clearly, and I didn't hear a good counter argument yet.

Sorry for the misunderstanding.  I was just not asking for a re-iteration
but what we would loose when supporting it.  Even if we give it a
data type of 64 bit, no one would have to use it.

Of course we should not spend effort on supporting a feature that
no one uses. But this is exactly what I want to explore.

If I get you right, you do not see a case where 64 bit sysuptimes
make sense, but if we still define them we don't loose anything
because we can still use reduced 32 bit encoding.

Now, is anyone seeing scenarios where a 64 bit sysuptime would be
desirable?

On the list Brian brought up the issue of simulation.
Irino-san was looking at how to report flows lasting longer than 50 days.
Can't these scenario not be solved by using other IEs?

Thanks,

    Juergen


> To reiterate:
>
> The advantage of sending sysuptimes is they're only 32 bits long.
>
> In netflow v9 they reference the sysuptime in the message header. But this has been removed from the IPFIX header, so when using IPFIX you must also send systemInitTimeMilliseconds (an additional 64 bits).
>
> Sending flowStartSysUpTime, flowEndSysUpTime and systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits) (or even sending the equivalent Micro or
> Nano IEs, which are also 64 bits each).
>
> In fact, it's more of an overhead due to the convertion of the relative sysuptimes to absolute times.
>
> The only saving to be made is if systemInitTimeMilliseconds can be sent seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits per flow, though still with the conversion overhead.
>
> What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 192 bits per flow *plus* the additional overhead of conversion, which is clearly a lot less efficient than sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits,
> with no conversion required).
>
> Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 = 128 bits per flow (so equivalent to flowStartMilliseconds and flowEndMilliseconds) but still with the conversion overhead.
>
> So it quite simply doesn't make any sense to extend sysuptimes to 64 bits; there's no advantage to be gained at all.
>
> Rather, implimentations should move to the use of absolute flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit flowStartSysUpTime and flowEndSysUpTime for backwards compatability.
>
>> We would still be backwards compatible with NetFlowv9 (that uses 32 bit
>> sysuptimes) but at the same time allow for longer values if required,
>> for example, at devices without an absolute clock being set.
>
> A device without an absolute clock is problematic for a different reason. Observed traffic could be retained in the device's cache for some time before being exported (eg, if the exporter runs once per minute), or stuck in an IPC queue, or stuck in the
> export stack, or delayed in the network between the exporter and collector.
>
> So it could be difficult (I hesitate to say "impossible") for the collecting device to convert the relative sysuptimes to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds.
>
> Whereas the use of sysuptime IEs in netflow v9 was always relative to a sysuptime and absolute time in the message header, so it was always possible to convert the sysuptimes with accuracy.
>
> Since the header sysuptime doesn't exist in IPFIX, and since sending of relative times alone seems insufficient (except for the most trivial of monitoring), I think we should discourage the sending of the flowStartSysUpTime and flowEndSysUpTime IEs
> without also sending systemInitTimeMilliseconds.
>
> Do you know of any such implimentation today?
>
> --
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.



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



From ipfix-bounces@ietf.org Sun Oct 15 13:57:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZADG-0001Cz-Bw; Sun, 15 Oct 2006 13:55:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZADE-00018s-Sq
	for ipfix@ietf.org; Sun, 15 Oct 2006 13:55:48 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZADA-0000ZF-OF
	for ipfix@ietf.org; Sun, 15 Oct 2006 13:55:48 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 7DEC31BACA1;
	Sun, 15 Oct 2006 19:55:40 +0200 (CEST)
Date: Sun, 15 Oct 2006 19:55:35 +0200
From: Juergen Quittek 
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Message-ID: <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
In-Reply-To: <45324C91.5090507@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Paul,

--On 15.10.2006 15:58 Uhr +0100 Paul Aitken wrote:

> Juergen,
>
>> What do you think we would loose if we allow sending 64 bit sysuptimes?
>
> I already explained my objection quite clearly, and I didn't hear a good counter argument yet.

Sorry for the misunderstanding.  I was just not asking for a re-iteration
but what we would loose when supporting it.  Even if we give it a
data type of 64 bit, no one would have to use it.

Of course we should not spend effort on supporting a feature that
no one uses. But this is exactly what I want to explore.

If I get you right, you do not see a case where 64 bit sysuptimes
make sense, but if we still define them we don't loose anything
because we can still use reduced 32 bit encoding.

Now, is anyone seeing scenarios where a 64 bit sysuptime would be
desirable?

On the list Brian brought up the issue of simulation.
Irino-san was looking at how to report flows lasting longer than 50 days.
Can't these scenario not be solved by using other IEs?

Thanks,

    Juergen


> To reiterate:
>
> The advantage of sending sysuptimes is they're only 32 bits long.
>
> In netflow v9 they reference the sysuptime in the message header. But this has been removed from the IPFIX header, so when using IPFIX you must also send systemInitTimeMilliseconds (an additional 64 bits).
>
> Sending flowStartSysUpTime, flowEndSysUpTime and systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits) (or even sending the equivalent Micro or
> Nano IEs, which are also 64 bits each).
>
> In fact, it's more of an overhead due to the convertion of the relative sysuptimes to absolute times.
>
> The only saving to be made is if systemInitTimeMilliseconds can be sent seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits per flow, though still with the conversion overhead.
>
> What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 192 bits per flow *plus* the additional overhead of conversion, which is clearly a lot less efficient than sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits,
> with no conversion required).
>
> Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 = 128 bits per flow (so equivalent to flowStartMilliseconds and flowEndMilliseconds) but still with the conversion overhead.
>
> So it quite simply doesn't make any sense to extend sysuptimes to 64 bits; there's no advantage to be gained at all.
>
> Rather, implimentations should move to the use of absolute flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit flowStartSysUpTime and flowEndSysUpTime for backwards compatability.
>
>> We would still be backwards compatible with NetFlowv9 (that uses 32 bit
>> sysuptimes) but at the same time allow for longer values if required,
>> for example, at devices without an absolute clock being set.
>
> A device without an absolute clock is problematic for a different reason. Observed traffic could be retained in the device's cache for some time before being exported (eg, if the exporter runs once per minute), or stuck in an IPC queue, or stuck in the
> export stack, or delayed in the network between the exporter and collector.
>
> So it could be difficult (I hesitate to say "impossible") for the collecting device to convert the relative sysuptimes to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds.
>
> Whereas the use of sysuptime IEs in netflow v9 was always relative to a sysuptime and absolute time in the message header, so it was always possible to convert the sysuptimes with accuracy.
>
> Since the header sysuptime doesn't exist in IPFIX, and since sending of relative times alone seems insufficient (except for the most trivial of monitoring), I think we should discourage the sending of the flowStartSysUpTime and flowEndSysUpTime IEs
> without also sending systemInitTimeMilliseconds.
>
> Do you know of any such implimentation today?
>
> --
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.



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



From ipfix-bounces@ietf.org Sun Oct 15 14:03:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZAKi-0006ok-Jb; Sun, 15 Oct 2006 14:03:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAKh-0006oe-BK
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:03:31 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAKd-0001Zk-8Z
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:03:31 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id AC8E41BAC9E;
	Sun, 15 Oct 2006 20:03:24 +0200 (CEST)
Date: Sun, 15 Oct 2006 20:03:15 +0200
From: Juergen Quittek 
To: Andrew Johnson 
Subject: Re: [IPFIX] IPFIX totalLength?
Message-ID: <2F9D543C18AB0A0F60F00022@[61.213.6.135]>
In-Reply-To: <45326340.3080106@cisco.com>
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
	<42C6DB58A53456C327DD88B5@[61.213.6.135]>
	<45326340.3080106@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Andrew,

--On 15.10.2006 17:35 Uhr +0100 Andrew Johnson wrote:

> Juergen Quittek wrote:
>> Hi Lutz and Paul,
>>
>> --On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:
>>
>>>
>>>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>>>> could not find one.
>>>>
>>>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>>>
>>>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>>>> "IPtotalLength" IE.
>>
>> I agree that we should provide an IE for reporting this information.
>>
>> Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
>> that can be applied to all IP packets? I have a preference for the generic one,
>> because it gives us more options when applying it.
>
> I do not think we want a specific one.  We have a specific totalLengthIPv4 as
> that is a field found in the IPv4 header.  This is consistent with having a
> specific payloadLengthIPv6 (found in the IPv6 header) and a generic
> ipPayloadLength.
>
> I think the meaning of this new IE will be consistent with minimumPacketLength
> and maximumPacketLength fields:
>   ...  The packet length includes the IP header(s) length and the IP payload
>   length.
>
> However, packetLength seems a misleading name and ipTotalLength would be
> more appropriate.  With this in mind, perhaps the aforementioned fields
> could be renamed to minimumIpTotalLength and maximumIpTotalLength.

Fine with me.
Anyone objecting?

>> The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
>> because the maximum jumbo payload length is 2^32 - 1 and with the additional
>> 40 octets from the header we exceed what can be represented by 32 bits.
>
> This seems reasonable.  Note that the above min/max fields have a data type
> of unsigned16, which seems woefully short.

You are right.
Would anyone have a problem with changing the datatypes of min/maximumIpTotalLength
from unsigned16 to unsigned64?

>>> yes, and to make it complete we need packetTotalLength to
>>> be able to count link layer bytes also.
>
> I think this proves the point about packetLength being a misleading name :-)

:-)

Thanks,

    Juergen


> regards
>
> Andrew
>
>
>> We have already #312 dataLinkFrameSize in the PSAMP info model.
>> I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
>> to converge before submitting a new version.  But you can find the
>> set of IEs that is under discussion for PSAMP-INFO at the IPFIX
>> Info Model Browser at .
>> PSAMP-INFO elements have IDs >= 300.
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Sun Oct 15 14:03:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZAKi-0006ok-Jb; Sun, 15 Oct 2006 14:03:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAKh-0006oe-BK
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:03:31 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAKd-0001Zk-8Z
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:03:31 -0400
Received: from [61.213.6.135] (unknown [61.213.6.135])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id AC8E41BAC9E;
	Sun, 15 Oct 2006 20:03:24 +0200 (CEST)
Date: Sun, 15 Oct 2006 20:03:15 +0200
From: Juergen Quittek 
To: Andrew Johnson 
Subject: Re: [IPFIX] IPFIX totalLength?
Message-ID: <2F9D543C18AB0A0F60F00022@[61.213.6.135]>
In-Reply-To: <45326340.3080106@cisco.com>
References: <45210A8D.6010202@cisco.com> <452A6D41.1040707@fokus.fraunhofer.de>
	<42C6DB58A53456C327DD88B5@[61.213.6.135]>
	<45326340.3080106@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Andrew,

--On 15.10.2006 17:35 Uhr +0100 Andrew Johnson wrote:

> Juergen Quittek wrote:
>> Hi Lutz and Paul,
>>
>> --On 09.10.2006 17:39 Uhr +0200 Lutz Mark wrote:
>>
>>>
>>>> I was looking for an IPv6 IE equivalent to #190, totalLengthIPv4 - but I
>>>> could not find one.
>>>>
>>>> Probably all we can do is to calculate #191 payloadLengthIPv6 + 40.
>>>>
>>>> A new IE, "totalLengthIPv6", would be useful - as would a generic
>>>> "IPtotalLength" IE.
>>
>> I agree that we should provide an IE for reporting this information.
>>
>> Shall we use a specific IE for IPv6 or rather use a generic IE totalLengthIP
>> that can be applied to all IP packets? I have a preference for the generic one,
>> because it gives us more options when applying it.
>
> I do not think we want a specific one.  We have a specific totalLengthIPv4 as
> that is a field found in the IPv4 header.  This is consistent with having a
> specific payloadLengthIPv6 (found in the IPv6 header) and a generic
> ipPayloadLength.
>
> I think the meaning of this new IE will be consistent with minimumPacketLength
> and maximumPacketLength fields:
>   ...  The packet length includes the IP header(s) length and the IP payload
>   length.
>
> However, packetLength seems a misleading name and ipTotalLength would be
> more appropriate.  With this in mind, perhaps the aforementioned fields
> could be renamed to minimumIpTotalLength and maximumIpTotalLength.

Fine with me.
Anyone objecting?

>> The data type of either totalLengthIPv6 or totalLengthIP must be unsigned64,
>> because the maximum jumbo payload length is 2^32 - 1 and with the additional
>> 40 octets from the header we exceed what can be represented by 32 bits.
>
> This seems reasonable.  Note that the above min/max fields have a data type
> of unsigned16, which seems woefully short.

You are right.
Would anyone have a problem with changing the datatypes of min/maximumIpTotalLength
from unsigned16 to unsigned64?

>>> yes, and to make it complete we need packetTotalLength to
>>> be able to count link layer bytes also.
>
> I think this proves the point about packetLength being a misleading name :-)

:-)

Thanks,

    Juergen


> regards
>
> Andrew
>
>
>> We have already #312 dataLinkFrameSize in the PSAMP info model.
>> I-D PSAMP-INFO is expired, because we are waiting for IPFIX-INFO
>> to converge before submitting a new version.  But you can find the
>> set of IEs that is under discussion for PSAMP-INFO at the IPFIX
>> Info Model Browser at .
>> PSAMP-INFO elements have IDs >= 300.
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Sun Oct 15 14:20:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZAao-0007ci-OA; Sun, 15 Oct 2006 14:20:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAan-0007cd-JA
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:20:09 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAam-00043b-8m
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:20:09 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 20:20:08 +0200
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.20060308/8.12.11) with ESMTP id
	k9FIK7r2030145; Sun, 15 Oct 2006 20:20:07 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FIK6md019078; 
	Sun, 15 Oct 2006 20:20:06 +0200 (MEST)
Received: from [10.61.81.91] (ams3-vpn-dhcp4444.cisco.com [10.61.81.91])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA09221;
	Sun, 15 Oct 2006 19:20:05 +0100 (BST)
Message-ID: <45327BD3.6090901@cisco.com>
Date: Sun, 15 Oct 2006 19:20:03 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
In-Reply-To: <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1598; t=1160936407; x=1161800407;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=NFWPKcO498107e8WUtn37SSwfRw6lbTA2mN4IIo9ARD1lZ0U4G50M0ARN0HGklkC/vxfVxpJ
	ble4y29k4VLS/ghRmQcLM1ZVQf+Y085ha7jVzzTw37mWOiN/DPuvbYaR;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

> Sorry for the misunderstanding.  I was just not asking for a 
> re-iteration but what we would loose when supporting it.  Even if we 
> give it a data type of 64 bit, no one would have to use it.

If nobody will use it, then we are wasting our time even discussing it.

> Of course we should not spend effort on supporting a feature that no 
> one uses. But this is exactly what I want to explore.

Then who has (or plans) an implimentation that uses sysuptimes which
would not be improved by using flowStartMilliseconds and
flowEndMilliseconds?

> If I get you right, you do not see a case where 64 bit sysuptimes 
> make sense,

Correct. In fact, I showed why they don't ever make sense.

> but if we still define them we don't loose anything because we can 
> still use reduced 32 bit encoding.

Sure. But if you would use the 64-bit encoding, then your implimentation
would be more efficient if you converted it to use flowStartMilliseconds
and flowEndMilliseconds.

> Now, is anyone seeing scenarios where a 64 bit sysuptime would be 
> desirable?
> 
> On the list Brian brought up the issue of simulation. Irino-san was 
> looking at how to report flows lasting longer than 50 days. Can't 
> these scenario not be solved by using other IEs?

I understand these scenarios, and recommend use of flowStartMilliseconds
and flowEndMilliseconds for these situations.

But if someone has a good justification for implimentating 64-bit
sysuptimes, then of course I would like to hear it.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Sun Oct 15 14:20:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZAao-0007ci-OA; Sun, 15 Oct 2006 14:20:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAan-0007cd-JA
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:20:09 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAam-00043b-8m
	for ipfix@ietf.org; Sun, 15 Oct 2006 14:20:09 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 15 Oct 2006 20:20:08 +0200
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.20060308/8.12.11) with ESMTP id
	k9FIK7r2030145; Sun, 15 Oct 2006 20:20:07 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FIK6md019078; 
	Sun, 15 Oct 2006 20:20:06 +0200 (MEST)
Received: from [10.61.81.91] (ams3-vpn-dhcp4444.cisco.com [10.61.81.91])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA09221;
	Sun, 15 Oct 2006 19:20:05 +0100 (BST)
Message-ID: <45327BD3.6090901@cisco.com>
Date: Sun, 15 Oct 2006 19:20:03 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
In-Reply-To: <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1598; t=1160936407; x=1161800407;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=NFWPKcO498107e8WUtn37SSwfRw6lbTA2mN4IIo9ARD1lZ0U4G50M0ARN0HGklkC/vxfVxpJ
	ble4y29k4VLS/ghRmQcLM1ZVQf+Y085ha7jVzzTw37mWOiN/DPuvbYaR;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

> Sorry for the misunderstanding.  I was just not asking for a 
> re-iteration but what we would loose when supporting it.  Even if we 
> give it a data type of 64 bit, no one would have to use it.

If nobody will use it, then we are wasting our time even discussing it.

> Of course we should not spend effort on supporting a feature that no 
> one uses. But this is exactly what I want to explore.

Then who has (or plans) an implimentation that uses sysuptimes which
would not be improved by using flowStartMilliseconds and
flowEndMilliseconds?

> If I get you right, you do not see a case where 64 bit sysuptimes 
> make sense,

Correct. In fact, I showed why they don't ever make sense.

> but if we still define them we don't loose anything because we can 
> still use reduced 32 bit encoding.

Sure. But if you would use the 64-bit encoding, then your implimentation
would be more efficient if you converted it to use flowStartMilliseconds
and flowEndMilliseconds.

> Now, is anyone seeing scenarios where a 64 bit sysuptime would be 
> desirable?
> 
> On the list Brian brought up the issue of simulation. Irino-san was 
> looking at how to report flows lasting longer than 50 days. Can't 
> these scenario not be solved by using other IEs?

I understand these scenarios, and recommend use of flowStartMilliseconds
and flowEndMilliseconds for these situations.

But if someone has a good justification for implimentating 64-bit
sysuptimes, then of course I would like to hear it.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Sun Oct 15 20:46:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZGbG-0000Wj-M3; Sun, 15 Oct 2006 20:45:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGbE-0000Vr-Fv
	for ipfix@ietf.org; Sun, 15 Oct 2006 20:45:00 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGTA-0003sM-La
	for ipfix@ietf.org; Sun, 15 Oct 2006 20:36:42 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aawI028749
	for ; Mon, 16 Oct 2006 09:36:36 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aZ7i001045
	for ; Mon, 16 Oct 2006 09:36:35 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aYU4022564
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aYRX028974
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aXNj027257
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aXPU027254
	for ; Mon, 16 Oct 2006 09:36:33 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aWY2021703
	for ; Mon, 16 Oct 2006 09:36:33 +0900 (JST)
Message-ID: <4532D411.9090006@lab.ntt.co.jp>
Date: Mon, 16 Oct 2006 09:36:33 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: [IPFIX] Question about data types of some IEs
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

I have a question and suggestion about data types of some IEs.

1.
  5.5.12.  tcpHeaderLength
  Abstract Data Type: unsigned16

TCP headers has 4 bit "Data Offset" field which has the number of 32 bit
words in the TCP header. Therefore, I think TCP header max size is 2^4*4
= 64 octets. Therefore I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned16?

2.
  5.6.9.  mplsTopLabelTTL
  Abstract Data Type: unsigned32

According to 2.1. Encoding the Label Stack in RFC3032
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     Exp:    Experimental Use, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned32?

3.
  5.4.30.  ipPayloadLength
  Abstract Data Type: unsigned64

totalLengthIPv4 is 16bit, payloadLengthIPv6 is 32bit for jumbo payload
(rfc2675). I think unsigned32 is sufficient for ipPayloadLength.
Why Does Abstract Data Type of this IE have unsigned64?

4.
   5.7.12.  mplsVpnRouteDistinguisher
   Abstract Data Type: octetArray

According to section 4.2 in rfc4364,
a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by 
a 4-byte IPv4 address.

Is unsigned64 sufficient for this IE?

According to page 7 of rfc4382,
MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
SYNTAX  OCTET STRING(SIZE (0..256))

I think that Abstract Data Type of this IE should be "string", if this 
IE is in conformity to rfc4382.

5.
Can Exporter implementation be chosen which use fixed or variable length 
for IEs that have octetArray or string data type?  Is it correct?
Should Information model draft define which use fixed or variable for 
these IEs?

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories


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



From ipfix-bounces@ietf.org Sun Oct 15 20:46:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZGbG-0000Wj-M3; Sun, 15 Oct 2006 20:45:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGbE-0000Vr-Fv
	for ipfix@ietf.org; Sun, 15 Oct 2006 20:45:00 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGTA-0003sM-La
	for ipfix@ietf.org; Sun, 15 Oct 2006 20:36:42 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aawI028749
	for ; Mon, 16 Oct 2006 09:36:36 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aZ7i001045
	for ; Mon, 16 Oct 2006 09:36:35 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aYU4022564
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aYRX028974
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aXNj027257
	for ; Mon, 16 Oct 2006 09:36:34 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9G0aXPU027254
	for ; Mon, 16 Oct 2006 09:36:33 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9G0aWY2021703
	for ; Mon, 16 Oct 2006 09:36:33 +0900 (JST)
Message-ID: <4532D411.9090006@lab.ntt.co.jp>
Date: Mon, 16 Oct 2006 09:36:33 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: [IPFIX] Question about data types of some IEs
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

I have a question and suggestion about data types of some IEs.

1.
  5.5.12.  tcpHeaderLength
  Abstract Data Type: unsigned16

TCP headers has 4 bit "Data Offset" field which has the number of 32 bit
words in the TCP header. Therefore, I think TCP header max size is 2^4*4
= 64 octets. Therefore I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned16?

2.
  5.6.9.  mplsTopLabelTTL
  Abstract Data Type: unsigned32

According to 2.1. Encoding the Label Stack in RFC3032
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     Exp:    Experimental Use, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

I think that unsigned8 is sufficient for this IE.
Is there any reason that is unsigned32?

3.
  5.4.30.  ipPayloadLength
  Abstract Data Type: unsigned64

totalLengthIPv4 is 16bit, payloadLengthIPv6 is 32bit for jumbo payload
(rfc2675). I think unsigned32 is sufficient for ipPayloadLength.
Why Does Abstract Data Type of this IE have unsigned64?

4.
   5.7.12.  mplsVpnRouteDistinguisher
   Abstract Data Type: octetArray

According to section 4.2 in rfc4364,
a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by 
a 4-byte IPv4 address.

Is unsigned64 sufficient for this IE?

According to page 7 of rfc4382,
MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
SYNTAX  OCTET STRING(SIZE (0..256))

I think that Abstract Data Type of this IE should be "string", if this 
IE is in conformity to rfc4382.

5.
Can Exporter implementation be chosen which use fixed or variable length 
for IEs that have octetArray or string data type?  Is it correct?
Should Information model draft define which use fixed or variable for 
these IEs?

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories


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



From ipfix-bounces@ietf.org Mon Oct 16 06:40:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZPsC-0006rU-GA; Mon, 16 Oct 2006 06:39:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPsA-0006mp-TT
	for ipfix@ietf.org; Mon, 16 Oct 2006 06:39:06 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPs5-0005zK-KZ
	for ipfix@ietf.org; Mon, 16 Oct 2006 06:39:06 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 27FBA11B; Mon, 16 Oct 2006 12:39:00 +0200 (MST)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
	by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
	id 28814-03; Mon, 16 Oct 2006 12:38:57 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 99AC3141; Mon, 16 Oct 2006 12:38:57 +0200 (DFT)
Message-ID: <45336182.2090300@informatik.uni-tuebingen.de>
Date: Mon, 16 Oct 2006 12:40:02 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Benoit Claise 
References: <452FBF6D.9030309@cisco.com>
	<452FD2D9.5030507@informatik.uni-tuebingen.de>
	<45335312.7070501@cisco.com>
In-Reply-To: <45335312.7070501@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35
Cc: ipfix@ietf.org
Subject: [IPFIX] Re: [PSAMP] Metering Process and/or Selection Process
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Hi Benoit,

Yes, solution 3 is a good start. I see the following possible enhancements:

1) In order to avoid confusion, we should not define processes within
processes but find another word for "Selection Process". For example, we
could call it "Packet Selection Function". (If you do not like
"function", you can replace it by something else.)

2) Sampled packets can be either used for PSAMP or IPFIX export. In the
first case, we need a "Packet Reporting Function" to extract the
exported IEs and to generate the report stream. In the second case, we
have a "Flow Metering Function" that generates the flow records.

So the whole picture could look like this:

PSAMP Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Packet   | |   | Exporting |
 Packet--->| |Selection|->|Reporting|---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+

IPFIX Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Flow     | |   | Exporting |
 Packet--->| |Selection|->|Metering |---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+


Regards,
Gerhard


Benoit Claise wrote:
>  Hi Gerhard,
> 
> Do I understand correctly that you favor solution 3 in my email.
> This is also my preferred solution.
> 
> Regards, Benoit.
>> Benoit,
>>
>> In draft-muenz-ipfix-configuration-00, I tried to combine the different
>> aspects of an IPFIX/PSAMP Metering Process:
>>
>>
>> 4.3.  Metering Process
>>
>>    Metering Processes perform the data processing within the IPFIX
>>    Device.  In case that the input of a Metering Process is raw packets
>>    from Observation Points, the data are processed and transformed into
>>    exportable records.  If the input is records received from Collecting
>>    Processes or other Metering Processes, the records are processed and
>>    transformed into a new stream of records.
>>
>>    In principle, packet-based and flow-based metering can be
>>    distinguished.  Various packet-based processing techniques are
>>    specified in [I-D.ietf-psamp-sample-tech], and their configurable
>>    parameters are defined in [I-D.ietf-psamp-mib].  [I-D.ietf-psamp-
>>    framework] divides the packet-based Metering Process into a packet
>>    selection process and a reporting process.  This is mapped on
>>    corresponding structures in the configuration data model.
>>
>>    Flow-based processing techniques are described in [I-D.ietf-ipfix-
>>    architecture] and [I-D.dressler-ipfix-aggregation].  [RFC3917] gives
>>    an overview on the configurable parameters.  [I-D.dressler-ipfix-
>>    aggregation] proposes a description language for flow metering rules
>>    (therein called aggregation rules) that define the Flow Keys as well
>>    as the metered and exported flow attributes.  This rule-based
>>    description of flow metering can also be applied to devices that do
>>    not support multiple metering rules.  For example, if a device
>>    performs flow metering with a single set of Flow Keys only, this can
>>    be mapped to exactly one metering rule.
>>
>>    All in all, the configurable parameters of a Metering Process can be
>>    summarized as follows:
>>
>>    Packet Selection:
>>       Incoming raw packets can be processed in a sequence of filters and
>>       sampling algorithms.  The possible filtering and sampling
>>       parameters are defined in [I-D.ietf-psamp-mib].
>>
>>    Packet Reporting:
>>       If the output of the Metering Process are records with packet-
>>       based monitoring data (or PSAMP data), the packet reporting
>>       parameters define the Information Elements that are present in the
>>       records.
>>
>>    Flow Metering:
>>       Flow-based metering can be described by one or more metering
>>       rules.  Each metering rule defines the Information Elements that
>>       are present in the resulting records.  Two different types of
>>       Information Elements are distinguished: Information Elements that
>>       are used as Flow Keys and Information Elements specifying the
>>       additional information reported for each flow.  The application of
>>       a metering rule can be restricted to incoming data matching given
>>       patterns.  Apart from metering rules, the flow-based data
>>       processing depends on active and inactive flow timeout values that
>>       control the flow expiration.
>>
>>    Next Pointer:
>>       The output of a Metering Process can be passed to Exporting
>>       Processes and/or to other Metering Processes.
>>
>>
>> This allows mapping different realizations of the Metering Processes:
>>
>> PSAMP probe: Packet Selection (optional) + Packet Reporting
>> IPFIX probe: Packet Selecton (optional) + Flow Metering
>> Concentrator: Flow Metering (alone)
>>
>> Note that my considerations were based on the assumption that we combine
>> the former PSAMP Measurement Process and the IPFIX Metering Process into
>> a single process. Of course, there are other possibilities, e.g.
>> defining new types of Processes as you propose.
>>
>> Regards,
>> Gerhard
>>
>>
>> Benoit Claise wrote:
>>   
>>>   Tanja, all,
>>>
>>> I want to start a new email thread, discussing one of the point raised
>>> by Tanja in
>>> http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html
>>>
>>>     2: Section 3.3.1: As far as I know we agreed that we use the same
>>>     metering process definition for IPFIX and PSAMP. So the only
>>>     difference I see between PSAMP and IPFIX processes are the
>>>     Information elements that are reported. So I found section 3.3.1. a
>>>     bit confusing.
>>>
>>> Note: in Dallas, we agreed to replace the "measurement process" by the
>>> "metering process"
>>> While re-reading this section 3.3.1, I agree this is confusing. So we
>>> have to change this text/picture     
>>>
>>>    The figure B indicates the sequence of the processes (selection and 
>>>    exporting) within the PSAMP Device. 
>>>           
>>>                   +----------+      +-----------+ 
>>>         Observed  | Metering |      | Exporting | 
>>>         Packet--->| Process  |----->| Process   |--->Collector 
>>>         Stream    +----------+      +-----------+ 
>>>     
>>>        Figure B: PSAMP Processes 
>>>                           
>>>    The Selection Process, which takes an Observed Packet Stream as its 
>>>    input and produces Packet Reports as its output, is an integral part 
>>>    of the Metering Process, which by its definition produces Flow 
>>>    Records as its output. 
>>>
>>>
>>>
>>> I was wondering how to change this: basically, we've got 2 choices!
>>> Drawing 1:
>>>  
>>>            +------------------+
>>>            | Metering Process |
>>>            | +-----------+    |     +-----------+
>>>  Observed  | | Selection |    |     | Exporting |
>>>  Packet--->| | Process   |--------->| Process   |--->Collector
>>>  Stream    | +-----------+    |     +-----------+
>>>            +------------------+
>>>
>>> This would be consistent with the text in section 3.3.1:
>>>
>>>     The Selection Process, which takes an Observed Packet Stream as its
>>>     input and produces Packet Reports as its output, is an integral part
>>>     of the Metering Process, which by its definition produces Flow
>>>     Records as its output.
>>>
>>> Drawing 2:
>>>
>>>            +-----------+   +----------+    +-----------+
>>>  Observed  | Selection |   | Metering |    | Exporting |
>>>  Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
>>>  Stream    +-----------+   +----------+    +-----------+
>>>  
>>>     Figure B: PSAMP Processes
>>>
>>> This would be consistent with the text in section 3.2.2:
>>>
>>>    Selection Process 
>>>          
>>>    A Selection Process takes the Observed Packet Stream as its input and 
>>>    selects a subset of that stream as its output. 
>>>
>>>
>>>
>>>
>>>
>>> However, we quickly realize that we've an inconsistency in the following
>>> definitions;
>>>
>>>    Selection Process 
>>>          
>>>    A Selection Process takes the Observed Packet Stream as its input and 
>>>    selects a subset of that stream as its output. 
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Selection Process, comprising 
>>>    two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation.
>>>
>>>
>>> One definition says that the selection process doesn't generate the
>>> report stream while another says the reverse.
>>> To solve this issue we've got 2 solutions:
>>>
>>>
>>> Solution 1:
>>> We divide the metering process into a Selection Process (Packet Stream
>>> in, Selected Packets out) and a Reporting Process (Selected Packets In,
>>> Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]:
>>>
>>>       * Report Stream: 
>>>             
>>>            The report stream is the output of a reporting process, 
>>>            comprising two distinguished types of information: packet 
>>>            reports, and report interpretation. 
>>>
>>> As far as I recall, we decided to remove the Reporting Process from
>>> [PSAMP-PROTO]... This rules out solution 1.
>>>
>>> Solution 2:
>>>
>>>            +-----------+   +----------+    +-----------+
>>>  Observed  | Selection |   | Metering |    | Exporting |
>>>  Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
>>>  Stream    +-----------+   +----------+    +-----------+
>>>  
>>>     Figure B: PSAMP Processes
>>>
>>> So it means that PSAMP = IPFIX + an extra Selection Process.
>>> We must update
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
>>>    comprising two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation
>>>
>>>
>>> Solution 3:
>>>
>>>  
>>>            +------------------+
>>>            | Metering Process |
>>>            | +-----------+    |     +-----------+
>>>  Observed  | | Selection |    |     | Exporting |
>>>  Packet--->| | Process   |--------->| Process   |--->Collector
>>>  Stream    | +-----------+    |     +-----------+
>>>            +------------------+
>>>
>>> So the metering process: Packet Stream in, Packet Reports out.
>>> We must update
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
>>>    comprising two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation
>>>
>>>
>>> What's your preferred solution?
>>>
>>> Regards, Benoit.
>>>
>>>
>>>
>>>  
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PSAMP mailing list
>>> PSAMP@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/psamp
>>>     
>> _______________________________________________
>> PSAMP mailing list
>> PSAMP@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/psamp
>>   
> 

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



From ipfix-bounces@ietf.org Mon Oct 16 06:40:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZPsC-0006rU-GA; Mon, 16 Oct 2006 06:39:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPsA-0006mp-TT
	for ipfix@ietf.org; Mon, 16 Oct 2006 06:39:06 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPs5-0005zK-KZ
	for ipfix@ietf.org; Mon, 16 Oct 2006 06:39:06 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 27FBA11B; Mon, 16 Oct 2006 12:39:00 +0200 (MST)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
	by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
	id 28814-03; Mon, 16 Oct 2006 12:38:57 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 99AC3141; Mon, 16 Oct 2006 12:38:57 +0200 (DFT)
Message-ID: <45336182.2090300@informatik.uni-tuebingen.de>
Date: Mon, 16 Oct 2006 12:40:02 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Benoit Claise 
References: <452FBF6D.9030309@cisco.com>
	<452FD2D9.5030507@informatik.uni-tuebingen.de>
	<45335312.7070501@cisco.com>
In-Reply-To: <45335312.7070501@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35
Cc: ipfix@ietf.org
Subject: [IPFIX] Re: [PSAMP] Metering Process and/or Selection Process
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Hi Benoit,

Yes, solution 3 is a good start. I see the following possible enhancements:

1) In order to avoid confusion, we should not define processes within
processes but find another word for "Selection Process". For example, we
could call it "Packet Selection Function". (If you do not like
"function", you can replace it by something else.)

2) Sampled packets can be either used for PSAMP or IPFIX export. In the
first case, we need a "Packet Reporting Function" to extract the
exported IEs and to generate the report stream. In the second case, we
have a "Flow Metering Function" that generates the flow records.

So the whole picture could look like this:

PSAMP Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Packet   | |   | Exporting |
 Packet--->| |Selection|->|Reporting|---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+

IPFIX Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Flow     | |   | Exporting |
 Packet--->| |Selection|->|Metering |---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+


Regards,
Gerhard


Benoit Claise wrote:
>  Hi Gerhard,
> 
> Do I understand correctly that you favor solution 3 in my email.
> This is also my preferred solution.
> 
> Regards, Benoit.
>> Benoit,
>>
>> In draft-muenz-ipfix-configuration-00, I tried to combine the different
>> aspects of an IPFIX/PSAMP Metering Process:
>>
>>
>> 4.3.  Metering Process
>>
>>    Metering Processes perform the data processing within the IPFIX
>>    Device.  In case that the input of a Metering Process is raw packets
>>    from Observation Points, the data are processed and transformed into
>>    exportable records.  If the input is records received from Collecting
>>    Processes or other Metering Processes, the records are processed and
>>    transformed into a new stream of records.
>>
>>    In principle, packet-based and flow-based metering can be
>>    distinguished.  Various packet-based processing techniques are
>>    specified in [I-D.ietf-psamp-sample-tech], and their configurable
>>    parameters are defined in [I-D.ietf-psamp-mib].  [I-D.ietf-psamp-
>>    framework] divides the packet-based Metering Process into a packet
>>    selection process and a reporting process.  This is mapped on
>>    corresponding structures in the configuration data model.
>>
>>    Flow-based processing techniques are described in [I-D.ietf-ipfix-
>>    architecture] and [I-D.dressler-ipfix-aggregation].  [RFC3917] gives
>>    an overview on the configurable parameters.  [I-D.dressler-ipfix-
>>    aggregation] proposes a description language for flow metering rules
>>    (therein called aggregation rules) that define the Flow Keys as well
>>    as the metered and exported flow attributes.  This rule-based
>>    description of flow metering can also be applied to devices that do
>>    not support multiple metering rules.  For example, if a device
>>    performs flow metering with a single set of Flow Keys only, this can
>>    be mapped to exactly one metering rule.
>>
>>    All in all, the configurable parameters of a Metering Process can be
>>    summarized as follows:
>>
>>    Packet Selection:
>>       Incoming raw packets can be processed in a sequence of filters and
>>       sampling algorithms.  The possible filtering and sampling
>>       parameters are defined in [I-D.ietf-psamp-mib].
>>
>>    Packet Reporting:
>>       If the output of the Metering Process are records with packet-
>>       based monitoring data (or PSAMP data), the packet reporting
>>       parameters define the Information Elements that are present in the
>>       records.
>>
>>    Flow Metering:
>>       Flow-based metering can be described by one or more metering
>>       rules.  Each metering rule defines the Information Elements that
>>       are present in the resulting records.  Two different types of
>>       Information Elements are distinguished: Information Elements that
>>       are used as Flow Keys and Information Elements specifying the
>>       additional information reported for each flow.  The application of
>>       a metering rule can be restricted to incoming data matching given
>>       patterns.  Apart from metering rules, the flow-based data
>>       processing depends on active and inactive flow timeout values that
>>       control the flow expiration.
>>
>>    Next Pointer:
>>       The output of a Metering Process can be passed to Exporting
>>       Processes and/or to other Metering Processes.
>>
>>
>> This allows mapping different realizations of the Metering Processes:
>>
>> PSAMP probe: Packet Selection (optional) + Packet Reporting
>> IPFIX probe: Packet Selecton (optional) + Flow Metering
>> Concentrator: Flow Metering (alone)
>>
>> Note that my considerations were based on the assumption that we combine
>> the former PSAMP Measurement Process and the IPFIX Metering Process into
>> a single process. Of course, there are other possibilities, e.g.
>> defining new types of Processes as you propose.
>>
>> Regards,
>> Gerhard
>>
>>
>> Benoit Claise wrote:
>>   
>>>   Tanja, all,
>>>
>>> I want to start a new email thread, discussing one of the point raised
>>> by Tanja in
>>> http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html
>>>
>>>     2: Section 3.3.1: As far as I know we agreed that we use the same
>>>     metering process definition for IPFIX and PSAMP. So the only
>>>     difference I see between PSAMP and IPFIX processes are the
>>>     Information elements that are reported. So I found section 3.3.1. a
>>>     bit confusing.
>>>
>>> Note: in Dallas, we agreed to replace the "measurement process" by the
>>> "metering process"
>>> While re-reading this section 3.3.1, I agree this is confusing. So we
>>> have to change this text/picture     
>>>
>>>    The figure B indicates the sequence of the processes (selection and 
>>>    exporting) within the PSAMP Device. 
>>>           
>>>                   +----------+      +-----------+ 
>>>         Observed  | Metering |      | Exporting | 
>>>         Packet--->| Process  |----->| Process   |--->Collector 
>>>         Stream    +----------+      +-----------+ 
>>>     
>>>        Figure B: PSAMP Processes 
>>>                           
>>>    The Selection Process, which takes an Observed Packet Stream as its 
>>>    input and produces Packet Reports as its output, is an integral part 
>>>    of the Metering Process, which by its definition produces Flow 
>>>    Records as its output. 
>>>
>>>
>>>
>>> I was wondering how to change this: basically, we've got 2 choices!
>>> Drawing 1:
>>>  
>>>            +------------------+
>>>            | Metering Process |
>>>            | +-----------+    |     +-----------+
>>>  Observed  | | Selection |    |     | Exporting |
>>>  Packet--->| | Process   |--------->| Process   |--->Collector
>>>  Stream    | +-----------+    |     +-----------+
>>>            +------------------+
>>>
>>> This would be consistent with the text in section 3.3.1:
>>>
>>>     The Selection Process, which takes an Observed Packet Stream as its
>>>     input and produces Packet Reports as its output, is an integral part
>>>     of the Metering Process, which by its definition produces Flow
>>>     Records as its output.
>>>
>>> Drawing 2:
>>>
>>>            +-----------+   +----------+    +-----------+
>>>  Observed  | Selection |   | Metering |    | Exporting |
>>>  Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
>>>  Stream    +-----------+   +----------+    +-----------+
>>>  
>>>     Figure B: PSAMP Processes
>>>
>>> This would be consistent with the text in section 3.2.2:
>>>
>>>    Selection Process 
>>>          
>>>    A Selection Process takes the Observed Packet Stream as its input and 
>>>    selects a subset of that stream as its output. 
>>>
>>>
>>>
>>>
>>>
>>> However, we quickly realize that we've an inconsistency in the following
>>> definitions;
>>>
>>>    Selection Process 
>>>          
>>>    A Selection Process takes the Observed Packet Stream as its input and 
>>>    selects a subset of that stream as its output. 
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Selection Process, comprising 
>>>    two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation.
>>>
>>>
>>> One definition says that the selection process doesn't generate the
>>> report stream while another says the reverse.
>>> To solve this issue we've got 2 solutions:
>>>
>>>
>>> Solution 1:
>>> We divide the metering process into a Selection Process (Packet Stream
>>> in, Selected Packets out) and a Reporting Process (Selected Packets In,
>>> Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]:
>>>
>>>       * Report Stream: 
>>>             
>>>            The report stream is the output of a reporting process, 
>>>            comprising two distinguished types of information: packet 
>>>            reports, and report interpretation. 
>>>
>>> As far as I recall, we decided to remove the Reporting Process from
>>> [PSAMP-PROTO]... This rules out solution 1.
>>>
>>> Solution 2:
>>>
>>>            +-----------+   +----------+    +-----------+
>>>  Observed  | Selection |   | Metering |    | Exporting |
>>>  Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
>>>  Stream    +-----------+   +----------+    +-----------+
>>>  
>>>     Figure B: PSAMP Processes
>>>
>>> So it means that PSAMP = IPFIX + an extra Selection Process.
>>> We must update
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
>>>    comprising two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation
>>>
>>>
>>> Solution 3:
>>>
>>>  
>>>            +------------------+
>>>            | Metering Process |
>>>            | +-----------+    |     +-----------+
>>>  Observed  | | Selection |    |     | Exporting |
>>>  Packet--->| | Process   |--------->| Process   |--->Collector
>>>  Stream    | +-----------+    |     +-----------+
>>>            +------------------+
>>>
>>> So the metering process: Packet Stream in, Packet Reports out.
>>> We must update
>>>
>>>    Report Stream 
>>>          
>>>    The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
>>>    comprising two distinguished types of information: Packet Reports, and Report 
>>>    Interpretation
>>>
>>>
>>> What's your preferred solution?
>>>
>>> Regards, Benoit.
>>>
>>>
>>>
>>>  
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PSAMP mailing list
>>> PSAMP@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/psamp
>>>     
>> _______________________________________________
>> PSAMP mailing list
>> PSAMP@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/psamp
>>   
> 

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



From ipfix-bounces@ietf.org Mon Oct 16 09:22:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZSPE-0003lH-23; Mon, 16 Oct 2006 09:21:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSPC-0003lC-5a
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:21:22 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSP7-00031t-TH
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:21:22 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9GDL9wS001362 for ; Mon, 16 Oct 2006 09:21:11 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9GDKCD5001311
	for ; Mon, 16 Oct 2006 09:20:12 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9GDKCPh001306;
	Mon, 16 Oct 2006 09:20:12 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-15.remote.cert.org [10.25.4.15])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9GDKCtd029082; Mon, 16 Oct 2006 09:20:12 -0400
In-Reply-To: <45327BD3.6090901@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
	<45327BD3.6090901@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Mon, 16 Oct 2006 09:19:39 -0400
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


On Oct 15, 2006, at 2:20 PM, Paul Aitken wrote:

> Juergen,
>
>> Now, is anyone seeing scenarios where a 64 bit sysuptime would be  
>> desirable?
>> On the list Brian brought up the issue of simulation. Irino-san  
>> was looking at how to report flows lasting longer than 50 days.  
>> Can't these scenario not be solved by using other IEs?
>
> I understand these scenarios, and recommend use of  
> flowStartMilliseconds
> and flowEndMilliseconds for these situations.

This makes sense to me. The only reason I could see now is if the  
calculation of flow{Start,End}Milliseconds was significantly more  
costly that the calculation of flow{Start,End}SysUpTime, but these  
are fairly minor points and I can't provide an example of such an  
machine; so I withdraw my point...

Regards,

Brian




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



From ipfix-bounces@ietf.org Mon Oct 16 09:22:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZSPE-0003lH-23; Mon, 16 Oct 2006 09:21:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSPC-0003lC-5a
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:21:22 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSP7-00031t-TH
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:21:22 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9GDL9wS001362 for ; Mon, 16 Oct 2006 09:21:11 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9GDKCD5001311
	for ; Mon, 16 Oct 2006 09:20:12 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9GDKCPh001306;
	Mon, 16 Oct 2006 09:20:12 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-15.remote.cert.org [10.25.4.15])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9GDKCtd029082; Mon, 16 Oct 2006 09:20:12 -0400
In-Reply-To: <45327BD3.6090901@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>
	<45251A10.9060300@sfc.wide.ad.jp>
	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>
	<45324C91.5090507@cisco.com>
	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>
	<45327BD3.6090901@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Mon, 16 Oct 2006 09:19:39 -0400
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


On Oct 15, 2006, at 2:20 PM, Paul Aitken wrote:

> Juergen,
>
>> Now, is anyone seeing scenarios where a 64 bit sysuptime would be  
>> desirable?
>> On the list Brian brought up the issue of simulation. Irino-san  
>> was looking at how to report flows lasting longer than 50 days.  
>> Can't these scenario not be solved by using other IEs?
>
> I understand these scenarios, and recommend use of  
> flowStartMilliseconds
> and flowEndMilliseconds for these situations.

This makes sense to me. The only reason I could see now is if the  
calculation of flow{Start,End}Milliseconds was significantly more  
costly that the calculation of flow{Start,End}SysUpTime, but these  
are fairly minor points and I can't provide an example of such an  
machine; so I withdraw my point...

Regards,

Brian




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



From ipfix-bounces@ietf.org Mon Oct 16 09:27:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZSUr-00079U-HF; Mon, 16 Oct 2006 09:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSUr-00079P-2o
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:27:13 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSUp-0003uB-PP
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:27:13 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9GDR9T1001719 for ; Mon, 16 Oct 2006 09:27:09 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9GDPgJ7001649
	for ; Mon, 16 Oct 2006 09:25:42 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9GDPgAt001646;
	Mon, 16 Oct 2006 09:25:42 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-15.remote.cert.org [10.25.4.15])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9GDPgkx029736; Mon, 16 Oct 2006 09:25:42 -0400
In-Reply-To: <2742A316245C642E5AE60DB5@[61.213.6.135]>
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
	<2742A316245C642E5AE60DB5@[61.213.6.135]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
Date: Mon, 16 Oct 2006 09:25:09 -0400
To: Juergen Quittek 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: Lutz Mark , ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

Part of this issue would appear to be a specific case of a general  
question - should there be one or two IEs for IPv4/IPv6 header fields  
that are semantically identical and similar in encoding (e.g. DSCP),  
and I thought the direction we were moving in this summer was toward  
_not_ differentiating v4 and v6.

My personal preference would be not to split, and to allow reduced- 
length encoding for fragmentOffset.

Regards,

Brian

On Oct 15, 2006, at 4:00 AM, Juergen Quittek wrote:

> Paul and Lutz,
>
> Here is a brief summary of the situation so far.
>
> We have three IEs related to fragmentation:
>
> #54  fragmentIdentification unsigned32
> #88  fragmentOffset unsigned16
> #197 fragmentFlags unsigned8
>
> Currently, all three can be used for IPv4 as well as for IPv6.
>
> Now, you request to split fragmentIdentification into two IEs,
> one specific for IPv4 and one for specific for IPv6.
>
> The only argument for this that I read so far is saving bandwidth
> if you have to report mixed traffic with IPv4 and IPv6, because
> the pure IPv4 identifier has half the length of the IPv6 identifier.
>
> Still I do not get this argument:
>
>  1. If you have only IPv4 traffic, you can use reduced encoding and
>     waste no bandwidth.
>
>  2. If you report IPv6 traffic only, there is no issue.
>
>  3. If you report mixed traffic, then the current IEs give you two
>     options:
>     a) Either use a single template for reporting IPv4 and IPv6.
>        This implies a waste of 16 bits per IPv4 record
>     b) You use different templates for IPv4 and IPv6 records.
>        Then you would use 16 bit encoding for the IPv4 record
>        and 32 bit encoding for the IPv6 record.
>
> If we split fragmentIdentification into fragmentIdentificationIPv4
> and fragmentIdentificationIPv6, then the only achievement would be
> that 3.a) is not possible anymore.
>
> Is this what you want to achieve or am I somehow mistaken?
> Are there other arguments for the split that I have ignored?
>
> Thanks,
>
>    Juergen
>
>
> --On 09.10.2006 17:21 Uhr +0200 Lutz Mark wrote:
>
>>
>>> I think I would prefer to go back to #54 = IPv4 ID (coming from the
>>> netflow v9 definition) and create a new  
>>> fragmentIdentificationIPv6 IE.
>>
>> I support this. We had this discussion before:
>> http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html
>>
>> I still prefer to use a name that
>> makes it clear that this info is
>> part of the IPv6 extension header.
>>
>> Best regards,
>> Lutz
>>
>>
>>
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Mon Oct 16 09:27:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZSUr-00079U-HF; Mon, 16 Oct 2006 09:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSUr-00079P-2o
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:27:13 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSUp-0003uB-PP
	for ipfix@ietf.org; Mon, 16 Oct 2006 09:27:13 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9GDR9T1001719 for ; Mon, 16 Oct 2006 09:27:09 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9GDPgJ7001649
	for ; Mon, 16 Oct 2006 09:25:42 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9GDPgAt001646;
	Mon, 16 Oct 2006 09:25:42 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-15.remote.cert.org [10.25.4.15])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9GDPgkx029736; Mon, 16 Oct 2006 09:25:42 -0400
In-Reply-To: <2742A316245C642E5AE60DB5@[61.213.6.135]>
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
	<2742A316245C642E5AE60DB5@[61.213.6.135]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
Date: Mon, 16 Oct 2006 09:25:09 -0400
To: Juergen Quittek 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: Lutz Mark , ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Juergen,

Part of this issue would appear to be a specific case of a general  
question - should there be one or two IEs for IPv4/IPv6 header fields  
that are semantically identical and similar in encoding (e.g. DSCP),  
and I thought the direction we were moving in this summer was toward  
_not_ differentiating v4 and v6.

My personal preference would be not to split, and to allow reduced- 
length encoding for fragmentOffset.

Regards,

Brian

On Oct 15, 2006, at 4:00 AM, Juergen Quittek wrote:

> Paul and Lutz,
>
> Here is a brief summary of the situation so far.
>
> We have three IEs related to fragmentation:
>
> #54  fragmentIdentification unsigned32
> #88  fragmentOffset unsigned16
> #197 fragmentFlags unsigned8
>
> Currently, all three can be used for IPv4 as well as for IPv6.
>
> Now, you request to split fragmentIdentification into two IEs,
> one specific for IPv4 and one for specific for IPv6.
>
> The only argument for this that I read so far is saving bandwidth
> if you have to report mixed traffic with IPv4 and IPv6, because
> the pure IPv4 identifier has half the length of the IPv6 identifier.
>
> Still I do not get this argument:
>
>  1. If you have only IPv4 traffic, you can use reduced encoding and
>     waste no bandwidth.
>
>  2. If you report IPv6 traffic only, there is no issue.
>
>  3. If you report mixed traffic, then the current IEs give you two
>     options:
>     a) Either use a single template for reporting IPv4 and IPv6.
>        This implies a waste of 16 bits per IPv4 record
>     b) You use different templates for IPv4 and IPv6 records.
>        Then you would use 16 bit encoding for the IPv4 record
>        and 32 bit encoding for the IPv6 record.
>
> If we split fragmentIdentification into fragmentIdentificationIPv4
> and fragmentIdentificationIPv6, then the only achievement would be
> that 3.a) is not possible anymore.
>
> Is this what you want to achieve or am I somehow mistaken?
> Are there other arguments for the split that I have ignored?
>
> Thanks,
>
>    Juergen
>
>
> --On 09.10.2006 17:21 Uhr +0200 Lutz Mark wrote:
>
>>
>>> I think I would prefer to go back to #54 = IPv4 ID (coming from the
>>> netflow v9 definition) and create a new  
>>> fragmentIdentificationIPv6 IE.
>>
>> I support this. We had this discussion before:
>> http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html
>>
>> I still prefer to use a name that
>> makes it clear that this info is
>> part of the IPv6 extension header.
>>
>> Best regards,
>> Lutz
>>
>>
>>
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Mon Oct 16 12:57:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZVkv-0004it-FW; Mon, 16 Oct 2006 12:56:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVkt-0004ik-UU
	for ipfix@ietf.org; Mon, 16 Oct 2006 12:55:59 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVkr-0007gl-IM
	for ipfix@ietf.org; Mon, 16 Oct 2006 12:55:59 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 16 Oct 2006 18:55:52 +0200
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.20060308/8.12.11) with ESMTP id
	k9GGtoJd023980; Mon, 16 Oct 2006 18:55:50 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GGtnmd020226; 
	Mon, 16 Oct 2006 18:55:50 +0200 (MEST)
Received: from [10.61.81.91] (ams3-vpn-dhcp4444.cisco.com [10.61.81.91])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA11419;
	Mon, 16 Oct 2006 17:55:47 +0100 (BST)
Message-ID: <4533B991.8030400@cisco.com>
Date: Mon, 16 Oct 2006 17:55:45 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
	<2742A316245C642E5AE60DB5@[61.213.6.135]>
	<74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
In-Reply-To: <74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=799; t=1161017750; x=1161881750;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20IPFIX=20fragmentIdentification;
	X=v=3Dcisco.com=3B=20h=3D2waevV8sg0N5qR1ADrkT7ag3wmI=3D;
	b=ODviXxaXlvVrZVBprvq6S+Q+7b/617051MHAwvNLZU5XD+99Otfl7yFPZci8o0oH5VwRTe4N
	9Shog4M57qD7frr/WcUVQELQk0+x/znYiMY9sWxw2eIeSVPjQtPCDG7j;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Lutz Mark , ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

> Part of this issue would appear to be a specific case of a general  
> question - should there be one or two IEs for IPv4/IPv6 header fields  
> that are semantically identical and similar in encoding (e.g. DSCP),  
> and I thought the direction we were moving in this summer was toward  
> _not_ differentiating v4 and v6.
> 
> My personal preference would be not to split, and to allow reduced- 
> length encoding for fragmentOffset.

I agree with you when the fields are similar.

But since these fields come from different headers (IPv4 header versus 
IPv6 option) and are different sizes (16 bits for IPv4 versus 32 bits 
for IPv6) we concluded that they're not the same and so should have 
different IEs.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Mon Oct 16 12:57:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZVkv-0004it-FW; Mon, 16 Oct 2006 12:56:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVkt-0004ik-UU
	for ipfix@ietf.org; Mon, 16 Oct 2006 12:55:59 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVkr-0007gl-IM
	for ipfix@ietf.org; Mon, 16 Oct 2006 12:55:59 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 16 Oct 2006 18:55:52 +0200
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.20060308/8.12.11) with ESMTP id
	k9GGtoJd023980; Mon, 16 Oct 2006 18:55:50 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GGtnmd020226; 
	Mon, 16 Oct 2006 18:55:50 +0200 (MEST)
Received: from [10.61.81.91] (ams3-vpn-dhcp4444.cisco.com [10.61.81.91])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA11419;
	Mon, 16 Oct 2006 17:55:47 +0100 (BST)
Message-ID: <4533B991.8030400@cisco.com>
Date: Mon, 16 Oct 2006 17:55:45 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] IPFIX fragmentIdentification
References: <4520E6E4.80701@cisco.com> <1D65F14886840B1D4488ED01@[10.1.1.104]>
	<4521263E.4020006@cisco.com> <452A68E5.7070203@lehe.de>
	<2742A316245C642E5AE60DB5@[61.213.6.135]>
	<74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
In-Reply-To: <74FF8C4A-6AB9-46BA-A156-EA3C38583ADE@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=799; t=1161017750; x=1161881750;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20IPFIX=20fragmentIdentification;
	X=v=3Dcisco.com=3B=20h=3D2waevV8sg0N5qR1ADrkT7ag3wmI=3D;
	b=ODviXxaXlvVrZVBprvq6S+Q+7b/617051MHAwvNLZU5XD+99Otfl7yFPZci8o0oH5VwRTe4N
	9Shog4M57qD7frr/WcUVQELQk0+x/znYiMY9sWxw2eIeSVPjQtPCDG7j;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Lutz Mark , ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

> Part of this issue would appear to be a specific case of a general  
> question - should there be one or two IEs for IPv4/IPv6 header fields  
> that are semantically identical and similar in encoding (e.g. DSCP),  
> and I thought the direction we were moving in this summer was toward  
> _not_ differentiating v4 and v6.
> 
> My personal preference would be not to split, and to allow reduced- 
> length encoding for fragmentOffset.

I agree with you when the fields are similar.

But since these fields come from different headers (IPv4 header versus 
IPv6 option) and are different sizes (16 bits for IPv4 versus 32 bits 
for IPv6) we concluded that they're not the same and so should have 
different IEs.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Mon Oct 16 14:44:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZXQh-0003pJ-Nu; Mon, 16 Oct 2006 14:43:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXQd-0003hK-MQ
	for ipfix@ietf.org; Mon, 16 Oct 2006 14:43:12 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZXGJ-0006eC-RR
	for ipfix@ietf.org; Mon, 16 Oct 2006 14:32:34 -0400
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
	k9GIWU712367
	for ; Mon, 16 Oct 2006 20:32:31 +0200 (CEST)
Received: from [10.61.82.76] (ams3-vpn-dhcp4685.cisco.com [10.61.82.76])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9GIWSP00323
	for ; Mon, 16 Oct 2006 20:32:28 +0200 (CEST)
Message-ID: <4533D03B.80100@cisco.com>
Date: Mon, 16 Oct 2006 20:32:27 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ipfix@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0516e2ddc924b4e52f6253f239963708
Subject: [IPFIX] IPFIX MIB review
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0777372044=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0777372044==
Content-Type: multipart/alternative;
	boundary="------------040008070307030709090408"

This is a multi-part message in MIME format.
--------------040008070307030709090408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I sent the editorial details directly to Thomas.
Feel free to start a new email thread with one of the point below.

1.  Section 3, IPFIX Documents Overview.

I would insert the second paragraph of section 2 at the end of this 
section., once we have defined the IPFIX document overview.
Otherwise, you defined twice the information.

2. Section 5, terminology
   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. are
   semantically identical with those found in the IPFIX requirements
   document [RFC3917]. 
It might be better to reference [IPFIX-PROTO], which is a normative 
reference anyway.

3.  Section 6.1.1, the Reporting Group
"ipfixCollectorGroupTable contains only indexes " I don't understand 
what it means


4. Section 6.1.2 the Instance Group

   The ipfixTemplateTable lists all data templates that are used by the
   IPFIX exporter.  It has two indices.  The first one is the template
   id and the second one is just a running index for the field ids
   listed in the table.  So the ipfixTemplateEntry.4.x will list all
   field ids used for template id 4 in the order given by x.

   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable."
       INDEX { ipfixTemplateId, ipfixTemplateIndex }
       ::= { ipfixTemplateTable 1 }

Is there no conflict with the new definition of the template Id in 
[IPFIX-PROTO], as the templateId is unique per Transport Session?

      Template ID 
          Each of the newly generated Template Records is given a unique  
          Template ID.  This uniqueness is local to the Transport 
          Session and Observation Domain that generated the Template ID.  
          Template IDs 0-255 are reserved for Template Sets, Options 
          Template Sets, and other reserved Sets yet to be created.  

If a transport session restarts, then...


5.  -- Collector Group Table, ipfixCollectorGroupTable OBJECT-TYPE
I don't see what we gain with this group?
If this group contains several entries, are these multiple exports to 
all the entries.
I think this group only makes sense if we defined the notion of backup 
versus multiple versus load-balancing export in there.

6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
etc... are read-write.
Shall we limit the read-only with the "Units of Conformance"?

7. ipfixInstanceReportingProcessId

   ipfixInstanceReportingProcessId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The process id of the reporting process used by this
            instance."
       ::= { ipfixInstanceEntry 10 }

There is no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not sure what this adds to the MIB.

Note that the editorial changes have been sent directly to Thomas.

8. ipfixInstancePacketsDropped
   ipfixInstancePacketsDropped OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of packets dropped while filtering/sampling
            packets."
       ::= { ipfixInstanceEntry 8 }

This one should be part of the PSAMP MIB, right?

9. There is something missing. As defined in the CISCO NETFLOW MIB

    NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION        "Defines different types of interface configuration."
        SYNTAX  INTEGER{
                interfaceDirNone(0),
                interfaceDirIngress(1),
                interfaceDirEgress(2),
                interfaceDirBoth(3)
        }

    cnfCIInterfaceTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF CnfCIInterfaceEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION        "This table provides Netflow Enable information per interface."
        ::= { cnfCacheInfo  1 }

    cnfCIInterfaceEntry OBJECT-TYPE
        SYNTAX     CnfCIInterfaceEntry
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry ."
        INDEX { ifIndex  }
        ::= { cnfCIInterfaceTable  1}

    CnfCIInterfaceEntry ::= SEQUENCE {
            cnfCINetflowEnable               NfInterfaceDirectionTypes
         }
      

    cnfCINetflowEnable OBJECT-TYPE
        SYNTAX      NfInterfaceDirectionTypes
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION        "Indicates whether the netflow feature is enabled for this
             interface, and if so, in which directions."
        ::= { cnfCIInterfaceEntry  1 }


 
10. Do we want to foresee the version already


  IpfixCollectorEntry ::= SEQUENCE {
           ipfixCollectorIndex             Integer32,
           ipfixCollectorDstIpAddressType  InetAddressType,
           ipfixCollectorDstIpAddress      InetAddress,
           ipfixCollectorDstProtocol       Integer32,
           ipfixCollectorDstPort           Integer32,
           ipfixCollectorReportsSent       Integer32,
           ipfixExportVersion               Integer32    ???????????????????
           ipfixCollectorRowStatus         RowStatus
       }


11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only        
<--------------------------------------------------
       STATUS      current         
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it 
mean? Can only deleted by SNMP? And not created?

12. We would really need some examples of the instance and method chain 
group

13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:

    cnfESExportRate OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "bytes per second"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of Bytes exported per second."
        ::= { cnfExportStatistics  2 }

    cnfESRecordsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of flow statistics  records which were exported."
        ::= { cnfExportStatistics  3 }

    cnfESPktsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of packets (udp datagrams) which were exported."
        ::= { cnfExportStatistics  4 }

    cnfESPktsFailed OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of times a flow record could not be exported because of
             a pak allocation failure."
        ::= { cnfExportStatistics  5 }

    cnfESPktsDropped OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of export packets which were dropped at the time of
             ipwrite operation. The reasons for this failure are no FIB,
             adjacency failure, MTU failed, enqueue failed, IPC failed etc."
        ::= { cnfExportStatistics  6 }


Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus


 14. collectExporterTable  


   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can _configure _on my Collector 
which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, 
simply listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .


15. I think that we are missing the observation domain as an index in 
many tables
Example: as the Template IDs are unique per Observation Domain, 
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable
On the other hand, I don't clearly understand the goal of 
collectObservDomainStatisTable. Should we simply add the O.D.id to the 
collectExporterStatisTable  and combine those stats?

16.
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the 
collectExporterIndex enough? (next to the O.D.id: see point 16)

17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will 
always be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and 
collectTemplateStatisticsTable 

18. collectTemplateStatisticsTable 
Again, why is there a rowStatus in that table?

19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to 
display how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session, 
missing in the index.


Regards, Benoit.







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




  


Dear all,



I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).

I sent the editorial details directly to Thomas.

Feel free to start a new email thread with one of the point below.



1.  Section 3, IPFIX Documents Overview.



I would insert the second paragraph of section 2 at the end of this
section., once we have defined the IPFIX document overview. 

Otherwise, you defined twice the information.



2. Section 5, terminology

   The definitions of the basic terms like IP
Traffic Flow, Exporting

   Process, Collecting Process, Observation
Points, etc. are

   semantically identical with those found in
the IPFIX requirements

   document [RFC3917].  

It might be better to reference [IPFIX-PROTO], which is a normative
reference anyway.



3.  Section 6.1.1, the Reporting Group

"ipfixCollectorGroupTable
contains only indexes " I don't understand what it means





4. Section 6.1.2 the Instance Group



   The ipfixTemplateTable lists all data
templates that are used by the

   IPFIX exporter.  It
has two indices.  The first one is the template

   id and the second one is just a running index
for the field ids

   listed in the table.  So
the ipfixTemplateEntry.4.x will list all

   field ids used for template id 4 in the order
given by x.



   ipfixTemplateEntry OBJECT-TYPE

       SYNTAX      IpfixTemplateEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "Defines an entry in the
ipfixTemplateTable."

       INDEX { ipfixTemplateId,
ipfixTemplateIndex }

       ::= { ipfixTemplateTable 1 }



Is there no conflict with the new definition of the template Id in
[IPFIX-PROTO], as the templateId is unique per Transport Session?


      Template ID 
          Each of the newly generated Template Records is given a unique  
          Template ID.  This uniqueness is local to the Transport 
          Session and Observation Domain that generated the Template ID.  
          Template IDs 0-255 are reserved for Template Sets, Options 
          Template Sets, and other reserved Sets yet to be created.  

If a transport session restarts, then...




5.  -- Collector Group Table,  ipfixCollectorGroupTable OBJECT-TYPE

I
don't see what we gain with this group?

If this group contains several entries, are these multiple exports to
all the entries.

I think this group only makes sense if we defined the notion of backup
versus multiple versus load-balancing export in there.



6.
And again the discussion about read-write versus read-only.

ipfixCollectorTable,
ipfixCollectorGroupTable,
ipfixTemplateTable,
etc... are read-write.

Shall we limit the read-only with the "Units of Conformance"?



7. ipfixInstanceReportingProcessId 



   ipfixInstanceReportingProcessId OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only

       STATUS      current

       DESCRIPTION

           "The process id of the reporting
process used by this

            instance."

       ::= { ipfixInstanceEntry 10 }



There is
no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.

And I'm not sure what this adds to the MIB.



Note that the editorial changes have been sent directly to Thomas.



8. ipfixInstancePacketsDropped 

   ipfixInstancePacketsDropped OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only

       STATUS      current

       DESCRIPTION

           "The number of packets dropped while
filtering/sampling

            packets."

       ::= { ipfixInstanceEntry 8 }



This one should be part of the PSAMP MIB, right?



9. There is something missing. As defined in the CISCO NETFLOW MIB




  
NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION        "Defines different types of interface configuration."
    SYNTAX  INTEGER{
            interfaceDirNone(0),
            interfaceDirIngress(1),
            interfaceDirEgress(2),
            interfaceDirBoth(3)
    }

cnfCIInterfaceTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CnfCIInterfaceEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION        "This table provides Netflow Enable information per interface."
    ::= { cnfCacheInfo 1 }

cnfCIInterfaceEntry OBJECT-TYPE
    SYNTAX     CnfCIInterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry."
    INDEX { ifIndex }
    ::= { cnfCIInterfaceTable 1}

CnfCIInterfaceEntry ::= SEQUENCE {
        cnfCINetflowEnable              NfInterfaceDirectionTypes
     }
  

  
cnfCINetflowEnable OBJECT-TYPE
    SYNTAX      NfInterfaceDirectionTypes
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION        "Indicates whether the netflow feature is enabled for this
         interface, and if so, in which directions."
    ::= { cnfCIInterfaceEntry 1 }






 
10. Do we want to foresee the version already



  IpfixCollectorEntry ::= SEQUENCE {

           ipfixCollectorIndex             Integer32,

           ipfixCollectorDstIpAddressType  InetAddressType,

           ipfixCollectorDstIpAddress      InetAddress,

           ipfixCollectorDstProtocol       Integer32,

           ipfixCollectorDstPort           Integer32,

           ipfixCollectorReportsSent       Integer32,

           ipfixExportVersion               Integer32   
???????????????????

           ipfixCollectorRowStatus         RowStatus

       }




11. only ipfixTemplateRowStatus 
is read-write in this table

 

   IpfixTemplateEntry ::= SEQUENCE {

           ipfixTemplateId         
Integer32,

           ipfixTemplateIndex      
Integer32,

           ipfixTemplateFieldId    
Integer32,

           ipfixTemplateRowStatus  
RowStatus

       }

 

   ipfixTemplateId OBJECT-TYPE

       SYNTAX      Integer32
(1..2147483647)

       MAX-ACCESS  not-accessible       
<--------------------------------------------------

       STATUS      current

       DESCRIPTION

           "The unique identifier for the
template."

       REFERENCE

           "draft-ietf-ipfix-sample-tech-04.txt,
Section 5.1"

   -- Editor Note: get reference right!

       ::= { ipfixTemplateEntry 1 }

 

   ipfixTemplateIndex OBJECT-TYPE

       SYNTAX      Integer32
(1..2147483647)

       MAX-ACCESS  not-accessible       
<--------------------------------------------------

       STATUS      current

       DESCRIPTION

           "The locally arbitrary, but unique
identifier of a field Id

            in the template identified by
ipfixTemplateId.

 

            The value is expected to remain
constant at least from one

            re-initialization of the entity's
network management system

            to the next re-initialization."

       ::= { ipfixTemplateEntry 2 }



  ipfixTemplateFieldId OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only       
<--------------------------------------------------

       STATUS      current         


       DESCRIPTION

           "The Field Id at position
ipfixTemplateIndex in the template

            ipfixTemplateId. This implicitly
gives the data type and

            state values that are exported."

       REFERENCE

           "draft-ietf-ipfix-sample-tech-04.txt,
IPFIX/PSAMP INFO MODEL"

   -- Editor Note: get reference right!

       ::= { ipfixTemplateEntry 3 }

 

   ipfixTemplateRowStatus OBJECT-TYPE

       SYNTAX      RowStatus

       MAX-ACCESS  read-create

       STATUS      current

       DESCRIPTION

           "The status of this row of the table."

       ::= { ipfixTemplateEntry 4 }



Only ipfixTemplateRowStatus  is
read-write in this table. What does it mean? Can only deleted by SNMP?
And not created?



12. We would really need some examples of the instance and method chain
group



13. In ipfixReporting,
I really would like to see some stats.

Coming from the NetFlow MIB:




  
cnfESExportRate OBJECT-TYPE
    SYNTAX     Counter32
    UNITS      "bytes per second"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of Bytes exported per second."
    ::= { cnfExportStatistics 2 }

cnfESRecordsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of flow statistics records which were exported."
    ::= { cnfExportStatistics 3 }

cnfESPktsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of packets (udp datagrams) which were exported."
    ::= { cnfExportStatistics 4 }

cnfESPktsFailed OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of times a flow record could not be exported because of
         a pak allocation failure."
    ::= { cnfExportStatistics 5 }

cnfESPktsDropped OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of export packets which were dropped at the time of
         ipwrite operation. The reasons for this failure are no FIB,
         adjacency failure, MTU failed, enqueue failed, IPC failed etc."
    ::= { cnfExportStatistics 6 }






Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

   collectExporterStatisEntry OBJECT-TYPE

       SYNTAX      CollectExporterStatisEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "Defines an entry in the
collectExporterStatisTable"

       INDEX { collectExporterIndex,

               collectExporterDstPort }

       ::= { collectExporterStatisTable 1 }

 

   CollectExporterStatisEntry ::=

       SEQUENCE {

           collectExporterDstPort          
Integer32,

           collectExporterProcessId        
Integer32,

           collectExporterRcdPackets        Counter32,

           collectExporterRcdBytes         
Counter32,

           collectExporterRcdMessages       Counter32,

           collectExporterDiscardMessages   Counter32,

           collectSessionElapsedTime        Gauge32,

           collectExporterRcdFlows         
Counter32,

           collectExporterRcdTemplates      Counter32,

           collectExporterStatisRowStatus   RowStatus




  






 14. collectExporterTable  



   collectExporterTable  OBJECT-TYPE

       SYNTAX      SEQUENCE
OF

                   CollectExporterEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "This table lists Exporters that
received by collecting

           process. This process manages them."

       ::= {
collectExporter 1 }



  CollectExporterEntry ::=

       SEQUENCE {

           collectExporterIndex            
Integer32,

           collectExporterSrcIpAddrType     InetAddressType,

           collectExporterSrcIpAddr        
InetAddress,

           collectExporterProtocol         
Integer32,

           collectExporterSrcPort          
Integer32,

           collectLifeTimeTemplate         
Integer32,

           collectExporterRowStatus        
RowStatus

       }



What is the goal of that MIB
table.

As this read-write, it means that I can configure on my
Collector which Exporter I'm receiving info from. Is this supposed to
serve as an ACL?

I would not have any problems if that MIB table would be read-only,
simply listing the Exporters the Collector receives info from.

Same question for the
collectObservDomainStatisTable  .





15. I think that we are missing the observation domain as an index in
many tables

Example: as the Template IDs are unique per Observation Domain, ipfixTemplateTable
must contains the O.D.id as an index

Example: ipfixInstanceTable


On the other hand, I don't clearly understand the goal of collectObservDomainStatisTable. Should we simply add the O.D.id to
the collectExporterStatisTable  and combine those stats?



16. 

   collectExporterStatisEntry OBJECT-TYPE

       SYNTAX      CollectExporterStatisEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "Defines an entry in the
collectExporterStatisTable"

       INDEX { collectExporterIndex,

               collectExporterDstPort }



I don't understand why we have two indexes in this table? Isn't the
collectExporterIndex enough? (next to the O.D.id: see point 16)



17.



   collectMeteringProcessId OBJECT-TYPE

       SYNTAX      Integer32(1..2147483647)

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "It uses the Metering Process id in
the received

           IPFIX message. It should be zero, if
IPFIX message don't

           specify Metering Process id."

       ::= { collectObservDomainStatisEntry 2 }



The IPFIX Message doesn't specify the Metering Process id, so it will
always be zero. So I would not even mention it.

And remove it as index in collectObservDomainStatisTable  and collectTemplateStatisticsTable  



18. collectTemplateStatisticsTable  

Again, why is there a rowStatus in that table?



19.





collectTemplateRcdTable  OBJECT-TYPE

       SYNTAX      SEQUENCE
OF

                   CollectTemplateRcdEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "This table lists templates that are
received by the

           collecting process. This process
manages them."

       ::= { collectTemplate 2 }

 

   collectTemplateRcdEntry OBJECT-TYPE

       SYNTAX      CollectTemplateRcdEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "Defines an entry in the
collectTemplateRcdTable"

       INDEX {

           collectExporterIndex,

           collectObservDomainId,

           collectMeteringProcessId,

           collectTemplateRcdId,

           collectTemplateRcdIndex }

       ::= { collectTemplateRcdTable 1 }



   CollectTemplateRcdEntry ::=

       SEQUENCE {

           collectTemplateRcdIndex      
Integer32,

           collectTemplateRcdInfoEltId   Integer32,

           collectTemplateInfoEltLength  Integer32,

           collectTemplateRcdRowStatus   RowStatus

       }



I'm wondering why we have this complex table (5 indexes) simply to
display how the templates decode.

Somehow, I failed to find a business case for this table.

On the top of that, the template id are unique per transport session,
missing in the index.





Regards, Benoit.

















--------------040008070307030709090408--


--===============0777372044==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0777372044==--




From ipfix-bounces@ietf.org Mon Oct 16 14:44:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZXQh-0003pJ-Nu; Mon, 16 Oct 2006 14:43:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXQd-0003hK-MQ
	for ipfix@ietf.org; Mon, 16 Oct 2006 14:43:12 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZXGJ-0006eC-RR
	for ipfix@ietf.org; Mon, 16 Oct 2006 14:32:34 -0400
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
	k9GIWU712367
	for ; Mon, 16 Oct 2006 20:32:31 +0200 (CEST)
Received: from [10.61.82.76] (ams3-vpn-dhcp4685.cisco.com [10.61.82.76])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9GIWSP00323
	for ; Mon, 16 Oct 2006 20:32:28 +0200 (CEST)
Message-ID: <4533D03B.80100@cisco.com>
Date: Mon, 16 Oct 2006 20:32:27 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ipfix@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0516e2ddc924b4e52f6253f239963708
Subject: [IPFIX] IPFIX MIB review
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0777372044=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0777372044==
Content-Type: multipart/alternative;
	boundary="------------040008070307030709090408"

This is a multi-part message in MIME format.
--------------040008070307030709090408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I sent the editorial details directly to Thomas.
Feel free to start a new email thread with one of the point below.

1.  Section 3, IPFIX Documents Overview.

I would insert the second paragraph of section 2 at the end of this 
section., once we have defined the IPFIX document overview.
Otherwise, you defined twice the information.

2. Section 5, terminology
   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. are
   semantically identical with those found in the IPFIX requirements
   document [RFC3917]. 
It might be better to reference [IPFIX-PROTO], which is a normative 
reference anyway.

3.  Section 6.1.1, the Reporting Group
"ipfixCollectorGroupTable contains only indexes " I don't understand 
what it means


4. Section 6.1.2 the Instance Group

   The ipfixTemplateTable lists all data templates that are used by the
   IPFIX exporter.  It has two indices.  The first one is the template
   id and the second one is just a running index for the field ids
   listed in the table.  So the ipfixTemplateEntry.4.x will list all
   field ids used for template id 4 in the order given by x.

   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable."
       INDEX { ipfixTemplateId, ipfixTemplateIndex }
       ::= { ipfixTemplateTable 1 }

Is there no conflict with the new definition of the template Id in 
[IPFIX-PROTO], as the templateId is unique per Transport Session?

      Template ID 
          Each of the newly generated Template Records is given a unique  
          Template ID.  This uniqueness is local to the Transport 
          Session and Observation Domain that generated the Template ID.  
          Template IDs 0-255 are reserved for Template Sets, Options 
          Template Sets, and other reserved Sets yet to be created.  

If a transport session restarts, then...


5.  -- Collector Group Table, ipfixCollectorGroupTable OBJECT-TYPE
I don't see what we gain with this group?
If this group contains several entries, are these multiple exports to 
all the entries.
I think this group only makes sense if we defined the notion of backup 
versus multiple versus load-balancing export in there.

6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
etc... are read-write.
Shall we limit the read-only with the "Units of Conformance"?

7. ipfixInstanceReportingProcessId

   ipfixInstanceReportingProcessId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The process id of the reporting process used by this
            instance."
       ::= { ipfixInstanceEntry 10 }

There is no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not sure what this adds to the MIB.

Note that the editorial changes have been sent directly to Thomas.

8. ipfixInstancePacketsDropped
   ipfixInstancePacketsDropped OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of packets dropped while filtering/sampling
            packets."
       ::= { ipfixInstanceEntry 8 }

This one should be part of the PSAMP MIB, right?

9. There is something missing. As defined in the CISCO NETFLOW MIB

    NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION        "Defines different types of interface configuration."
        SYNTAX  INTEGER{
                interfaceDirNone(0),
                interfaceDirIngress(1),
                interfaceDirEgress(2),
                interfaceDirBoth(3)
        }

    cnfCIInterfaceTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF CnfCIInterfaceEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION        "This table provides Netflow Enable information per interface."
        ::= { cnfCacheInfo  1 }

    cnfCIInterfaceEntry OBJECT-TYPE
        SYNTAX     CnfCIInterfaceEntry
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry ."
        INDEX { ifIndex  }
        ::= { cnfCIInterfaceTable  1}

    CnfCIInterfaceEntry ::= SEQUENCE {
            cnfCINetflowEnable               NfInterfaceDirectionTypes
         }
      

    cnfCINetflowEnable OBJECT-TYPE
        SYNTAX      NfInterfaceDirectionTypes
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION        "Indicates whether the netflow feature is enabled for this
             interface, and if so, in which directions."
        ::= { cnfCIInterfaceEntry  1 }


 
10. Do we want to foresee the version already


  IpfixCollectorEntry ::= SEQUENCE {
           ipfixCollectorIndex             Integer32,
           ipfixCollectorDstIpAddressType  InetAddressType,
           ipfixCollectorDstIpAddress      InetAddress,
           ipfixCollectorDstProtocol       Integer32,
           ipfixCollectorDstPort           Integer32,
           ipfixCollectorReportsSent       Integer32,
           ipfixExportVersion               Integer32    ???????????????????
           ipfixCollectorRowStatus         RowStatus
       }


11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only        
<--------------------------------------------------
       STATUS      current         
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it 
mean? Can only deleted by SNMP? And not created?

12. We would really need some examples of the instance and method chain 
group

13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:

    cnfESExportRate OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "bytes per second"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of Bytes exported per second."
        ::= { cnfExportStatistics  2 }

    cnfESRecordsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of flow statistics  records which were exported."
        ::= { cnfExportStatistics  3 }

    cnfESPktsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of packets (udp datagrams) which were exported."
        ::= { cnfExportStatistics  4 }

    cnfESPktsFailed OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of times a flow record could not be exported because of
             a pak allocation failure."
        ::= { cnfExportStatistics  5 }

    cnfESPktsDropped OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of export packets which were dropped at the time of
             ipwrite operation. The reasons for this failure are no FIB,
             adjacency failure, MTU failed, enqueue failed, IPC failed etc."
        ::= { cnfExportStatistics  6 }


Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus


 14. collectExporterTable  


   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can _configure _on my Collector 
which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, 
simply listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .


15. I think that we are missing the observation domain as an index in 
many tables
Example: as the Template IDs are unique per Observation Domain, 
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable
On the other hand, I don't clearly understand the goal of 
collectObservDomainStatisTable. Should we simply add the O.D.id to the 
collectExporterStatisTable  and combine those stats?

16.
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the 
collectExporterIndex enough? (next to the O.D.id: see point 16)

17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will 
always be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and 
collectTemplateStatisticsTable 

18. collectTemplateStatisticsTable 
Again, why is there a rowStatus in that table?

19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to 
display how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session, 
missing in the index.


Regards, Benoit.







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




  


Dear all,



I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).

I sent the editorial details directly to Thomas.

Feel free to start a new email thread with one of the point below.



1.  Section 3, IPFIX Documents Overview.



I would insert the second paragraph of section 2 at the end of this
section., once we have defined the IPFIX document overview. 

Otherwise, you defined twice the information.



2. Section 5, terminology

   The definitions of the basic terms like IP
Traffic Flow, Exporting

   Process, Collecting Process, Observation
Points, etc. are

   semantically identical with those found in
the IPFIX requirements

   document [RFC3917].  

It might be better to reference [IPFIX-PROTO], which is a normative
reference anyway.



3.  Section 6.1.1, the Reporting Group

"ipfixCollectorGroupTable
contains only indexes " I don't understand what it means





4. Section 6.1.2 the Instance Group



   The ipfixTemplateTable lists all data
templates that are used by the

   IPFIX exporter.  It
has two indices.  The first one is the template

   id and the second one is just a running index
for the field ids

   listed in the table.  So
the ipfixTemplateEntry.4.x will list all

   field ids used for template id 4 in the order
given by x.



   ipfixTemplateEntry OBJECT-TYPE

       SYNTAX      IpfixTemplateEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "Defines an entry in the
ipfixTemplateTable."

       INDEX { ipfixTemplateId,
ipfixTemplateIndex }

       ::= { ipfixTemplateTable 1 }



Is there no conflict with the new definition of the template Id in
[IPFIX-PROTO], as the templateId is unique per Transport Session?


      Template ID 
          Each of the newly generated Template Records is given a unique  
          Template ID.  This uniqueness is local to the Transport 
          Session and Observation Domain that generated the Template ID.  
          Template IDs 0-255 are reserved for Template Sets, Options 
          Template Sets, and other reserved Sets yet to be created.  

If a transport session restarts, then...




5.  -- Collector Group Table,  ipfixCollectorGroupTable OBJECT-TYPE

I
don't see what we gain with this group?

If this group contains several entries, are these multiple exports to
all the entries.

I think this group only makes sense if we defined the notion of backup
versus multiple versus load-balancing export in there.



6.
And again the discussion about read-write versus read-only.

ipfixCollectorTable,
ipfixCollectorGroupTable,
ipfixTemplateTable,
etc... are read-write.

Shall we limit the read-only with the "Units of Conformance"?



7. ipfixInstanceReportingProcessId 



   ipfixInstanceReportingProcessId OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only

       STATUS      current

       DESCRIPTION

           "The process id of the reporting
process used by this

            instance."

       ::= { ipfixInstanceEntry 10 }



There is
no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.

And I'm not sure what this adds to the MIB.



Note that the editorial changes have been sent directly to Thomas.



8. ipfixInstancePacketsDropped 

   ipfixInstancePacketsDropped OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only

       STATUS      current

       DESCRIPTION

           "The number of packets dropped while
filtering/sampling

            packets."

       ::= { ipfixInstanceEntry 8 }



This one should be part of the PSAMP MIB, right?



9. There is something missing. As defined in the CISCO NETFLOW MIB




  
NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION        "Defines different types of interface configuration."
    SYNTAX  INTEGER{
            interfaceDirNone(0),
            interfaceDirIngress(1),
            interfaceDirEgress(2),
            interfaceDirBoth(3)
    }

cnfCIInterfaceTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CnfCIInterfaceEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION        "This table provides Netflow Enable information per interface."
    ::= { cnfCacheInfo 1 }

cnfCIInterfaceEntry OBJECT-TYPE
    SYNTAX     CnfCIInterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry."
    INDEX { ifIndex }
    ::= { cnfCIInterfaceTable 1}

CnfCIInterfaceEntry ::= SEQUENCE {
        cnfCINetflowEnable              NfInterfaceDirectionTypes
     }
  

  
cnfCINetflowEnable OBJECT-TYPE
    SYNTAX      NfInterfaceDirectionTypes
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION        "Indicates whether the netflow feature is enabled for this
         interface, and if so, in which directions."
    ::= { cnfCIInterfaceEntry 1 }






 
10. Do we want to foresee the version already



  IpfixCollectorEntry ::= SEQUENCE {

           ipfixCollectorIndex             Integer32,

           ipfixCollectorDstIpAddressType  InetAddressType,

           ipfixCollectorDstIpAddress      InetAddress,

           ipfixCollectorDstProtocol       Integer32,

           ipfixCollectorDstPort           Integer32,

           ipfixCollectorReportsSent       Integer32,

           ipfixExportVersion               Integer32   
???????????????????

           ipfixCollectorRowStatus         RowStatus

       }




11. only ipfixTemplateRowStatus 
is read-write in this table

 

   IpfixTemplateEntry ::= SEQUENCE {

           ipfixTemplateId         
Integer32,

           ipfixTemplateIndex      
Integer32,

           ipfixTemplateFieldId    
Integer32,

           ipfixTemplateRowStatus  
RowStatus

       }

 

   ipfixTemplateId OBJECT-TYPE

       SYNTAX      Integer32
(1..2147483647)

       MAX-ACCESS  not-accessible       
<--------------------------------------------------

       STATUS      current

       DESCRIPTION

           "The unique identifier for the
template."

       REFERENCE

           "draft-ietf-ipfix-sample-tech-04.txt,
Section 5.1"

   -- Editor Note: get reference right!

       ::= { ipfixTemplateEntry 1 }

 

   ipfixTemplateIndex OBJECT-TYPE

       SYNTAX      Integer32
(1..2147483647)

       MAX-ACCESS  not-accessible       
<--------------------------------------------------

       STATUS      current

       DESCRIPTION

           "The locally arbitrary, but unique
identifier of a field Id

            in the template identified by
ipfixTemplateId.

 

            The value is expected to remain
constant at least from one

            re-initialization of the entity's
network management system

            to the next re-initialization."

       ::= { ipfixTemplateEntry 2 }



  ipfixTemplateFieldId OBJECT-TYPE

       SYNTAX      Integer32

       MAX-ACCESS  read-only       
<--------------------------------------------------

       STATUS      current         


       DESCRIPTION

           "The Field Id at position
ipfixTemplateIndex in the template

            ipfixTemplateId. This implicitly
gives the data type and

            state values that are exported."

       REFERENCE

           "draft-ietf-ipfix-sample-tech-04.txt,
IPFIX/PSAMP INFO MODEL"

   -- Editor Note: get reference right!

       ::= { ipfixTemplateEntry 3 }

 

   ipfixTemplateRowStatus OBJECT-TYPE

       SYNTAX      RowStatus

       MAX-ACCESS  read-create

       STATUS      current

       DESCRIPTION

           "The status of this row of the table."

       ::= { ipfixTemplateEntry 4 }



Only ipfixTemplateRowStatus  is
read-write in this table. What does it mean? Can only deleted by SNMP?
And not created?



12. We would really need some examples of the instance and method chain
group



13. In ipfixReporting,
I really would like to see some stats.

Coming from the NetFlow MIB:




  
cnfESExportRate OBJECT-TYPE
    SYNTAX     Counter32
    UNITS      "bytes per second"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of Bytes exported per second."
    ::= { cnfExportStatistics 2 }

cnfESRecordsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of flow statistics records which were exported."
    ::= { cnfExportStatistics 3 }

cnfESPktsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of packets (udp datagrams) which were exported."
    ::= { cnfExportStatistics 4 }

cnfESPktsFailed OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of times a flow record could not be exported because of
         a pak allocation failure."
    ::= { cnfExportStatistics 5 }

cnfESPktsDropped OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of export packets which were dropped at the time of
         ipwrite operation. The reasons for this failure are no FIB,
         adjacency failure, MTU failed, enqueue failed, IPC failed etc."
    ::= { cnfExportStatistics 6 }






Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

   collectExporterStatisEntry OBJECT-TYPE

       SYNTAX      CollectExporterStatisEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "Defines an entry in the
collectExporterStatisTable"

       INDEX { collectExporterIndex,

               collectExporterDstPort }

       ::= { collectExporterStatisTable 1 }

 

   CollectExporterStatisEntry ::=

       SEQUENCE {

           collectExporterDstPort          
Integer32,

           collectExporterProcessId        
Integer32,

           collectExporterRcdPackets        Counter32,

           collectExporterRcdBytes         
Counter32,

           collectExporterRcdMessages       Counter32,

           collectExporterDiscardMessages   Counter32,

           collectSessionElapsedTime        Gauge32,

           collectExporterRcdFlows         
Counter32,

           collectExporterRcdTemplates      Counter32,

           collectExporterStatisRowStatus   RowStatus




  






 14. collectExporterTable  



   collectExporterTable  OBJECT-TYPE

       SYNTAX      SEQUENCE
OF

                   CollectExporterEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "This table lists Exporters that
received by collecting

           process. This process manages them."

       ::= {
collectExporter 1 }



  CollectExporterEntry ::=

       SEQUENCE {

           collectExporterIndex            
Integer32,

           collectExporterSrcIpAddrType     InetAddressType,

           collectExporterSrcIpAddr        
InetAddress,

           collectExporterProtocol         
Integer32,

           collectExporterSrcPort          
Integer32,

           collectLifeTimeTemplate         
Integer32,

           collectExporterRowStatus        
RowStatus

       }



What is the goal of that MIB
table.

As this read-write, it means that I can configure on my
Collector which Exporter I'm receiving info from. Is this supposed to
serve as an ACL?

I would not have any problems if that MIB table would be read-only,
simply listing the Exporters the Collector receives info from.

Same question for the
collectObservDomainStatisTable  .





15. I think that we are missing the observation domain as an index in
many tables

Example: as the Template IDs are unique per Observation Domain, ipfixTemplateTable
must contains the O.D.id as an index

Example: ipfixInstanceTable


On the other hand, I don't clearly understand the goal of collectObservDomainStatisTable. Should we simply add the O.D.id to
the collectExporterStatisTable  and combine those stats?



16. 

   collectExporterStatisEntry OBJECT-TYPE

       SYNTAX      CollectExporterStatisEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "Defines an entry in the
collectExporterStatisTable"

       INDEX { collectExporterIndex,

               collectExporterDstPort }



I don't understand why we have two indexes in this table? Isn't the
collectExporterIndex enough? (next to the O.D.id: see point 16)



17.



   collectMeteringProcessId OBJECT-TYPE

       SYNTAX      Integer32(1..2147483647)

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "It uses the Metering Process id in
the received

           IPFIX message. It should be zero, if
IPFIX message don't

           specify Metering Process id."

       ::= { collectObservDomainStatisEntry 2 }



The IPFIX Message doesn't specify the Metering Process id, so it will
always be zero. So I would not even mention it.

And remove it as index in collectObservDomainStatisTable  and collectTemplateStatisticsTable  



18. collectTemplateStatisticsTable  

Again, why is there a rowStatus in that table?



19.





collectTemplateRcdTable  OBJECT-TYPE

       SYNTAX      SEQUENCE
OF

                   CollectTemplateRcdEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

          "This table lists templates that are
received by the

           collecting process. This process
manages them."

       ::= { collectTemplate 2 }

 

   collectTemplateRcdEntry OBJECT-TYPE

       SYNTAX      CollectTemplateRcdEntry

       MAX-ACCESS  not-accessible

       STATUS      current

       DESCRIPTION

           "Defines an entry in the
collectTemplateRcdTable"

       INDEX {

           collectExporterIndex,

           collectObservDomainId,

           collectMeteringProcessId,

           collectTemplateRcdId,

           collectTemplateRcdIndex }

       ::= { collectTemplateRcdTable 1 }



   CollectTemplateRcdEntry ::=

       SEQUENCE {

           collectTemplateRcdIndex      
Integer32,

           collectTemplateRcdInfoEltId   Integer32,

           collectTemplateInfoEltLength  Integer32,

           collectTemplateRcdRowStatus   RowStatus

       }



I'm wondering why we have this complex table (5 indexes) simply to
display how the templates decode.

Somehow, I failed to find a business case for this table.

On the top of that, the template id are unique per transport session,
missing in the index.





Regards, Benoit.

















--------------040008070307030709090408--


--===============0777372044==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0777372044==--




From ipfix-bounces@ietf.org Mon Oct 16 21:31:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZdmo-00046C-57; Mon, 16 Oct 2006 21:30:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdmn-000466-CR
	for ipfix@ietf.org; Mon, 16 Oct 2006 21:30:29 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZdmi-0004Lo-3W
	for ipfix@ietf.org; Mon, 16 Oct 2006 21:30:29 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1UEmt011586; 
	Tue, 17 Oct 2006 10:30:14 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U8gS018159; Tue, 17 Oct 2006 10:30:09 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U7Lj005455; 
	Tue, 17 Oct 2006 10:30:07 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U6AQ012625; 
	Tue, 17 Oct 2006 10:30:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U6rn028163; Tue, 17 Oct 2006 10:30:06 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U5rA028158; Tue, 17 Oct 2006 10:30:05 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U5JY000661;
	Tue, 17 Oct 2006 10:30:05 +0900 (JST)
Message-ID: <4534321E.9000300@lab.ntt.co.jp>
Date: Tue, 17 Oct 2006 10:30:06 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
In-Reply-To: <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Paul,

Brian Trammell wrote:
> 
> On Oct 15, 2006, at 2:20 PM, Paul Aitken wrote:
> 
>> Juergen,
>>
>>> Now, is anyone seeing scenarios where a 64 bit sysuptime would be 
>>> desirable?
>>> On the list Brian brought up the issue of simulation. Irino-san was 
>>> looking at how to report flows lasting longer than 50 days. Can't 
>>> these scenario not be solved by using other IEs?
>>
>> I understand these scenarios, and recommend use of flowStartMilliseconds
>> and flowEndMilliseconds for these situations.
> 
> This makes sense to me. The only reason I could see now is if the 
> calculation of flow{Start,End}Milliseconds was significantly more costly 
> that the calculation of flow{Start,End}SysUpTime, but these are fairly 
> minor points and I can't provide an example of such an machine; so I 
> withdraw my point...

I understand use of flowStartMilliseconds and flowEndMilliseconds is 
suitable for the situation that exporter runs longer than 50 days.
So, I will not argue to extend sysuptime to 64 bit.

But, I still have a question. Don't flowStartSysUpTime and 
flowEnsSysUpTime support to represent longer than 50 days since device 
booted?
If they can represent only shorter than 50 days since device booted, 
they are not realistic, because routers which are typical IPFIX 
exporters have to run longer than 50 days.
If systemInitTimeMilliseconds is updated to new absolute timestamp to 
represent longer than 50 days whenever counters of sysUpTime overflow. 
Is it correct? If it is correct, I think that systemInitTimeMilliseconds 
is not initialize timestamp, it is just absolute base time for 
flowStartMilliseconds and flowEndMilliseconds. This behavior is 
different from description of systemInitTimeMilliseconds. I think it is 
better to change the name or description of systemInitTimeMilliseconds, 
or create a new Information Element to represent base time for 
sysuptime, for example sysUpBaseTimeMilliseconds (It is similar to 
Brian's suggestion at 5th Oct).

Regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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



From ipfix-bounces@ietf.org Mon Oct 16 21:31:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZdmo-00046C-57; Mon, 16 Oct 2006 21:30:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdmn-000466-CR
	for ipfix@ietf.org; Mon, 16 Oct 2006 21:30:29 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZdmi-0004Lo-3W
	for ipfix@ietf.org; Mon, 16 Oct 2006 21:30:29 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1UEmt011586; 
	Tue, 17 Oct 2006 10:30:14 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U8gS018159; Tue, 17 Oct 2006 10:30:09 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U7Lj005455; 
	Tue, 17 Oct 2006 10:30:07 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U6AQ012625; 
	Tue, 17 Oct 2006 10:30:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U6rn028163; Tue, 17 Oct 2006 10:30:06 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9H1U5rA028158; Tue, 17 Oct 2006 10:30:05 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9H1U5JY000661;
	Tue, 17 Oct 2006 10:30:05 +0900 (JST)
Message-ID: <4534321E.9000300@lab.ntt.co.jp>
Date: Tue, 17 Oct 2006 10:30:06 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
In-Reply-To: <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Paul,

Brian Trammell wrote:
> 
> On Oct 15, 2006, at 2:20 PM, Paul Aitken wrote:
> 
>> Juergen,
>>
>>> Now, is anyone seeing scenarios where a 64 bit sysuptime would be 
>>> desirable?
>>> On the list Brian brought up the issue of simulation. Irino-san was 
>>> looking at how to report flows lasting longer than 50 days. Can't 
>>> these scenario not be solved by using other IEs?
>>
>> I understand these scenarios, and recommend use of flowStartMilliseconds
>> and flowEndMilliseconds for these situations.
> 
> This makes sense to me. The only reason I could see now is if the 
> calculation of flow{Start,End}Milliseconds was significantly more costly 
> that the calculation of flow{Start,End}SysUpTime, but these are fairly 
> minor points and I can't provide an example of such an machine; so I 
> withdraw my point...

I understand use of flowStartMilliseconds and flowEndMilliseconds is 
suitable for the situation that exporter runs longer than 50 days.
So, I will not argue to extend sysuptime to 64 bit.

But, I still have a question. Don't flowStartSysUpTime and 
flowEnsSysUpTime support to represent longer than 50 days since device 
booted?
If they can represent only shorter than 50 days since device booted, 
they are not realistic, because routers which are typical IPFIX 
exporters have to run longer than 50 days.
If systemInitTimeMilliseconds is updated to new absolute timestamp to 
represent longer than 50 days whenever counters of sysUpTime overflow. 
Is it correct? If it is correct, I think that systemInitTimeMilliseconds 
is not initialize timestamp, it is just absolute base time for 
flowStartMilliseconds and flowEndMilliseconds. This behavior is 
different from description of systemInitTimeMilliseconds. I think it is 
better to change the name or description of systemInitTimeMilliseconds, 
or create a new Information Element to represent base time for 
sysuptime, for example sysUpBaseTimeMilliseconds (It is similar to 
Brian's suggestion at 5th Oct).

Regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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



From ipfix-bounces@ietf.org Tue Oct 17 01:32:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZhXQ-0006Hq-Dp; Tue, 17 Oct 2006 01:30:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhXP-0006G7-Qh
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:30:51 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhXL-000534-AA
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:30:51 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5URCZ025327;
	Tue, 17 Oct 2006 14:30:32 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:30:47 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017142241.773D.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

This thread is listed up No.6 comment "read-wite versus read-only".

> 6. And again the discussion about read-write versus read-only.
> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
> etc... are read-write.
> Shall we limit the read-only with the "Units of Conformance"?

It is OK that whole Collector-MIB module is "read-only", It is simply receiving
exporting data as you mention. But, I hope that the configurable parameters
of Exporter-MIB are "read-write" at least.
I wonder that the flow configurable parameters are "read-only", 
whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 01:32:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZhXQ-0006Hq-Dp; Tue, 17 Oct 2006 01:30:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhXP-0006G7-Qh
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:30:51 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhXL-000534-AA
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:30:51 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5URCZ025327;
	Tue, 17 Oct 2006 14:30:32 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:30:47 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017142241.773D.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

This thread is listed up No.6 comment "read-wite versus read-only".

> 6. And again the discussion about read-write versus read-only.
> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
> etc... are read-write.
> Shall we limit the read-only with the "Units of Conformance"?

It is OK that whole Collector-MIB module is "read-only", It is simply receiving
exporting data as you mention. But, I hope that the configurable parameters
of Exporter-MIB are "read-write" at least.
I wonder that the flow configurable parameters are "read-only", 
whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 01:38:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZheq-0003NG-BQ; Tue, 17 Oct 2006 01:38:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhep-0003NA-Ck
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:38:31 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhen-0006CE-QB
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:38:31 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5cRrH025389;
	Tue, 17 Oct 2006 14:38:27 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:38:42 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (RowStatus)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017143347.7740.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

This thread is listed up No.11 comment "Row status".

I simply imaged that the row of table is deleted or created by SNMP.
You mean that RowStatus in statistics table should be removed?
As statistic table shows only performance data that is not configurable
parameter, I think that Rowstatus is certainly needless.

> 11. only ipfixTemplateRowStatus  is read-write in this table
>  
>    IpfixTemplateEntry ::= SEQUENCE {
>            ipfixTemplateId          Integer32,
>            ipfixTemplateIndex       Integer32,
>            ipfixTemplateFieldId     Integer32,
>            ipfixTemplateRowStatus   RowStatus
>        }
>  
>    ipfixTemplateId OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible        
> <--------------------------------------------------
>        STATUS      current
>        DESCRIPTION
>            "The unique identifier for the template."
>        REFERENCE
>            "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
>    -- Editor Note: get reference right!
>        ::= { ipfixTemplateEntry 1 }
>  
>    ipfixTemplateIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible        
> <--------------------------------------------------
>        STATUS      current
>        DESCRIPTION
>            "The locally arbitrary, but unique identifier of a field Id
>             in the template identified by ipfixTemplateId.
>  
>             The value is expected to remain constant at least from one
>             re-initialization of the entity's network management system
>             to the next re-initialization."
>        ::= { ipfixTemplateEntry 2 }
> 
>   ipfixTemplateFieldId OBJECT-TYPE
>        SYNTAX      Integer32
>        MAX-ACCESS  read-only        
> <--------------------------------------------------
>        STATUS      current         
>        DESCRIPTION
>            "The Field Id at position ipfixTemplateIndex in the template
>             ipfixTemplateId. This implicitly gives the data type and
>             state values that are exported."
>        REFERENCE
>            "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
>    -- Editor Note: get reference right!
>        ::= { ipfixTemplateEntry 3 }
>  
>    ipfixTemplateRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The status of this row of the table."
>        ::= { ipfixTemplateEntry 4 }
> 
> Only ipfixTemplateRowStatus  is read-write in this table. What does it 
> mean? Can only deleted by SNMP? And not created?
> 

> 
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 01:38:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZheq-0003NG-BQ; Tue, 17 Oct 2006 01:38:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhep-0003NA-Ck
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:38:31 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhen-0006CE-QB
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:38:31 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5cRrH025389;
	Tue, 17 Oct 2006 14:38:27 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:38:42 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (RowStatus)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017143347.7740.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

This thread is listed up No.11 comment "Row status".

I simply imaged that the row of table is deleted or created by SNMP.
You mean that RowStatus in statistics table should be removed?
As statistic table shows only performance data that is not configurable
parameter, I think that Rowstatus is certainly needless.

> 11. only ipfixTemplateRowStatus  is read-write in this table
>  
>    IpfixTemplateEntry ::= SEQUENCE {
>            ipfixTemplateId          Integer32,
>            ipfixTemplateIndex       Integer32,
>            ipfixTemplateFieldId     Integer32,
>            ipfixTemplateRowStatus   RowStatus
>        }
>  
>    ipfixTemplateId OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible        
> <--------------------------------------------------
>        STATUS      current
>        DESCRIPTION
>            "The unique identifier for the template."
>        REFERENCE
>            "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
>    -- Editor Note: get reference right!
>        ::= { ipfixTemplateEntry 1 }
>  
>    ipfixTemplateIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible        
> <--------------------------------------------------
>        STATUS      current
>        DESCRIPTION
>            "The locally arbitrary, but unique identifier of a field Id
>             in the template identified by ipfixTemplateId.
>  
>             The value is expected to remain constant at least from one
>             re-initialization of the entity's network management system
>             to the next re-initialization."
>        ::= { ipfixTemplateEntry 2 }
> 
>   ipfixTemplateFieldId OBJECT-TYPE
>        SYNTAX      Integer32
>        MAX-ACCESS  read-only        
> <--------------------------------------------------
>        STATUS      current         
>        DESCRIPTION
>            "The Field Id at position ipfixTemplateIndex in the template
>             ipfixTemplateId. This implicitly gives the data type and
>             state values that are exported."
>        REFERENCE
>            "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
>    -- Editor Note: get reference right!
>        ::= { ipfixTemplateEntry 3 }
>  
>    ipfixTemplateRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The status of this row of the table."
>        ::= { ipfixTemplateEntry 4 }
> 
> Only ipfixTemplateRowStatus  is read-write in this table. What does it 
> mean? Can only deleted by SNMP? And not created?
> 

> 
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 01:49:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZhpZ-000226-Bv; Tue, 17 Oct 2006 01:49:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhpY-00021z-N4
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:49:36 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhpW-0007PZ-J7
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:49:36 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5nWpG025474;
	Tue, 17 Oct 2006 14:49:33 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:49:47 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017143912.7743.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

I answer some of comments about COLLECTOR-MIB in inline.
They are 13, 14, 15, 16, 17, 18, and 19.

snip.

> 13. In ipfixReporting, I really would like to see some stats.
> Coming from the NetFlow MIB:
> 
>     cnfESExportRate OBJECT-TYPE
>         SYNTAX     Counter32
>         UNITS      "bytes per second"
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of Bytes exported per second."
>         ::= { cnfExportStatistics  2 }
> 
>     cnfESRecordsExported OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of flow statistics  records which were exported."
>         ::= { cnfExportStatistics  3 }
> 
>     cnfESPktsExported OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of packets (udp datagrams) which were exported."
>         ::= { cnfExportStatistics  4 }
> 
>     cnfESPktsFailed OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of times a flow record could not be exported because of
>              a pak allocation failure."
>         ::= { cnfExportStatistics  5 }
> 
>     cnfESPktsDropped OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of export packets which were dropped at the time of
>              ipwrite operation. The reasons for this failure are no FIB,
>              adjacency failure, MTU failed, enqueue failed, IPC failed etc."
>         ::= { cnfExportStatistics  6 }
> 
> 
> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
> 

I almost agree your comment. But, I have been considering three statistics tables
as follows. 
The Exporter statistics table will be changed session statstics table  in
consideration of backup multiple session between a Exporter and a Collector. 
Do you mean that SessionStatsTable should be aligned with Exporter-MIB?

(*) means index in this table.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
   ipfixSessionDiscardMessages
   ipfixSessionFlows
   ipfixSessionTemplates
   ipfixSessionElapsedTime
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

>    collectExporterStatisEntry OBJECT-TYPE
>        SYNTAX      CollectExporterStatisEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "Defines an entry in the collectExporterStatisTable"
>        INDEX { collectExporterIndex,
>                collectExporterDstPort }
>        ::= { collectExporterStatisTable 1 }
>  
>    CollectExporterStatisEntry ::=
>        SEQUENCE {
>            collectExporterDstPort           Integer32,
>            collectExporterProcessId         Integer32,
>            collectExporterRcdPackets        Counter32,
>            collectExporterRcdBytes          Counter32,
>            collectExporterRcdMessages       Counter32,
>            collectExporterDiscardMessages   Counter32,
>            collectSessionElapsedTime        Gauge32,
>            collectExporterRcdFlows          Counter32,
>            collectExporterRcdTemplates      Counter32,
>            collectExporterStatisRowStatus   RowStatus
> 
> 
>  14. collectExporterTable  
> 
> 
>    collectExporterTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    CollectExporterEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists Exporters that received by collecting
>            process. This process manages them."
>        ::= { collectExporter 1 }
> 
>   CollectExporterEntry ::=
>        SEQUENCE {
>            collectExporterIndex             Integer32,
>            collectExporterSrcIpAddrType     InetAddressType,
>            collectExporterSrcIpAddr         InetAddress,
>            collectExporterProtocol          Integer32,
>            collectExporterSrcPort           Integer32,
>            collectLifeTimeTemplate          Integer32,
>            collectExporterRowStatus         RowStatus
>        }
> 
> What is the goal of that MIB table.
> As this read-write, it means that I can _configure _on my Collector 
> which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
> I would not have any problems if that MIB table would be read-only, 
> simply listing the Exporters the Collector receives info from.
> Same question for the collectObservDomainStatisTable  .
> 
> 
OK, I will change "read-only" objects in collectExporterTable and
collectObservDomainStatisTable.

> 15. I think that we are missing the observation domain as an index in 
> many tables
> Example: as the Template IDs are unique per Observation Domain, 
> ipfixTemplateTable must contains the O.D.id as an index
> Example: ipfixInstanceTable
> On the other hand, I don't clearly understand the goal of 
> collectObservDomainStatisTable. Should we simply add the O.D.id to the 
> collectExporterStatisTable  and combine those stats?

I will propose  collectObservDomainStatisTable as follows.
I think that it has three index in consideration of multiple ODID
exporting to the same session.

(*) means index in this table.

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 
> 16.
>    collectExporterStatisEntry OBJECT-TYPE
>        SYNTAX      CollectExporterStatisEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "Defines an entry in the collectExporterStatisTable"
>        INDEX { collectExporterIndex,
>                collectExporterDstPort }
> 
> I don't understand why we have two indexes in this table? Isn't the 
> collectExporterIndex enough? (next to the O.D.id: see point 16)

I think that collectExporterIndex is enough after ODID discussion  in
mailing list. 
But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
Is this table necessary?

> 17.
> 
>    collectMeteringProcessId OBJECT-TYPE
>        SYNTAX      Integer32(1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "It uses the Metering Process id in the received
>            IPFIX message. It should be zero, if IPFIX message don't
>            specify Metering Process id."
>        ::= { collectObservDomainStatisEntry 2 }
> 
> The IPFIX Message doesn't specify the Metering Process id, so it will 
> always be zero. So I would not even mention it.
> And remove it as index in collectObservDomainStatisTable  and 
> collectTemplateStatisticsTable 
> 

I will remove this object in these table.

> 18. collectTemplateStatisticsTable 
> Again, why is there a rowStatus in that table?
> 
I will remove this object in these table.

> 19.
> 
> 
> collectTemplateRcdTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    CollectTemplateRcdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "This table lists templates that are received by the
>            collecting process. This process manages them."
>        ::= { collectTemplate 2 }
>  
>    collectTemplateRcdEntry OBJECT-TYPE
>        SYNTAX      CollectTemplateRcdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the collectTemplateRcdTable"
>        INDEX {
>            collectExporterIndex,
>            collectObservDomainId,
>            collectMeteringProcessId,
>            collectTemplateRcdId,
>            collectTemplateRcdIndex }
>        ::= { collectTemplateRcdTable 1 }
> 
>    CollectTemplateRcdEntry ::=
>        SEQUENCE {
>            collectTemplateRcdIndex       Integer32,
>            collectTemplateRcdInfoEltId   Integer32,
>            collectTemplateInfoEltLength  Integer32,
>            collectTemplateRcdRowStatus   RowStatus
>        }
> 
> I'm wondering why we have this complex table (5 indexes) simply to 
> display how the templates decode.
> Somehow, I failed to find a business case for this table.
> On the top of that, the template id are unique per transport session, 
> missing in the index.

I will propose following table. 

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength

> 
> Regards, Benoit.
> 
> 
> 
> 
> 
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 01:49:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZhpZ-000226-Bv; Tue, 17 Oct 2006 01:49:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhpY-00021z-N4
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:49:36 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhpW-0007PZ-J7
	for ipfix@ietf.org; Tue, 17 Oct 2006 01:49:36 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H5nWpG025474;
	Tue, 17 Oct 2006 14:49:33 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 14:49:47 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
In-Reply-To: <4533D03B.80100@cisco.com>
References: <4533D03B.80100@cisco.com>
Message-Id: <20061017143912.7743.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

I answer some of comments about COLLECTOR-MIB in inline.
They are 13, 14, 15, 16, 17, 18, and 19.

snip.

> 13. In ipfixReporting, I really would like to see some stats.
> Coming from the NetFlow MIB:
> 
>     cnfESExportRate OBJECT-TYPE
>         SYNTAX     Counter32
>         UNITS      "bytes per second"
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of Bytes exported per second."
>         ::= { cnfExportStatistics  2 }
> 
>     cnfESRecordsExported OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of flow statistics  records which were exported."
>         ::= { cnfExportStatistics  3 }
> 
>     cnfESPktsExported OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of packets (udp datagrams) which were exported."
>         ::= { cnfExportStatistics  4 }
> 
>     cnfESPktsFailed OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of times a flow record could not be exported because of
>              a pak allocation failure."
>         ::= { cnfExportStatistics  5 }
> 
>     cnfESPktsDropped OBJECT-TYPE
>         SYNTAX     Counter32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION        "Number of export packets which were dropped at the time of
>              ipwrite operation. The reasons for this failure are no FIB,
>              adjacency failure, MTU failed, enqueue failed, IPC failed etc."
>         ::= { cnfExportStatistics  6 }
> 
> 
> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
> 

I almost agree your comment. But, I have been considering three statistics tables
as follows. 
The Exporter statistics table will be changed session statstics table  in
consideration of backup multiple session between a Exporter and a Collector. 
Do you mean that SessionStatsTable should be aligned with Exporter-MIB?

(*) means index in this table.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
   ipfixSessionDiscardMessages
   ipfixSessionFlows
   ipfixSessionTemplates
   ipfixSessionElapsedTime
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

>    collectExporterStatisEntry OBJECT-TYPE
>        SYNTAX      CollectExporterStatisEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "Defines an entry in the collectExporterStatisTable"
>        INDEX { collectExporterIndex,
>                collectExporterDstPort }
>        ::= { collectExporterStatisTable 1 }
>  
>    CollectExporterStatisEntry ::=
>        SEQUENCE {
>            collectExporterDstPort           Integer32,
>            collectExporterProcessId         Integer32,
>            collectExporterRcdPackets        Counter32,
>            collectExporterRcdBytes          Counter32,
>            collectExporterRcdMessages       Counter32,
>            collectExporterDiscardMessages   Counter32,
>            collectSessionElapsedTime        Gauge32,
>            collectExporterRcdFlows          Counter32,
>            collectExporterRcdTemplates      Counter32,
>            collectExporterStatisRowStatus   RowStatus
> 
> 
>  14. collectExporterTable  
> 
> 
>    collectExporterTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    CollectExporterEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists Exporters that received by collecting
>            process. This process manages them."
>        ::= { collectExporter 1 }
> 
>   CollectExporterEntry ::=
>        SEQUENCE {
>            collectExporterIndex             Integer32,
>            collectExporterSrcIpAddrType     InetAddressType,
>            collectExporterSrcIpAddr         InetAddress,
>            collectExporterProtocol          Integer32,
>            collectExporterSrcPort           Integer32,
>            collectLifeTimeTemplate          Integer32,
>            collectExporterRowStatus         RowStatus
>        }
> 
> What is the goal of that MIB table.
> As this read-write, it means that I can _configure _on my Collector 
> which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
> I would not have any problems if that MIB table would be read-only, 
> simply listing the Exporters the Collector receives info from.
> Same question for the collectObservDomainStatisTable  .
> 
> 
OK, I will change "read-only" objects in collectExporterTable and
collectObservDomainStatisTable.

> 15. I think that we are missing the observation domain as an index in 
> many tables
> Example: as the Template IDs are unique per Observation Domain, 
> ipfixTemplateTable must contains the O.D.id as an index
> Example: ipfixInstanceTable
> On the other hand, I don't clearly understand the goal of 
> collectObservDomainStatisTable. Should we simply add the O.D.id to the 
> collectExporterStatisTable  and combine those stats?

I will propose  collectObservDomainStatisTable as follows.
I think that it has three index in consideration of multiple ODID
exporting to the same session.

(*) means index in this table.

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 
> 16.
>    collectExporterStatisEntry OBJECT-TYPE
>        SYNTAX      CollectExporterStatisEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "Defines an entry in the collectExporterStatisTable"
>        INDEX { collectExporterIndex,
>                collectExporterDstPort }
> 
> I don't understand why we have two indexes in this table? Isn't the 
> collectExporterIndex enough? (next to the O.D.id: see point 16)

I think that collectExporterIndex is enough after ODID discussion  in
mailing list. 
But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
Is this table necessary?

> 17.
> 
>    collectMeteringProcessId OBJECT-TYPE
>        SYNTAX      Integer32(1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "It uses the Metering Process id in the received
>            IPFIX message. It should be zero, if IPFIX message don't
>            specify Metering Process id."
>        ::= { collectObservDomainStatisEntry 2 }
> 
> The IPFIX Message doesn't specify the Metering Process id, so it will 
> always be zero. So I would not even mention it.
> And remove it as index in collectObservDomainStatisTable  and 
> collectTemplateStatisticsTable 
> 

I will remove this object in these table.

> 18. collectTemplateStatisticsTable 
> Again, why is there a rowStatus in that table?
> 
I will remove this object in these table.

> 19.
> 
> 
> collectTemplateRcdTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    CollectTemplateRcdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "This table lists templates that are received by the
>            collecting process. This process manages them."
>        ::= { collectTemplate 2 }
>  
>    collectTemplateRcdEntry OBJECT-TYPE
>        SYNTAX      CollectTemplateRcdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the collectTemplateRcdTable"
>        INDEX {
>            collectExporterIndex,
>            collectObservDomainId,
>            collectMeteringProcessId,
>            collectTemplateRcdId,
>            collectTemplateRcdIndex }
>        ::= { collectTemplateRcdTable 1 }
> 
>    CollectTemplateRcdEntry ::=
>        SEQUENCE {
>            collectTemplateRcdIndex       Integer32,
>            collectTemplateRcdInfoEltId   Integer32,
>            collectTemplateInfoEltLength  Integer32,
>            collectTemplateRcdRowStatus   RowStatus
>        }
> 
> I'm wondering why we have this complex table (5 indexes) simply to 
> display how the templates decode.
> Somehow, I failed to find a business case for this table.
> On the top of that, the template id are unique per transport session, 
> missing in the index.

I will propose following table. 

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength

> 
> Regards, Benoit.
> 
> 
> 
> 
> 
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 03:19:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjDz-00077C-Ly; Tue, 17 Oct 2006 03:18:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDr-0006sD-Ky
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:18:47 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZj2i-0001WS-Rn
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:07:18 -0400
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
	k9H77FW26149; Tue, 17 Oct 2006 09:07:15 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H77EP25520; Tue, 17 Oct 2006 09:07:15 +0200 (CEST)
Message-ID: <45348122.2060007@cisco.com>
Date: Tue, 17 Oct 2006 09:07:14 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
References: <4533D03B.80100@cisco.com> <20061017142241.773D.AKOBA@nttv6.net>
In-Reply-To: <20061017142241.773D.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0658907533=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0658907533==
Content-Type: multipart/alternative;
	boundary="------------030908020206030705050500"

This is a multi-part message in MIME format.
--------------030908020206030705050500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,
> Dear Benoit and all,
>
> This thread is listed up No.6 comment "read-wite versus read-only".
>
>   
>> 6. And again the discussion about read-write versus read-only.
>> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
>> etc... are read-write.
>> Shall we limit the read-only with the "Units of Conformance"?
>>     
>
> It is OK that whole Collector-MIB module is "read-only", It is simply receiving
> exporting data as you mention. 
I'm happy that we agree, as you confused me. At some point in time, I 
was thinking that you wanted to configure Exporters information on the 
Collector via the Collector MIB, which is clearly not possible as there 
is no configuration mechanism in IPFIX.
> But, I hope that the configurable parameters
> of Exporter-MIB are "read-write" at least.
>   
Some of them make sense, I agree. I'm wondering where to stop. Shall we 
allow everything to be configure via SNMP on the Exporter?
Maybe the solution is to make all OID read-write, and that the "Units of 
Conformance" specify that the read-only is the minimum to implement.
That way, we clearly specify how to use the MIB for configuration, while 
not mandating it... in case there is a more appropriate solution (NETCONF?)

Regards, Benoit.
> I wonder that the flow configurable parameters are "read-only", 
> whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  
  


Dear Kobayashi,



  
Dear Benoit and all,

This thread is listed up No.6 comment "read-wite versus read-only".

  

  

    
6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
etc... are read-write.
Shall we limit the read-only with the "Units of Conformance"?
    

  

  

It is OK that whole Collector-MIB module is "read-only", It is simply receiving
exporting data as you mention. 



I'm happy that we agree, as you confused me. At some point in time, I
was thinking that you wanted to configure Exporters information on the
Collector via the Collector MIB, which is clearly not possible as there
is no configuration mechanism in IPFIX. 



  
But, I hope that the configurable parameters
of Exporter-MIB are "read-write" at least.
  



Some of them make sense, I agree. I'm wondering where to stop. Shall we
allow everything to be configure via SNMP on the Exporter?

Maybe the solution is to make all OID read-write, and that the "Units
of Conformance" specify that the read-only is the minimum to implement.

That way, we clearly specify how to use the MIB for configuration,
while not mandating it... in case there is a more appropriate solution
(NETCONF?)



Regards, Benoit.



  
I wonder that the flow configurable parameters are "read-only", 
whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------030908020206030705050500--


--===============0658907533==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0658907533==--




From ipfix-bounces@ietf.org Tue Oct 17 03:19:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjDz-00077C-Ly; Tue, 17 Oct 2006 03:18:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDr-0006sD-Ky
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:18:47 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZj2i-0001WS-Rn
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:07:18 -0400
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
	k9H77FW26149; Tue, 17 Oct 2006 09:07:15 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H77EP25520; Tue, 17 Oct 2006 09:07:15 +0200 (CEST)
Message-ID: <45348122.2060007@cisco.com>
Date: Tue, 17 Oct 2006 09:07:14 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
References: <4533D03B.80100@cisco.com> <20061017142241.773D.AKOBA@nttv6.net>
In-Reply-To: <20061017142241.773D.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0658907533=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0658907533==
Content-Type: multipart/alternative;
	boundary="------------030908020206030705050500"

This is a multi-part message in MIME format.
--------------030908020206030705050500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,
> Dear Benoit and all,
>
> This thread is listed up No.6 comment "read-wite versus read-only".
>
>   
>> 6. And again the discussion about read-write versus read-only.
>> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
>> etc... are read-write.
>> Shall we limit the read-only with the "Units of Conformance"?
>>     
>
> It is OK that whole Collector-MIB module is "read-only", It is simply receiving
> exporting data as you mention. 
I'm happy that we agree, as you confused me. At some point in time, I 
was thinking that you wanted to configure Exporters information on the 
Collector via the Collector MIB, which is clearly not possible as there 
is no configuration mechanism in IPFIX.
> But, I hope that the configurable parameters
> of Exporter-MIB are "read-write" at least.
>   
Some of them make sense, I agree. I'm wondering where to stop. Shall we 
allow everything to be configure via SNMP on the Exporter?
Maybe the solution is to make all OID read-write, and that the "Units of 
Conformance" specify that the read-only is the minimum to implement.
That way, we clearly specify how to use the MIB for configuration, while 
not mandating it... in case there is a more appropriate solution (NETCONF?)

Regards, Benoit.
> I wonder that the flow configurable parameters are "read-only", 
> whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  
  


Dear Kobayashi,



  
Dear Benoit and all,

This thread is listed up No.6 comment "read-wite versus read-only".

  

  

    
6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
etc... are read-write.
Shall we limit the read-only with the "Units of Conformance"?
    

  

  

It is OK that whole Collector-MIB module is "read-only", It is simply receiving
exporting data as you mention. 



I'm happy that we agree, as you confused me. At some point in time, I
was thinking that you wanted to configure Exporters information on the
Collector via the Collector MIB, which is clearly not possible as there
is no configuration mechanism in IPFIX. 



  
But, I hope that the configurable parameters
of Exporter-MIB are "read-write" at least.
  



Some of them make sense, I agree. I'm wondering where to stop. Shall we
allow everything to be configure via SNMP on the Exporter?

Maybe the solution is to make all OID read-write, and that the "Units
of Conformance" specify that the read-only is the minimum to implement.

That way, we clearly specify how to use the MIB for configuration,
while not mandating it... in case there is a more appropriate solution
(NETCONF?)



Regards, Benoit.



  
I wonder that the flow configurable parameters are "read-only", 
whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------030908020206030705050500--


--===============0658907533==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0658907533==--




From ipfix-bounces@ietf.org Tue Oct 17 03:19:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjEn-0007rh-B9; Tue, 17 Oct 2006 03:19:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDQ-0006eG-9H
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:18:20 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZjA8-0002XO-Gl
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:14:57 -0400
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
	k9H7Etr26600; Tue, 17 Oct 2006 09:14:55 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H7EsP00311; Tue, 17 Oct 2006 09:14:54 +0200 (CEST)
Message-ID: <453482EE.6050401@cisco.com>
Date: Tue, 17 Oct 2006 09:14:54 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB (RowStatus)
References: <4533D03B.80100@cisco.com> <20061017143347.7740.AKOBA@nttv6.net>
In-Reply-To: <20061017143347.7740.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0232250677=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0232250677==
Content-Type: multipart/alternative;
	boundary="------------000003080908060109090704"

This is a multi-part message in MIME format.
--------------000003080908060109090704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,
> Dear Benoit and all,
>
> This thread is listed up No.11 comment "Row status".
>
> I simply imaged that the row of table is deleted or created by SNMP.
>   
My point is: how could you create a new entry in the specific case, as 
you can only read ipfixTemplateFieldId, and not set it.
> You mean that RowStatus in statistics table should be removed?
>   
Yes, unless you want to say: I'm continuously monitor the stats (which 
update themselves automatically), but I can use the RowStatus "delete" 
to delete a specific entry to "clear" the stats.
However, even if possible, I don't think RowStatus was foreseen for that 
case as a single delta of two polling would return the right information.

> As statistic table shows only performance data that is not configurable
> parameter, I think that Rowstatus is certainly needless.
>   
We agree.

Regards, Benoit.
>   
>> 11. only ipfixTemplateRowStatus  is read-write in this table
>>  
>>    IpfixTemplateEntry ::= SEQUENCE {
>>            ipfixTemplateId          Integer32,
>>            ipfixTemplateIndex       Integer32,
>>            ipfixTemplateFieldId     Integer32,
>>            ipfixTemplateRowStatus   RowStatus
>>        }
>>  
>>    ipfixTemplateId OBJECT-TYPE
>>        SYNTAX      Integer32 (1..2147483647)
>>        MAX-ACCESS  not-accessible        
>> <--------------------------------------------------
>>        STATUS      current
>>        DESCRIPTION
>>            "The unique identifier for the template."
>>        REFERENCE
>>            "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
>>    -- Editor Note: get reference right!
>>        ::= { ipfixTemplateEntry 1 }
>>  
>>    ipfixTemplateIndex OBJECT-TYPE
>>        SYNTAX      Integer32 (1..2147483647)
>>        MAX-ACCESS  not-accessible        
>> <--------------------------------------------------
>>        STATUS      current
>>        DESCRIPTION
>>            "The locally arbitrary, but unique identifier of a field Id
>>             in the template identified by ipfixTemplateId.
>>  
>>             The value is expected to remain constant at least from one
>>             re-initialization of the entity's network management system
>>             to the next re-initialization."
>>        ::= { ipfixTemplateEntry 2 }
>>
>>   ipfixTemplateFieldId OBJECT-TYPE
>>        SYNTAX      Integer32
>>        MAX-ACCESS  read-only        
>> <--------------------------------------------------
>>        STATUS      current         
>>        DESCRIPTION
>>            "The Field Id at position ipfixTemplateIndex in the template
>>             ipfixTemplateId. This implicitly gives the data type and
>>             state values that are exported."
>>        REFERENCE
>>            "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
>>    -- Editor Note: get reference right!
>>        ::= { ipfixTemplateEntry 3 }
>>  
>>    ipfixTemplateRowStatus OBJECT-TYPE
>>        SYNTAX      RowStatus
>>        MAX-ACCESS  read-create
>>        STATUS      current
>>        DESCRIPTION
>>            "The status of this row of the table."
>>        ::= { ipfixTemplateEntry 4 }
>>
>> Only ipfixTemplateRowStatus  is read-write in this table. What does it 
>> mean? Can only deleted by SNMP? And not created?
>>
>>     
>
>   
>>     
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  


Dear Kobayashi,


  
Dear Benoit and all,

This thread is listed up No.11 comment "Row status".

I simply imaged that the row of table is deleted or created by SNMP.
  



My point is: how could you create a new entry in the specific case, as
you can only read ipfixTemplateFieldId, and not set it.


  
You mean that RowStatus in statistics table should be removed?
  



Yes, unless you want to say: I'm continuously monitor the stats (which
update themselves automatically), but I can use the RowStatus "delete"
to delete a specific entry to "clear" the stats.

However, even if possible, I don't think RowStatus was foreseen for
that case as a single delta of two polling would return the right
information.





  
As statistic table shows only performance data that is not configurable
parameter, I think that Rowstatus is certainly needless.
  



We agree.



Regards, Benoit.



  
  

  

    
11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only        
<--------------------------------------------------
       STATUS      current         
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it 
mean? Can only deleted by SNMP? And not created?

    

  

  

  

  

    
    

  

  

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------000003080908060109090704--


--===============0232250677==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0232250677==--




From ipfix-bounces@ietf.org Tue Oct 17 03:19:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjEn-0007rh-B9; Tue, 17 Oct 2006 03:19:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDQ-0006eG-9H
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:18:20 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZjA8-0002XO-Gl
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:14:57 -0400
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
	k9H7Etr26600; Tue, 17 Oct 2006 09:14:55 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H7EsP00311; Tue, 17 Oct 2006 09:14:54 +0200 (CEST)
Message-ID: <453482EE.6050401@cisco.com>
Date: Tue, 17 Oct 2006 09:14:54 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB (RowStatus)
References: <4533D03B.80100@cisco.com> <20061017143347.7740.AKOBA@nttv6.net>
In-Reply-To: <20061017143347.7740.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0232250677=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0232250677==
Content-Type: multipart/alternative;
	boundary="------------000003080908060109090704"

This is a multi-part message in MIME format.
--------------000003080908060109090704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,
> Dear Benoit and all,
>
> This thread is listed up No.11 comment "Row status".
>
> I simply imaged that the row of table is deleted or created by SNMP.
>   
My point is: how could you create a new entry in the specific case, as 
you can only read ipfixTemplateFieldId, and not set it.
> You mean that RowStatus in statistics table should be removed?
>   
Yes, unless you want to say: I'm continuously monitor the stats (which 
update themselves automatically), but I can use the RowStatus "delete" 
to delete a specific entry to "clear" the stats.
However, even if possible, I don't think RowStatus was foreseen for that 
case as a single delta of two polling would return the right information.

> As statistic table shows only performance data that is not configurable
> parameter, I think that Rowstatus is certainly needless.
>   
We agree.

Regards, Benoit.
>   
>> 11. only ipfixTemplateRowStatus  is read-write in this table
>>  
>>    IpfixTemplateEntry ::= SEQUENCE {
>>            ipfixTemplateId          Integer32,
>>            ipfixTemplateIndex       Integer32,
>>            ipfixTemplateFieldId     Integer32,
>>            ipfixTemplateRowStatus   RowStatus
>>        }
>>  
>>    ipfixTemplateId OBJECT-TYPE
>>        SYNTAX      Integer32 (1..2147483647)
>>        MAX-ACCESS  not-accessible        
>> <--------------------------------------------------
>>        STATUS      current
>>        DESCRIPTION
>>            "The unique identifier for the template."
>>        REFERENCE
>>            "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
>>    -- Editor Note: get reference right!
>>        ::= { ipfixTemplateEntry 1 }
>>  
>>    ipfixTemplateIndex OBJECT-TYPE
>>        SYNTAX      Integer32 (1..2147483647)
>>        MAX-ACCESS  not-accessible        
>> <--------------------------------------------------
>>        STATUS      current
>>        DESCRIPTION
>>            "The locally arbitrary, but unique identifier of a field Id
>>             in the template identified by ipfixTemplateId.
>>  
>>             The value is expected to remain constant at least from one
>>             re-initialization of the entity's network management system
>>             to the next re-initialization."
>>        ::= { ipfixTemplateEntry 2 }
>>
>>   ipfixTemplateFieldId OBJECT-TYPE
>>        SYNTAX      Integer32
>>        MAX-ACCESS  read-only        
>> <--------------------------------------------------
>>        STATUS      current         
>>        DESCRIPTION
>>            "The Field Id at position ipfixTemplateIndex in the template
>>             ipfixTemplateId. This implicitly gives the data type and
>>             state values that are exported."
>>        REFERENCE
>>            "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
>>    -- Editor Note: get reference right!
>>        ::= { ipfixTemplateEntry 3 }
>>  
>>    ipfixTemplateRowStatus OBJECT-TYPE
>>        SYNTAX      RowStatus
>>        MAX-ACCESS  read-create
>>        STATUS      current
>>        DESCRIPTION
>>            "The status of this row of the table."
>>        ::= { ipfixTemplateEntry 4 }
>>
>> Only ipfixTemplateRowStatus  is read-write in this table. What does it 
>> mean? Can only deleted by SNMP? And not created?
>>
>>     
>
>   
>>     
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  


Dear Kobayashi,


  
Dear Benoit and all,

This thread is listed up No.11 comment "Row status".

I simply imaged that the row of table is deleted or created by SNMP.
  



My point is: how could you create a new entry in the specific case, as
you can only read ipfixTemplateFieldId, and not set it.


  
You mean that RowStatus in statistics table should be removed?
  



Yes, unless you want to say: I'm continuously monitor the stats (which
update themselves automatically), but I can use the RowStatus "delete"
to delete a specific entry to "clear" the stats.

However, even if possible, I don't think RowStatus was foreseen for
that case as a single delta of two polling would return the right
information.





  
As statistic table shows only performance data that is not configurable
parameter, I think that Rowstatus is certainly needless.
  



We agree.



Regards, Benoit.



  
  

  

    
11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only        
<--------------------------------------------------
       STATUS      current         
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it 
mean? Can only deleted by SNMP? And not created?

    

  

  

  

  

    
    

  

  

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------000003080908060109090704--


--===============0232250677==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0232250677==--




From ipfix-bounces@ietf.org Tue Oct 17 03:30:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjP2-0006St-TU; Tue, 17 Oct 2006 03:30:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjP2-0006Sk-3A
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:30:20 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZjP1-0005Im-0E
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:30:20 -0400
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
	k9H7UI627545; Tue, 17 Oct 2006 09:30:18 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H7UGP09771; Tue, 17 Oct 2006 09:30:16 +0200 (CEST)
Message-ID: <45348688.7000707@cisco.com>
Date: Tue, 17 Oct 2006 09:30:16 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
References: <4533D03B.80100@cisco.com> <20061017143912.7743.AKOBA@nttv6.net>
In-Reply-To: <20061017143912.7743.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0026582024=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0026582024==
Content-Type: multipart/alternative;
	boundary="------------020502010509000909050904"

This is a multi-part message in MIME format.
--------------020502010509000909050904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,

Many thanks for your work on the MIB.
See inline.
> Dear Benoit and all,
>
> I answer some of comments about COLLECTOR-MIB in inline.
> They are 13, 14, 15, 16, 17, 18, and 19.
>
> snip.
>
>   
>> 13. In ipfixReporting, I really would like to see some stats.
>> Coming from the NetFlow MIB:
>>
>>     cnfESExportRate OBJECT-TYPE
>>         SYNTAX     Counter32
>>         UNITS      "bytes per second"
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of Bytes exported per second."
>>         ::= { cnfExportStatistics  2 }
>>
>>     cnfESRecordsExported OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of flow statistics  records which were exported."
>>         ::= { cnfExportStatistics  3 }
>>
>>     cnfESPktsExported OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of packets (udp datagrams) which were exported."
>>         ::= { cnfExportStatistics  4 }
>>
>>     cnfESPktsFailed OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of times a flow record could not be exported because of
>>              a pak allocation failure."
>>         ::= { cnfExportStatistics  5 }
>>
>>     cnfESPktsDropped OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of export packets which were dropped at the time of
>>              ipwrite operation. The reasons for this failure are no FIB,
>>              adjacency failure, MTU failed, enqueue failed, IPC failed etc."
>>         ::= { cnfExportStatistics  6 }
>>
>>
>> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
>>
>>     
>
> I almost agree your comment. But, I have been considering three statistics tables
> as follows. 
> The Exporter statistics table will be changed session statstics table  in
> consideration of backup multiple session between a Exporter and a Collector. 
> Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
>   
At first glance, I would think it makes sense if we want to be able to 
compare stats. I would see a good case for UDP
> (*) means index in this table.
>
>  ipfixSessionStatsTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>    ipfixSessionPackets
>    ipfixSessionBytes
>    ipfixSessionMessages
>    ipfixSessionDiscardMessages
>    ipfixSessionFlows
>    ipfixSessionTemplates
>    ipfixSessionElapsedTime
>   
I'm wondering whether we need the O.D. as an index in the table above: 
maybe in case of multiple line cards exporting via the same session?
If this is the case, the table above and below could potentially be 
combined.
What's happening when a session is not active anymore. Is it simply 
removed form that table? Or kept for some time? If the latter, do you 
want to have "active/inactive" or the notion of time? This remark will 
be important for the comment 19 below.
>  
>  ipfixObdomainStats
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>    ipfixObdomainMessages
>    ipfixObdomainFlows
>    ipfixObdomainTemplates
>    ipfixObdomainLatestSeqNumber
>    ipfixObdomainDisorderdSeqNumbers
>
>  ipfixTemplateStatsTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>   *ipfixTemplateId
>    ipfixTempFlows
>    ipfixTempReceivedTime
>
>   
>>    collectExporterStatisEntry OBJECT-TYPE
>>        SYNTAX      CollectExporterStatisEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "Defines an entry in the collectExporterStatisTable"
>>        INDEX { collectExporterIndex,
>>                collectExporterDstPort }
>>        ::= { collectExporterStatisTable 1 }
>>  
>>    CollectExporterStatisEntry ::=
>>        SEQUENCE {
>>            collectExporterDstPort           Integer32,
>>            collectExporterProcessId         Integer32,
>>            collectExporterRcdPackets        Counter32,
>>            collectExporterRcdBytes          Counter32,
>>            collectExporterRcdMessages       Counter32,
>>            collectExporterDiscardMessages   Counter32,
>>            collectSessionElapsedTime        Gauge32,
>>            collectExporterRcdFlows          Counter32,
>>            collectExporterRcdTemplates      Counter32,
>>            collectExporterStatisRowStatus   RowStatus
>>
>>
>>  14. collectExporterTable  
>>
>>
>>    collectExporterTable  OBJECT-TYPE
>>        SYNTAX      SEQUENCE OF
>>                    CollectExporterEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "This table lists Exporters that received by collecting
>>            process. This process manages them."
>>        ::= { collectExporter 1 }
>>
>>   CollectExporterEntry ::=
>>        SEQUENCE {
>>            collectExporterIndex             Integer32,
>>            collectExporterSrcIpAddrType     InetAddressType,
>>            collectExporterSrcIpAddr         InetAddress,
>>            collectExporterProtocol          Integer32,
>>            collectExporterSrcPort           Integer32,
>>            collectLifeTimeTemplate          Integer32,
>>            collectExporterRowStatus         RowStatus
>>        }
>>
>> What is the goal of that MIB table.
>> As this read-write, it means that I can _configure _on my Collector 
>> which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
>> I would not have any problems if that MIB table would be read-only, 
>> simply listing the Exporters the Collector receives info from.
>> Same question for the collectObservDomainStatisTable  .
>>
>>
>>     
> OK, I will change "read-only" objects in collectExporterTable and
> collectObservDomainStatisTable.
>
>   
>> 15. I think that we are missing the observation domain as an index in 
>> many tables
>> Example: as the Template IDs are unique per Observation Domain, 
>> ipfixTemplateTable must contains the O.D.id as an index
>> Example: ipfixInstanceTable
>> On the other hand, I don't clearly understand the goal of 
>> collectObservDomainStatisTable. Should we simply add the O.D.id to the 
>> collectExporterStatisTable  and combine those stats?
>>     
>
> I will propose  collectObservDomainStatisTable as follows.
> I think that it has three index in consideration of multiple ODID
> exporting to the same session.
>
> (*) means index in this table.
>
>  ipfixObdomainStats
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>    ipfixObdomainMessages
>    ipfixObdomainFlows
>    ipfixObdomainTemplates
>    ipfixObdomainLatestSeqNumber
>    ipfixObdomainDisorderdSeqNumbers
>
>  
>   
>> 16.
>>    collectExporterStatisEntry OBJECT-TYPE
>>        SYNTAX      CollectExporterStatisEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "Defines an entry in the collectExporterStatisTable"
>>        INDEX { collectExporterIndex,
>>                collectExporterDstPort }
>>
>> I don't understand why we have two indexes in this table? Isn't the 
>> collectExporterIndex enough? (next to the O.D.id: see point 16)
>>     
>
> I think that collectExporterIndex is enough after ODID discussion  in
> mailing list. 
> But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
> Is this table necessary?
>   
You're correct.
>   
>> 17.
>>
>>    collectMeteringProcessId OBJECT-TYPE
>>        SYNTAX      Integer32(1..2147483647)
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "It uses the Metering Process id in the received
>>            IPFIX message. It should be zero, if IPFIX message don't
>>            specify Metering Process id."
>>        ::= { collectObservDomainStatisEntry 2 }
>>
>> The IPFIX Message doesn't specify the Metering Process id, so it will 
>> always be zero. So I would not even mention it.
>> And remove it as index in collectObservDomainStatisTable  and 
>> collectTemplateStatisticsTable 
>>
>>     
>
> I will remove this object in these table.
>
>   
>> 18. collectTemplateStatisticsTable 
>> Again, why is there a rowStatus in that table?
>>
>>     
> I will remove this object in these table.
>
>   
>> 19.
>>
>>
>> collectTemplateRcdTable  OBJECT-TYPE
>>        SYNTAX      SEQUENCE OF
>>                    CollectTemplateRcdEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "This table lists templates that are received by the
>>            collecting process. This process manages them."
>>        ::= { collectTemplate 2 }
>>  
>>    collectTemplateRcdEntry OBJECT-TYPE
>>        SYNTAX      CollectTemplateRcdEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "Defines an entry in the collectTemplateRcdTable"
>>        INDEX {
>>            collectExporterIndex,
>>            collectObservDomainId,
>>            collectMeteringProcessId,
>>            collectTemplateRcdId,
>>            collectTemplateRcdIndex }
>>        ::= { collectTemplateRcdTable 1 }
>>
>>    CollectTemplateRcdEntry ::=
>>        SEQUENCE {
>>            collectTemplateRcdIndex       Integer32,
>>            collectTemplateRcdInfoEltId   Integer32,
>>            collectTemplateInfoEltLength  Integer32,
>>            collectTemplateRcdRowStatus   RowStatus
>>        }
>>
>> I'm wondering why we have this complex table (5 indexes) simply to 
>> display how the templates decode.
>> Somehow, I failed to find a business case for this table.
>> On the top of that, the template id are unique per transport session, 
>> missing in the index.
>>     
>
> I will propose following table. 
>
>  ipfixTemplateTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixTemplateId
>   *ipfixTemplateIndex
>    ipfixTemplateFieldId
>    ipfixTemplateFieldLength
>   
Somehow, I failed to find a business case for this table. How do you plan to use this info?
If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

Regards, Benoit.

>   
>> Regards, Benoit.
>>
>>
>>
>>
>>
>>
>>     
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  


Dear Kobayashi,



Many thanks for your work on the MIB.

See inline.



  
Dear Benoit and all,

I answer some of comments about COLLECTOR-MIB in inline.
They are 13, 14, 15, 16, 17, 18, and 19.

snip.

  

  

    
13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:

    cnfESExportRate OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "bytes per second"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of Bytes exported per second."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 2 }

    cnfESRecordsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of flow statistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=statistics> records which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 3 }

    cnfESPktsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of packets (udp datagrams) which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 4 }

    cnfESPktsFailed OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of times a flow record could not be exported because of
             a pak allocation failure."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 5 }

    cnfESPktsDropped OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of export packets which were dropped at the time of
             ipwrite operation. The reasons for this failure are no FIB,
             adjacency failure, MTU failed, enqueue failed, IPC failed etc."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 6 }


Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

    

  

  

I almost agree your comment. But, I have been considering three statistics tables
as follows. 
The Exporter statistics table will be changed session statstics table  in
consideration of backup multiple session between a Exporter and a Collector. 
Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
  



At first glance, I would think it makes sense if we want to be able to
compare stats. I would see a good case for UDP



  
(*) means index in this table.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
   ipfixSessionDiscardMessages
   ipfixSessionFlows
   ipfixSessionTemplates
   ipfixSessionElapsedTime
  



I'm wondering whether we need the O.D. as an index in the table above:
maybe in case of
multiple line cards exporting via the same session? 

If this is the case, the table above and below could potentially be
combined.

What's happening when a session is not active anymore. Is it simply
removed form that table? Or kept for some time? If the latter, do you
want to have "active/inactive" or the notion of time? This remark will
be important for the comment 19 below.



  
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

  

  

    
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus


 14. collectExporterTable  


   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can _configure _on my Collector 
which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, 
simply listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .


    

  

  
OK, I will change "read-only" objects in collectExporterTable and
collectObservDomainStatisTable.

  

  

    
15. I think that we are missing the observation domain as an index in 
many tables
Example: as the Template IDs are unique per Observation Domain, 
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable
On the other hand, I don't clearly understand the goal of 
collectObservDomainStatisTable. Should we simply add the O.D.id to the 
collectExporterStatisTable  and combine those stats?
    

  

  

I will propose  collectObservDomainStatisTable as follows.
I think that it has three index in consideration of multiple ODID
exporting to the same session.

(*) means index in this table.

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 
  

  

    
16.
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the 
collectExporterIndex enough? (next to the O.D.id: see point 16)
    

  

  

I think that collectExporterIndex is enough after ODID discussion  in
mailing list. 
But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
Is this table necessary?
  



You're correct.



  
  

  

    
17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will 
always be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and 
collectTemplateStatisticsTable 

    

  

  

I will remove this object in these table.

  

  

    
18. collectTemplateStatisticsTable 
Again, why is there a rowStatus in that table?

    

  

  
I will remove this object in these table.

  

  

    
19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to 
display how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session, 
missing in the index.
    

  

  

I will propose following table. 

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength
  




Somehow, I failed to find a business case for this table. How do you plan to use this info?
If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

Regards, Benoit.




  
  

  

    
Regards, Benoit.






    

  

  

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------020502010509000909050904--


--===============0026582024==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0026582024==--




From ipfix-bounces@ietf.org Tue Oct 17 03:30:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZjP2-0006St-TU; Tue, 17 Oct 2006 03:30:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjP2-0006Sk-3A
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:30:20 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZjP1-0005Im-0E
	for ipfix@ietf.org; Tue, 17 Oct 2006 03:30:20 -0400
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
	k9H7UI627545; Tue, 17 Oct 2006 09:30:18 +0200 (CEST)
Received: from [10.61.80.145] (ams3-vpn-dhcp4242.cisco.com [10.61.80.145])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9H7UGP09771; Tue, 17 Oct 2006 09:30:16 +0200 (CEST)
Message-ID: <45348688.7000707@cisco.com>
Date: Tue, 17 Oct 2006 09:30:16 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
References: <4533D03B.80100@cisco.com> <20061017143912.7743.AKOBA@nttv6.net>
In-Reply-To: <20061017143912.7743.AKOBA@nttv6.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0026582024=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0026582024==
Content-Type: multipart/alternative;
	boundary="------------020502010509000909050904"

This is a multi-part message in MIME format.
--------------020502010509000909050904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Kobayashi,

Many thanks for your work on the MIB.
See inline.
> Dear Benoit and all,
>
> I answer some of comments about COLLECTOR-MIB in inline.
> They are 13, 14, 15, 16, 17, 18, and 19.
>
> snip.
>
>   
>> 13. In ipfixReporting, I really would like to see some stats.
>> Coming from the NetFlow MIB:
>>
>>     cnfESExportRate OBJECT-TYPE
>>         SYNTAX     Counter32
>>         UNITS      "bytes per second"
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of Bytes exported per second."
>>         ::= { cnfExportStatistics  2 }
>>
>>     cnfESRecordsExported OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of flow statistics  records which were exported."
>>         ::= { cnfExportStatistics  3 }
>>
>>     cnfESPktsExported OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of packets (udp datagrams) which were exported."
>>         ::= { cnfExportStatistics  4 }
>>
>>     cnfESPktsFailed OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of times a flow record could not be exported because of
>>              a pak allocation failure."
>>         ::= { cnfExportStatistics  5 }
>>
>>     cnfESPktsDropped OBJECT-TYPE
>>         SYNTAX     Counter32
>>         MAX-ACCESS read-only
>>         STATUS     current
>>         DESCRIPTION        "Number of export packets which were dropped at the time of
>>              ipwrite operation. The reasons for this failure are no FIB,
>>              adjacency failure, MTU failed, enqueue failed, IPC failed etc."
>>         ::= { cnfExportStatistics  6 }
>>
>>
>> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
>>
>>     
>
> I almost agree your comment. But, I have been considering three statistics tables
> as follows. 
> The Exporter statistics table will be changed session statstics table  in
> consideration of backup multiple session between a Exporter and a Collector. 
> Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
>   
At first glance, I would think it makes sense if we want to be able to 
compare stats. I would see a good case for UDP
> (*) means index in this table.
>
>  ipfixSessionStatsTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>    ipfixSessionPackets
>    ipfixSessionBytes
>    ipfixSessionMessages
>    ipfixSessionDiscardMessages
>    ipfixSessionFlows
>    ipfixSessionTemplates
>    ipfixSessionElapsedTime
>   
I'm wondering whether we need the O.D. as an index in the table above: 
maybe in case of multiple line cards exporting via the same session?
If this is the case, the table above and below could potentially be 
combined.
What's happening when a session is not active anymore. Is it simply 
removed form that table? Or kept for some time? If the latter, do you 
want to have "active/inactive" or the notion of time? This remark will 
be important for the comment 19 below.
>  
>  ipfixObdomainStats
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>    ipfixObdomainMessages
>    ipfixObdomainFlows
>    ipfixObdomainTemplates
>    ipfixObdomainLatestSeqNumber
>    ipfixObdomainDisorderdSeqNumbers
>
>  ipfixTemplateStatsTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>   *ipfixTemplateId
>    ipfixTempFlows
>    ipfixTempReceivedTime
>
>   
>>    collectExporterStatisEntry OBJECT-TYPE
>>        SYNTAX      CollectExporterStatisEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "Defines an entry in the collectExporterStatisTable"
>>        INDEX { collectExporterIndex,
>>                collectExporterDstPort }
>>        ::= { collectExporterStatisTable 1 }
>>  
>>    CollectExporterStatisEntry ::=
>>        SEQUENCE {
>>            collectExporterDstPort           Integer32,
>>            collectExporterProcessId         Integer32,
>>            collectExporterRcdPackets        Counter32,
>>            collectExporterRcdBytes          Counter32,
>>            collectExporterRcdMessages       Counter32,
>>            collectExporterDiscardMessages   Counter32,
>>            collectSessionElapsedTime        Gauge32,
>>            collectExporterRcdFlows          Counter32,
>>            collectExporterRcdTemplates      Counter32,
>>            collectExporterStatisRowStatus   RowStatus
>>
>>
>>  14. collectExporterTable  
>>
>>
>>    collectExporterTable  OBJECT-TYPE
>>        SYNTAX      SEQUENCE OF
>>                    CollectExporterEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "This table lists Exporters that received by collecting
>>            process. This process manages them."
>>        ::= { collectExporter 1 }
>>
>>   CollectExporterEntry ::=
>>        SEQUENCE {
>>            collectExporterIndex             Integer32,
>>            collectExporterSrcIpAddrType     InetAddressType,
>>            collectExporterSrcIpAddr         InetAddress,
>>            collectExporterProtocol          Integer32,
>>            collectExporterSrcPort           Integer32,
>>            collectLifeTimeTemplate          Integer32,
>>            collectExporterRowStatus         RowStatus
>>        }
>>
>> What is the goal of that MIB table.
>> As this read-write, it means that I can _configure _on my Collector 
>> which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
>> I would not have any problems if that MIB table would be read-only, 
>> simply listing the Exporters the Collector receives info from.
>> Same question for the collectObservDomainStatisTable  .
>>
>>
>>     
> OK, I will change "read-only" objects in collectExporterTable and
> collectObservDomainStatisTable.
>
>   
>> 15. I think that we are missing the observation domain as an index in 
>> many tables
>> Example: as the Template IDs are unique per Observation Domain, 
>> ipfixTemplateTable must contains the O.D.id as an index
>> Example: ipfixInstanceTable
>> On the other hand, I don't clearly understand the goal of 
>> collectObservDomainStatisTable. Should we simply add the O.D.id to the 
>> collectExporterStatisTable  and combine those stats?
>>     
>
> I will propose  collectObservDomainStatisTable as follows.
> I think that it has three index in consideration of multiple ODID
> exporting to the same session.
>
> (*) means index in this table.
>
>  ipfixObdomainStats
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixObdomainId
>    ipfixObdomainMessages
>    ipfixObdomainFlows
>    ipfixObdomainTemplates
>    ipfixObdomainLatestSeqNumber
>    ipfixObdomainDisorderdSeqNumbers
>
>  
>   
>> 16.
>>    collectExporterStatisEntry OBJECT-TYPE
>>        SYNTAX      CollectExporterStatisEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "Defines an entry in the collectExporterStatisTable"
>>        INDEX { collectExporterIndex,
>>                collectExporterDstPort }
>>
>> I don't understand why we have two indexes in this table? Isn't the 
>> collectExporterIndex enough? (next to the O.D.id: see point 16)
>>     
>
> I think that collectExporterIndex is enough after ODID discussion  in
> mailing list. 
> But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
> Is this table necessary?
>   
You're correct.
>   
>> 17.
>>
>>    collectMeteringProcessId OBJECT-TYPE
>>        SYNTAX      Integer32(1..2147483647)
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "It uses the Metering Process id in the received
>>            IPFIX message. It should be zero, if IPFIX message don't
>>            specify Metering Process id."
>>        ::= { collectObservDomainStatisEntry 2 }
>>
>> The IPFIX Message doesn't specify the Metering Process id, so it will 
>> always be zero. So I would not even mention it.
>> And remove it as index in collectObservDomainStatisTable  and 
>> collectTemplateStatisticsTable 
>>
>>     
>
> I will remove this object in these table.
>
>   
>> 18. collectTemplateStatisticsTable 
>> Again, why is there a rowStatus in that table?
>>
>>     
> I will remove this object in these table.
>
>   
>> 19.
>>
>>
>> collectTemplateRcdTable  OBJECT-TYPE
>>        SYNTAX      SEQUENCE OF
>>                    CollectTemplateRcdEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>           "This table lists templates that are received by the
>>            collecting process. This process manages them."
>>        ::= { collectTemplate 2 }
>>  
>>    collectTemplateRcdEntry OBJECT-TYPE
>>        SYNTAX      CollectTemplateRcdEntry
>>        MAX-ACCESS  not-accessible
>>        STATUS      current
>>        DESCRIPTION
>>            "Defines an entry in the collectTemplateRcdTable"
>>        INDEX {
>>            collectExporterIndex,
>>            collectObservDomainId,
>>            collectMeteringProcessId,
>>            collectTemplateRcdId,
>>            collectTemplateRcdIndex }
>>        ::= { collectTemplateRcdTable 1 }
>>
>>    CollectTemplateRcdEntry ::=
>>        SEQUENCE {
>>            collectTemplateRcdIndex       Integer32,
>>            collectTemplateRcdInfoEltId   Integer32,
>>            collectTemplateInfoEltLength  Integer32,
>>            collectTemplateRcdRowStatus   RowStatus
>>        }
>>
>> I'm wondering why we have this complex table (5 indexes) simply to 
>> display how the templates decode.
>> Somehow, I failed to find a business case for this table.
>> On the top of that, the template id are unique per transport session, 
>> missing in the index.
>>     
>
> I will propose following table. 
>
>  ipfixTemplateTable
>   *ipfixExporterIndex
>   *ipfixSessionId
>   *ipfixTemplateId
>   *ipfixTemplateIndex
>    ipfixTemplateFieldId
>    ipfixTemplateFieldLength
>   
Somehow, I failed to find a business case for this table. How do you plan to use this info?
If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

Regards, Benoit.

>   
>> Regards, Benoit.
>>
>>
>>
>>
>>
>>
>>     
>
> --- 
> Atsushi KOBAYASHI  
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>   


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




  


Dear Kobayashi,



Many thanks for your work on the MIB.

See inline.



  
Dear Benoit and all,

I answer some of comments about COLLECTOR-MIB in inline.
They are 13, 14, 15, 16, 17, 18, and 19.

snip.

  

  

    
13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:

    cnfESExportRate OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "bytes per second"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of Bytes exported per second."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 2 }

    cnfESRecordsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of flow statistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=statistics> records which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 3 }

    cnfESPktsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of packets (udp datagrams) which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 4 }

    cnfESPktsFailed OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of times a flow record could not be exported because of
             a pak allocation failure."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 5 }

    cnfESPktsDropped OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of export packets which were dropped at the time of
             ipwrite operation. The reasons for this failure are no FIB,
             adjacency failure, MTU failed, enqueue failed, IPC failed etc."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 6 }


Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

    

  

  

I almost agree your comment. But, I have been considering three statistics tables
as follows. 
The Exporter statistics table will be changed session statstics table  in
consideration of backup multiple session between a Exporter and a Collector. 
Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
  



At first glance, I would think it makes sense if we want to be able to
compare stats. I would see a good case for UDP



  
(*) means index in this table.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
   ipfixSessionDiscardMessages
   ipfixSessionFlows
   ipfixSessionTemplates
   ipfixSessionElapsedTime
  



I'm wondering whether we need the O.D. as an index in the table above:
maybe in case of
multiple line cards exporting via the same session? 

If this is the case, the table above and below could potentially be
combined.

What's happening when a session is not active anymore. Is it simply
removed form that table? Or kept for some time? If the latter, do you
want to have "active/inactive" or the notion of time? This remark will
be important for the comment 19 below.



  
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

  

  

    
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus


 14. collectExporterTable  


   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can _configure _on my Collector 
which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, 
simply listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .


    

  

  
OK, I will change "read-only" objects in collectExporterTable and
collectObservDomainStatisTable.

  

  

    
15. I think that we are missing the observation domain as an index in 
many tables
Example: as the Template IDs are unique per Observation Domain, 
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable
On the other hand, I don't clearly understand the goal of 
collectObservDomainStatisTable. Should we simply add the O.D.id to the 
collectExporterStatisTable  and combine those stats?
    

  

  

I will propose  collectObservDomainStatisTable as follows.
I think that it has three index in consideration of multiple ODID
exporting to the same session.

(*) means index in this table.

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 
  

  

    
16.
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the 
collectExporterIndex enough? (next to the O.D.id: see point 16)
    

  

  

I think that collectExporterIndex is enough after ODID discussion  in
mailing list. 
But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
Is this table necessary?
  



You're correct.



  
  

  

    
17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will 
always be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and 
collectTemplateStatisticsTable 

    

  

  

I will remove this object in these table.

  

  

    
18. collectTemplateStatisticsTable 
Again, why is there a rowStatus in that table?

    

  

  
I will remove this object in these table.

  

  

    
19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to 
display how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session, 
missing in the index.
    

  

  

I will propose following table. 

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength
  




Somehow, I failed to find a business case for this table. How do you plan to use this info?
If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

Regards, Benoit.




  
  

  

    
Regards, Benoit.






    

  

  

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
  








--------------020502010509000909050904--


--===============0026582024==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0026582024==--




From ipfix-bounces@ietf.org Tue Oct 17 05:00:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZknh-0005bv-EH; Tue, 17 Oct 2006 04:59:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkng-0005bc-8n
	for ipfix@ietf.org; Tue, 17 Oct 2006 04:59:52 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZknc-0005YL-Nj
	for ipfix@ietf.org; Tue, 17 Oct 2006 04:59:52 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H8xS0o026726;
	Tue, 17 Oct 2006 17:59:29 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 17:59:43 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
In-Reply-To: <45348122.2060007@cisco.com>
References: <20061017142241.773D.AKOBA@nttv6.net> <45348122.2060007@cisco.com>
Message-Id: <20061017175421.774E.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

I wrote my comment inline.

On Tue, 17 Oct 2006 09:07:14 +0200
Benoit Claise  wrote:

> Dear Kobayashi,
> > Dear Benoit and all,
> >
> > This thread is listed up No.6 comment "read-wite versus read-only".
> >
> >   
> >> 6. And again the discussion about read-write versus read-only.
> >> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
> >> etc... are read-write.
> >> Shall we limit the read-only with the "Units of Conformance"?
> >>     
> >
> > It is OK that whole Collector-MIB module is "read-only", It is simply receiving
> > exporting data as you mention. 
> I'm happy that we agree, as you confused me. At some point in time, I 
> was thinking that you wanted to configure Exporters information on the 
> Collector via the Collector MIB, which is clearly not possible as there 
> is no configuration mechanism in IPFIX.
> > But, I hope that the configurable parameters
> > of Exporter-MIB are "read-write" at least.
> >   
> Some of them make sense, I agree. I'm wondering where to stop. Shall we 
> allow everything to be configure via SNMP on the Exporter?
> Maybe the solution is to make all OID read-write, and that the "Units of 
> Conformance" specify that the read-only is the minimum to implement.
> That way, we clearly specify how to use the MIB for configuration, while 
> not mandating it... in case there is a more appropriate solution (NETCONF?)

You mean that minimum conformance set is "read-only"?
We can show the implementation of some conformance IPFIX device 
by defining MIB. That MIB should be reflected from conformance IPFIX.
If read-only, we can not recognize whether each parameter is 
implemented parameter of device, or configurable parameter.
NETCONF is better solution, but NETCONF data model is created based on 
this MIB module. 

Regards,
Atsushi KOBAYASHI

> 
> Regards, Benoit.
> > I wonder that the flow configurable parameters are "read-only", 
> > whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.
> >
> > --- 
> > Atsushi KOBAYASHI  
> > NTT Information Sharing Platform Lab.
> > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> >   
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 05:00:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZknh-0005bv-EH; Tue, 17 Oct 2006 04:59:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkng-0005bc-8n
	for ipfix@ietf.org; Tue, 17 Oct 2006 04:59:52 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZknc-0005YL-Nj
	for ipfix@ietf.org; Tue, 17 Oct 2006 04:59:52 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H8xS0o026726;
	Tue, 17 Oct 2006 17:59:29 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 17:59:43 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB( read-wite versus read-only)
In-Reply-To: <45348122.2060007@cisco.com>
References: <20061017142241.773D.AKOBA@nttv6.net> <45348122.2060007@cisco.com>
Message-Id: <20061017175421.774E.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

I wrote my comment inline.

On Tue, 17 Oct 2006 09:07:14 +0200
Benoit Claise  wrote:

> Dear Kobayashi,
> > Dear Benoit and all,
> >
> > This thread is listed up No.6 comment "read-wite versus read-only".
> >
> >   
> >> 6. And again the discussion about read-write versus read-only.
> >> ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
> >> etc... are read-write.
> >> Shall we limit the read-only with the "Units of Conformance"?
> >>     
> >
> > It is OK that whole Collector-MIB module is "read-only", It is simply receiving
> > exporting data as you mention. 
> I'm happy that we agree, as you confused me. At some point in time, I 
> was thinking that you wanted to configure Exporters information on the 
> Collector via the Collector MIB, which is clearly not possible as there 
> is no configuration mechanism in IPFIX.
> > But, I hope that the configurable parameters
> > of Exporter-MIB are "read-write" at least.
> >   
> Some of them make sense, I agree. I'm wondering where to stop. Shall we 
> allow everything to be configure via SNMP on the Exporter?
> Maybe the solution is to make all OID read-write, and that the "Units of 
> Conformance" specify that the read-only is the minimum to implement.
> That way, we clearly specify how to use the MIB for configuration, while 
> not mandating it... in case there is a more appropriate solution (NETCONF?)

You mean that minimum conformance set is "read-only"?
We can show the implementation of some conformance IPFIX device 
by defining MIB. That MIB should be reflected from conformance IPFIX.
If read-only, we can not recognize whether each parameter is 
implemented parameter of device, or configurable parameter.
NETCONF is better solution, but NETCONF data model is created based on 
this MIB module. 

Regards,
Atsushi KOBAYASHI

> 
> Regards, Benoit.
> > I wonder that the flow configurable parameters are "read-only", 
> > whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.
> >
> > --- 
> > Atsushi KOBAYASHI  
> > NTT Information Sharing Platform Lab.
> > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> >   
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 05:50:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZlZp-000760-DQ; Tue, 17 Oct 2006 05:49:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlZn-00072Z-Dc
	for ipfix@ietf.org; Tue, 17 Oct 2006 05:49:35 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlZl-0007HT-PB
	for ipfix@ietf.org; Tue, 17 Oct 2006 05:49:35 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H9nQL4026981;
	Tue, 17 Oct 2006 18:49:30 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 18:49:46 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
In-Reply-To: <45348688.7000707@cisco.com>
References: <20061017143912.7743.AKOBA@nttv6.net> <45348688.7000707@cisco.com>
Message-Id: <20061017180638.7751.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

Please see inline.

snip

> >>
> >> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
> >>
> >>     
> >
> > I almost agree your comment. But, I have been considering three statistics tables
> > as follows. 
> > The Exporter statistics table will be changed session statstics table  in
> > consideration of backup multiple session between a Exporter and a Collector. 
> > Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
> >   
> At first glance, I would think it makes sense if we want to be able to 
> compare stats. I would see a good case for UDP
> > (*) means index in this table.
> >
> >  ipfixSessionStatsTable
> >   *ipfixExporterIndex
> >   *ipfixSessionId
> >    ipfixSessionPackets
> >    ipfixSessionBytes
> >    ipfixSessionMessages
> >    ipfixSessionDiscardMessages
> >    ipfixSessionFlows
> >    ipfixSessionTemplates
> >    ipfixSessionElapsedTime
> >   
> I'm wondering whether we need the O.D. as an index in the table above: 
> maybe in case of multiple line cards exporting via the same session?
> If this is the case, the table above and below could potentially be 
> combined.

You mean that each statistics parameter in the ipfixSessionStatsTable is
the result of aggregation of multiple ipfixObdomainStats in same session?

If yes, we can remove several parameters in ipfixSessionStatsTable.  But,
ipfixSessionElapsedTime is maintained in this table.

> What's happening when a session is not active anymore. Is it simply 
> removed form that table? Or kept for some time? If the latter, do you 
> want to have "active/inactive" or the notion of time? This remark will 
> be important for the comment 19 below.

I think that latter condition. I will propose another table as follows.

 ipfixSessionTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionStatus
   ipfixSessionProtocol
   ipfixSessionDstPort
   ipfixSessionSrcPort 

Above sessionId is kept with session statistics data for some time, after
session is down. We can see session status by retrieving ipfixSessionStatus
object.

> >  

snip

> >>    collectTemplateRcdEntry OBJECT-TYPE
> >>        SYNTAX      CollectTemplateRcdEntry
> >>        MAX-ACCESS  not-accessible
> >>        STATUS      current
> >>        DESCRIPTION
> >>            "Defines an entry in the collectTemplateRcdTable"
> >>        INDEX {
> >>            collectExporterIndex,
> >>            collectObservDomainId,
> >>            collectMeteringProcessId,
> >>            collectTemplateRcdId,
> >>            collectTemplateRcdIndex }
> >>        ::= { collectTemplateRcdTable 1 }
> >>
> >>    CollectTemplateRcdEntry ::=
> >>        SEQUENCE {
> >>            collectTemplateRcdIndex       Integer32,
> >>            collectTemplateRcdInfoEltId   Integer32,
> >>            collectTemplateInfoEltLength  Integer32,
> >>            collectTemplateRcdRowStatus   RowStatus
> >>        }
> >>
> >> I'm wondering why we have this complex table (5 indexes) simply to 
> >> display how the templates decode.
> >> Somehow, I failed to find a business case for this table.
> >> On the top of that, the template id are unique per transport session, 
> >> missing in the index.
> >>     
> >
> > I will propose following table. 
> >
> >  ipfixTemplateTable
> >   *ipfixExporterIndex
> >   *ipfixSessionId
> >   *ipfixTemplateId
> >   *ipfixTemplateIndex
> >    ipfixTemplateFieldId
> >    ipfixTemplateFieldLength
> >   
> Somehow, I failed to find a business case for this table. How do you plan to use this info?
> If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
> So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

First of all, collecting process should keep template id with field
contents. 
And also, COLLECTOR-MIB maintains per template statistics data.
We can recognize each template is sort of template, such as IPv4,
IPv6, the number of label stack MPLS. Template statistics data is
valuable by seeing sort of template.
And also, another node can see what information elements are stored in
this collector. It can retrieve flow records adequately.

> 
> Regards, Benoit.
> 
> >   
> >> Regards, Benoit.
> >>
> >>
> >>
> >>
> >>
> >>
> >>     
> >
> > --- 
> > Atsushi KOBAYASHI  
> > NTT Information Sharing Platform Lab.
> > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> >   
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 05:50:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZlZp-000760-DQ; Tue, 17 Oct 2006 05:49:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlZn-00072Z-Dc
	for ipfix@ietf.org; Tue, 17 Oct 2006 05:49:35 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlZl-0007HT-PB
	for ipfix@ietf.org; Tue, 17 Oct 2006 05:49:35 -0400
Received: from [127.0.0.1] (dhcp-3-194.nttv6.com [192.47.163.194])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9H9nQL4026981;
	Tue, 17 Oct 2006 18:49:30 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Tue, 17 Oct 2006 18:49:46 +0900
From: kobayashi atsushi 
To: Benoit Claise 
Subject: Re: [IPFIX] IPFIX MIB (COLLECTOR-MIB)
In-Reply-To: <45348688.7000707@cisco.com>
References: <20061017143912.7743.AKOBA@nttv6.net> <45348688.7000707@cisco.com>
Message-Id: <20061017180638.7751.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear Benoit and all,

Please see inline.

snip

> >>
> >> Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.
> >>
> >>     
> >
> > I almost agree your comment. But, I have been considering three statistics tables
> > as follows. 
> > The Exporter statistics table will be changed session statstics table  in
> > consideration of backup multiple session between a Exporter and a Collector. 
> > Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
> >   
> At first glance, I would think it makes sense if we want to be able to 
> compare stats. I would see a good case for UDP
> > (*) means index in this table.
> >
> >  ipfixSessionStatsTable
> >   *ipfixExporterIndex
> >   *ipfixSessionId
> >    ipfixSessionPackets
> >    ipfixSessionBytes
> >    ipfixSessionMessages
> >    ipfixSessionDiscardMessages
> >    ipfixSessionFlows
> >    ipfixSessionTemplates
> >    ipfixSessionElapsedTime
> >   
> I'm wondering whether we need the O.D. as an index in the table above: 
> maybe in case of multiple line cards exporting via the same session?
> If this is the case, the table above and below could potentially be 
> combined.

You mean that each statistics parameter in the ipfixSessionStatsTable is
the result of aggregation of multiple ipfixObdomainStats in same session?

If yes, we can remove several parameters in ipfixSessionStatsTable.  But,
ipfixSessionElapsedTime is maintained in this table.

> What's happening when a session is not active anymore. Is it simply 
> removed form that table? Or kept for some time? If the latter, do you 
> want to have "active/inactive" or the notion of time? This remark will 
> be important for the comment 19 below.

I think that latter condition. I will propose another table as follows.

 ipfixSessionTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionStatus
   ipfixSessionProtocol
   ipfixSessionDstPort
   ipfixSessionSrcPort 

Above sessionId is kept with session statistics data for some time, after
session is down. We can see session status by retrieving ipfixSessionStatus
object.

> >  

snip

> >>    collectTemplateRcdEntry OBJECT-TYPE
> >>        SYNTAX      CollectTemplateRcdEntry
> >>        MAX-ACCESS  not-accessible
> >>        STATUS      current
> >>        DESCRIPTION
> >>            "Defines an entry in the collectTemplateRcdTable"
> >>        INDEX {
> >>            collectExporterIndex,
> >>            collectObservDomainId,
> >>            collectMeteringProcessId,
> >>            collectTemplateRcdId,
> >>            collectTemplateRcdIndex }
> >>        ::= { collectTemplateRcdTable 1 }
> >>
> >>    CollectTemplateRcdEntry ::=
> >>        SEQUENCE {
> >>            collectTemplateRcdIndex       Integer32,
> >>            collectTemplateRcdInfoEltId   Integer32,
> >>            collectTemplateInfoEltLength  Integer32,
> >>            collectTemplateRcdRowStatus   RowStatus
> >>        }
> >>
> >> I'm wondering why we have this complex table (5 indexes) simply to 
> >> display how the templates decode.
> >> Somehow, I failed to find a business case for this table.
> >> On the top of that, the template id are unique per transport session, 
> >> missing in the index.
> >>     
> >
> > I will propose following table. 
> >
> >  ipfixTemplateTable
> >   *ipfixExporterIndex
> >   *ipfixSessionId
> >   *ipfixTemplateId
> >   *ipfixTemplateIndex
> >    ipfixTemplateFieldId
> >    ipfixTemplateFieldLength
> >   
> Somehow, I failed to find a business case for this table. How do you plan to use this info?
> If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
> So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

First of all, collecting process should keep template id with field
contents. 
And also, COLLECTOR-MIB maintains per template statistics data.
We can recognize each template is sort of template, such as IPv4,
IPv6, the number of label stack MPLS. Template statistics data is
valuable by seeing sort of template.
And also, another node can see what information elements are stored in
this collector. It can retrieve flow records adequately.

> 
> Regards, Benoit.
> 
> >   
> >> Regards, Benoit.
> >>
> >>
> >>
> >>
> >>
> >>
> >>     
> >
> > --- 
> > Atsushi KOBAYASHI  
> > NTT Information Sharing Platform Lab.
> > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> >   
> 

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Tue Oct 17 07:35:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZnCO-0000sq-AX; Tue, 17 Oct 2006 07:33:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnCM-0000sl-ST
	for ipfix@ietf.org; Tue, 17 Oct 2006 07:33:30 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnCL-000376-HO
	for ipfix@ietf.org; Tue, 17 Oct 2006 07:33:30 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 17 Oct 2006 13:33:25 +0200
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.20060308/8.12.11) with ESMTP id
	k9HBXOA4015616; Tue, 17 Oct 2006 13:33:24 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HBXMmd004580; 
	Tue, 17 Oct 2006 13:33:22 +0200 (MEST)
Received: from [144.254.153.44] (dhcp-144-254-153-44.cisco.com
	[144.254.153.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA02583;
	Tue, 17 Oct 2006 12:33:21 +0100 (BST)
Message-ID: <4534BF81.9040906@cisco.com>
Date: Tue, 17 Oct 2006 12:33:21 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp>
In-Reply-To: <4534321E.9000300@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2053; t=1161084804; x=1161948804;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=AO5/ItV/WkOxn3gKs2PUE/eglHWrR3XN3Q6XaMNIebOcXTNWEyqPKQExy2NRWP4VaXCDo2oq
	Gc1HXu617hEuRxYVpP0uU4gdeR8wif9W+eikXiWGW7DG1+2JA1rlRFSN;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> I understand use of flowStartMilliseconds and flowEndMilliseconds is 
> suitable for the situation that exporter runs longer than 50 days.
> So, I will not argue to extend sysuptime to 64 bit.
> 
> But, I still have a question. Don't flowStartSysUpTime and 
> flowEnsSysUpTime support to represent longer than 50 days since device 
> booted?

Well, they wrap around at 50 days.

I looked at the SNMP definition for sysUpTime. It has SYNTAX TimeTicks, 
which is 0..4294967295 ie it's a 32 bit number. So the IPFIX definition 
is in keeping with this.


> If they can represent only shorter than 50 days since device booted, 
> they are not realistic, because routers which are typical IPFIX 
> exporters have to run longer than 50 days.

Agreed. That's one reason that I don't recommend their use in IPFIX.


> If systemInitTimeMilliseconds is updated to new absolute timestamp to 
> represent longer than 50 days whenever counters of sysUpTime overflow. 
> Is it correct?

No. Not unless the system reboots.


> If it is correct, I think that systemInitTimeMilliseconds 
> is not initialize timestamp, it is just absolute base time for 
> flowStartMilliseconds and flowEndMilliseconds. This behavior is 
> different from description of systemInitTimeMilliseconds. I think it is 
> better to change the name or description of systemInitTimeMilliseconds, 
> or create a new Information Element to represent base time for 
> sysuptime, for example sysUpBaseTimeMilliseconds (It is similar to 
> Brian's suggestion at 5th Oct).

So I see several things we could do:


1. Increase sysuptimes to 64 bits.

    - I don't favour this solution: it's not efficient,
      and it's contrary to SNMP


2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.

    - I could be OK with this.


3. Do something else.

    - Any suggestions?


4. Do nothing.

    - No change; just recommend using absolute timestamps.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Tue Oct 17 07:35:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZnCO-0000sq-AX; Tue, 17 Oct 2006 07:33:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnCM-0000sl-ST
	for ipfix@ietf.org; Tue, 17 Oct 2006 07:33:30 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnCL-000376-HO
	for ipfix@ietf.org; Tue, 17 Oct 2006 07:33:30 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 17 Oct 2006 13:33:25 +0200
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.20060308/8.12.11) with ESMTP id
	k9HBXOA4015616; Tue, 17 Oct 2006 13:33:24 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HBXMmd004580; 
	Tue, 17 Oct 2006 13:33:22 +0200 (MEST)
Received: from [144.254.153.44] (dhcp-144-254-153-44.cisco.com
	[144.254.153.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA02583;
	Tue, 17 Oct 2006 12:33:21 +0100 (BST)
Message-ID: <4534BF81.9040906@cisco.com>
Date: Tue, 17 Oct 2006 12:33:21 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp>
In-Reply-To: <4534321E.9000300@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2053; t=1161084804; x=1161948804;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=AO5/ItV/WkOxn3gKs2PUE/eglHWrR3XN3Q6XaMNIebOcXTNWEyqPKQExy2NRWP4VaXCDo2oq
	Gc1HXu617hEuRxYVpP0uU4gdeR8wif9W+eikXiWGW7DG1+2JA1rlRFSN;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> I understand use of flowStartMilliseconds and flowEndMilliseconds is 
> suitable for the situation that exporter runs longer than 50 days.
> So, I will not argue to extend sysuptime to 64 bit.
> 
> But, I still have a question. Don't flowStartSysUpTime and 
> flowEnsSysUpTime support to represent longer than 50 days since device 
> booted?

Well, they wrap around at 50 days.

I looked at the SNMP definition for sysUpTime. It has SYNTAX TimeTicks, 
which is 0..4294967295 ie it's a 32 bit number. So the IPFIX definition 
is in keeping with this.


> If they can represent only shorter than 50 days since device booted, 
> they are not realistic, because routers which are typical IPFIX 
> exporters have to run longer than 50 days.

Agreed. That's one reason that I don't recommend their use in IPFIX.


> If systemInitTimeMilliseconds is updated to new absolute timestamp to 
> represent longer than 50 days whenever counters of sysUpTime overflow. 
> Is it correct?

No. Not unless the system reboots.


> If it is correct, I think that systemInitTimeMilliseconds 
> is not initialize timestamp, it is just absolute base time for 
> flowStartMilliseconds and flowEndMilliseconds. This behavior is 
> different from description of systemInitTimeMilliseconds. I think it is 
> better to change the name or description of systemInitTimeMilliseconds, 
> or create a new Information Element to represent base time for 
> sysuptime, for example sysUpBaseTimeMilliseconds (It is similar to 
> Brian's suggestion at 5th Oct).

So I see several things we could do:


1. Increase sysuptimes to 64 bits.

    - I don't favour this solution: it's not efficient,
      and it's contrary to SNMP


2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.

    - I could be OK with this.


3. Do something else.

    - Any suggestions?


4. Do nothing.

    - No change; just recommend using absolute timestamps.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Tue Oct 17 08:18:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZntd-0004HY-5R; Tue, 17 Oct 2006 08:18:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnsj-0003DB-Ko
	for ipfix@ietf.org; Tue, 17 Oct 2006 08:17:18 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnoj-0003ol-B0
	for ipfix@ietf.org; Tue, 17 Oct 2006 08:13:12 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD2EV005219; 
	Tue, 17 Oct 2006 21:13:02 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCD1uB010901; Tue, 17 Oct 2006 21:13:01 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD0eS010644; 
	Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD0eP021485; 
	Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCCxVQ012276; Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCCxkc012273; Tue, 17 Oct 2006 21:12:59 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCCuZH020154;
	Tue, 17 Oct 2006 21:12:59 +0900 (JST)
Message-ID: <4534C8C8.1080209@lab.ntt.co.jp>
Date: Tue, 17 Oct 2006 21:12:56 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
In-Reply-To: <4534BF81.9040906@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Paul,

Paul Aitken wrote:
> Hitoshi-san,
> 
>> I understand use of flowStartMilliseconds and flowEndMilliseconds is 
>> suitable for the situation that exporter runs longer than 50 days.
>> So, I will not argue to extend sysuptime to 64 bit.
>>
>> But, I still have a question. Don't flowStartSysUpTime and 
>> flowEnsSysUpTime support to represent longer than 50 days since device 
>> booted?
> 
> Well, they wrap around at 50 days.
> 
> I looked at the SNMP definition for sysUpTime. It has SYNTAX TimeTicks, 
> which is 0..4294967295 ie it's a 32 bit number. So the IPFIX definition 
> is in keeping with this.
> 
> 
>> If they can represent only shorter than 50 days since device booted, 
>> they are not realistic, because routers which are typical IPFIX 
>> exporters have to run longer than 50 days.
> 
> Agreed. That's one reason that I don't recommend their use in IPFIX.
> 
> 
>> If systemInitTimeMilliseconds is updated to new absolute timestamp to 
>> represent longer than 50 days whenever counters of sysUpTime overflow. 
>> Is it correct?
> 
> No. Not unless the system reboots.
> 
> 
>> If it is correct, I think that systemInitTimeMilliseconds is not 
>> initialize timestamp, it is just absolute base time for 
>> flowStartMilliseconds and flowEndMilliseconds. This behavior is 
>> different from description of systemInitTimeMilliseconds. I think it 
>> is better to change the name or description of 
>> systemInitTimeMilliseconds, or create a new Information Element to 
>> represent base time for sysuptime, for example 
>> sysUpBaseTimeMilliseconds (It is similar to Brian's suggestion at 5th 
>> Oct).
> 
> So I see several things we could do:
> 
> 
> 1. Increase sysuptimes to 64 bits.
> 
>    - I don't favour this solution: it's not efficient,
>      and it's contrary to SNMP
> 
> 
> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
> 
>    - I could be OK with this.
> 
> 
> 3. Do something else.
> 
>    - Any suggestions?


   Keep systemInitTimeMilliseconds and create sysUpBaseTimeMilliseconds
      - meaning of base time for sysUpTime Information Elements is
        different from meaning of initial time,
        so I prefer creating a new IE, if there is no problems to create
        a new IE.


> 4. Do nothing.
> 
>    - No change; just recommend using absolute timestamps.
> 

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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



From ipfix-bounces@ietf.org Tue Oct 17 08:18:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZntd-0004HY-5R; Tue, 17 Oct 2006 08:18:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnsj-0003DB-Ko
	for ipfix@ietf.org; Tue, 17 Oct 2006 08:17:18 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnoj-0003ol-B0
	for ipfix@ietf.org; Tue, 17 Oct 2006 08:13:12 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD2EV005219; 
	Tue, 17 Oct 2006 21:13:02 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCD1uB010901; Tue, 17 Oct 2006 21:13:01 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD0eS010644; 
	Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCD0eP021485; 
	Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCCxVQ012276; Tue, 17 Oct 2006 21:13:00 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9HCCxkc012273; Tue, 17 Oct 2006 21:12:59 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9HCCuZH020154;
	Tue, 17 Oct 2006 21:12:59 +0900 (JST)
Message-ID: <4534C8C8.1080209@lab.ntt.co.jp>
Date: Tue, 17 Oct 2006 21:12:56 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
In-Reply-To: <4534BF81.9040906@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Paul,

Paul Aitken wrote:
> Hitoshi-san,
> 
>> I understand use of flowStartMilliseconds and flowEndMilliseconds is 
>> suitable for the situation that exporter runs longer than 50 days.
>> So, I will not argue to extend sysuptime to 64 bit.
>>
>> But, I still have a question. Don't flowStartSysUpTime and 
>> flowEnsSysUpTime support to represent longer than 50 days since device 
>> booted?
> 
> Well, they wrap around at 50 days.
> 
> I looked at the SNMP definition for sysUpTime. It has SYNTAX TimeTicks, 
> which is 0..4294967295 ie it's a 32 bit number. So the IPFIX definition 
> is in keeping with this.
> 
> 
>> If they can represent only shorter than 50 days since device booted, 
>> they are not realistic, because routers which are typical IPFIX 
>> exporters have to run longer than 50 days.
> 
> Agreed. That's one reason that I don't recommend their use in IPFIX.
> 
> 
>> If systemInitTimeMilliseconds is updated to new absolute timestamp to 
>> represent longer than 50 days whenever counters of sysUpTime overflow. 
>> Is it correct?
> 
> No. Not unless the system reboots.
> 
> 
>> If it is correct, I think that systemInitTimeMilliseconds is not 
>> initialize timestamp, it is just absolute base time for 
>> flowStartMilliseconds and flowEndMilliseconds. This behavior is 
>> different from description of systemInitTimeMilliseconds. I think it 
>> is better to change the name or description of 
>> systemInitTimeMilliseconds, or create a new Information Element to 
>> represent base time for sysuptime, for example 
>> sysUpBaseTimeMilliseconds (It is similar to Brian's suggestion at 5th 
>> Oct).
> 
> So I see several things we could do:
> 
> 
> 1. Increase sysuptimes to 64 bits.
> 
>    - I don't favour this solution: it's not efficient,
>      and it's contrary to SNMP
> 
> 
> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
> 
>    - I could be OK with this.
> 
> 
> 3. Do something else.
> 
>    - Any suggestions?


   Keep systemInitTimeMilliseconds and create sysUpBaseTimeMilliseconds
      - meaning of base time for sysUpTime Information Elements is
        different from meaning of initial time,
        so I prefer creating a new IE, if there is no problems to create
        a new IE.


> 4. Do nothing.
> 
>    - No change; just recommend using absolute timestamps.
> 

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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



From ipfix-bounces@ietf.org Tue Oct 17 10:37:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZq3u-0007w7-Hv; Tue, 17 Oct 2006 10:36:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq3s-0007vA-RL
	for ipfix@ietf.org; Tue, 17 Oct 2006 10:36:56 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZq3R-0007cy-Og
	for ipfix@ietf.org; Tue, 17 Oct 2006 10:36:56 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9HEaNbR019205 for ; Tue, 17 Oct 2006 10:36:25 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9HEYNHH019064
	for ; Tue, 17 Oct 2006 10:34:23 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9HEYNHO019061;
	Tue, 17 Oct 2006 10:34:23 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-31.remote.cert.org [10.25.4.31])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9HEYNsL012563; Tue, 17 Oct 2006 10:34:23 -0400
In-Reply-To: <4534C8C8.1080209@lab.ntt.co.jp>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Tue, 17 Oct 2006 10:33:48 -0400
To: Hitoshi Irino 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

On Oct 17, 2006, at 8:12 AM, Hitoshi Irino wrote:

> Dear Paul,
>
> Paul Aitken wrote:
>> Hitoshi-san,
>>>
>> So I see several things we could do:
>> 1. Increase sysuptimes to 64 bits.
>>    - I don't favour this solution: it's not efficient,
>>      and it's contrary to SNMP
>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>    - I could be OK with this.

I agree with Hitoshi-san (as below) -- if the argument for having  
systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for  
parallelism with SNMP (an argument I agree with... now), we probably  
don't want to change the meaning, because a sysUpBaseTimeMilliseconds  
IE would be subtly different than the present SMTP-derived  
definition. If we want adjustable base time not tied to restart, it  
should be a new IE (of course, now we need conflict resolution rules  
should both systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  
be present and valid...)

>> 3. Do something else.
>>    - Any suggestions?
>
>
>   Keep systemInitTimeMilliseconds and create sysUpBaseTimeMilliseconds
>      - meaning of base time for sysUpTime Information Elements is
>        different from meaning of initial time,
>        so I prefer creating a new IE, if there is no problems to  
> create
>        a new IE.
>
>
>> 4. Do nothing.
>>    - No change; just recommend using absolute timestamps.

We should do this _anyway_ ... the proliferation of timestamp IEs and  
formats (32-bit sec from epoch, 64-bit msec from epoch, NTP-style, 32- 
bit negative usec from export) is, I think, confusing to implementors  
(and is presently the most complex construct in the "universal" IPFIX  
import code in our own Collecting Process). I understand the  
compatibility reasons for supporting multiple timestamp IEs,  
especially as it is important to accommodate the variety of exporting  
process designs out there... but perhaps we should make  
recommendations as to which to use for export in the absence of other  
considerations.

(Personally, I'd recommend absolute timestamps all the way, further  
pointing out that only flow{Start,End}Milliseconds are immune from  
the Y2038 problem, if anyone cares to build exporting processes with  
a thirty-year service lifetime)

Cheers,

Brian

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



From ipfix-bounces@ietf.org Tue Oct 17 10:37:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZq3u-0007w7-Hv; Tue, 17 Oct 2006 10:36:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq3s-0007vA-RL
	for ipfix@ietf.org; Tue, 17 Oct 2006 10:36:56 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZq3R-0007cy-Og
	for ipfix@ietf.org; Tue, 17 Oct 2006 10:36:56 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9HEaNbR019205 for ; Tue, 17 Oct 2006 10:36:25 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9HEYNHH019064
	for ; Tue, 17 Oct 2006 10:34:23 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9HEYNHO019061;
	Tue, 17 Oct 2006 10:34:23 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-31.remote.cert.org [10.25.4.31])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9HEYNsL012563; Tue, 17 Oct 2006 10:34:23 -0400
In-Reply-To: <4534C8C8.1080209@lab.ntt.co.jp>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Tue, 17 Oct 2006 10:33:48 -0400
To: Hitoshi Irino 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

On Oct 17, 2006, at 8:12 AM, Hitoshi Irino wrote:

> Dear Paul,
>
> Paul Aitken wrote:
>> Hitoshi-san,
>>>
>> So I see several things we could do:
>> 1. Increase sysuptimes to 64 bits.
>>    - I don't favour this solution: it's not efficient,
>>      and it's contrary to SNMP
>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>    - I could be OK with this.

I agree with Hitoshi-san (as below) -- if the argument for having  
systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for  
parallelism with SNMP (an argument I agree with... now), we probably  
don't want to change the meaning, because a sysUpBaseTimeMilliseconds  
IE would be subtly different than the present SMTP-derived  
definition. If we want adjustable base time not tied to restart, it  
should be a new IE (of course, now we need conflict resolution rules  
should both systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  
be present and valid...)

>> 3. Do something else.
>>    - Any suggestions?
>
>
>   Keep systemInitTimeMilliseconds and create sysUpBaseTimeMilliseconds
>      - meaning of base time for sysUpTime Information Elements is
>        different from meaning of initial time,
>        so I prefer creating a new IE, if there is no problems to  
> create
>        a new IE.
>
>
>> 4. Do nothing.
>>    - No change; just recommend using absolute timestamps.

We should do this _anyway_ ... the proliferation of timestamp IEs and  
formats (32-bit sec from epoch, 64-bit msec from epoch, NTP-style, 32- 
bit negative usec from export) is, I think, confusing to implementors  
(and is presently the most complex construct in the "universal" IPFIX  
import code in our own Collecting Process). I understand the  
compatibility reasons for supporting multiple timestamp IEs,  
especially as it is important to accommodate the variety of exporting  
process designs out there... but perhaps we should make  
recommendations as to which to use for export in the absence of other  
considerations.

(Personally, I'd recommend absolute timestamps all the way, further  
pointing out that only flow{Start,End}Milliseconds are immune from  
the Y2038 problem, if anyone cares to build exporting processes with  
a thirty-year service lifetime)

Cheers,

Brian

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



From ipfix-bounces@ietf.org Tue Oct 17 11:56:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZrHz-0008Iw-0L; Tue, 17 Oct 2006 11:55:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrHx-0008Gm-Jx
	for ipfix@ietf.org; Tue, 17 Oct 2006 11:55:33 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrHv-0007eJ-8X
	for ipfix@ietf.org; Tue, 17 Oct 2006 11:55:33 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 17 Oct 2006 17:55:32 +0200
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.20060308/8.12.11) with ESMTP id
	k9HFtT38027402; Tue, 17 Oct 2006 17:55:29 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HFtSmd018660; 
	Tue, 17 Oct 2006 17:55:28 +0200 (MEST)
Received: from [144.254.153.44] (dhcp-144-254-153-44.cisco.com
	[144.254.153.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29132;
	Tue, 17 Oct 2006 16:55:27 +0100 (BST)
Message-ID: <4534FCEF.2020807@cisco.com>
Date: Tue, 17 Oct 2006 16:55:27 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
In-Reply-To: <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2222; t=1161100529; x=1161964529;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=LBPnYUq3nLTVE7YurbHFqhcQ21nuLgAYhu4AIKNqzPbvDY0qTSTHdh55SIVwcosVQj19y1uh
	IEbQ8hy0EyzyC4vPQax0ImFJ6GSiJGth6QCvLmV++KTijh1SMmFXl/KL;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

>>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>>    - I could be OK with this.
> 
> 
> I agree with Hitoshi-san (as below) -- if the argument for having  
> systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for  
> parallelism with SNMP (an argument I agree with... now), we probably  
> don't want to change the meaning, because a sysUpBaseTimeMilliseconds  
> IE would be subtly different than the present SMTP-derived  definition. 

I think the original reason for the systemInitTimeMilliseconds IE was as 
the base time for the sysuptime IEs, since this wasn't provided in the 
IPFIX header.

If it's only ever going to be used for that reason, then I'd not be 
unhappy about renaming it to sysUpBaseTimeMilliseconds.

However, if we perceive that the systemInitTime might be useful in its 
own right, then we should keep it and create a new IE.


> (of course, now we need conflict resolution rules  should both 
> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present and 
> valid...)

Since your sysuptimes might be referenced to an updated 
sysUpBaseTimeMilliseconds, that's what you must use and not 
systemInitTimeMilliseconds.


> the proliferation of timestamp IEs and  
> formats (32-bit sec from epoch, 64-bit msec from epoch, NTP-style, 32- 
> bit negative usec from export) is, I think, confusing to implementors  
> (and is presently the most complex construct in the "universal" IPFIX  
> import code in our own Collecting Process). I understand the  
> compatibility reasons for supporting multiple timestamp IEs,  especially 
> as it is important to accommodate the variety of exporting  process 
> designs out there... but perhaps we should make  recommendations as to 
> which to use for export in the absence of other  considerations.

Implimentation guidelines?


> (Personally, I'd recommend absolute timestamps all the way, further  
> pointing out that only flow{Start,End}Milliseconds are immune from  the 
> Y2038 problem, if anyone cares to build exporting processes with  a 
> thirty-year service lifetime)

IG again :-)

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Tue Oct 17 11:56:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZrHz-0008Iw-0L; Tue, 17 Oct 2006 11:55:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrHx-0008Gm-Jx
	for ipfix@ietf.org; Tue, 17 Oct 2006 11:55:33 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrHv-0007eJ-8X
	for ipfix@ietf.org; Tue, 17 Oct 2006 11:55:33 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 17 Oct 2006 17:55:32 +0200
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.20060308/8.12.11) with ESMTP id
	k9HFtT38027402; Tue, 17 Oct 2006 17:55:29 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HFtSmd018660; 
	Tue, 17 Oct 2006 17:55:28 +0200 (MEST)
Received: from [144.254.153.44] (dhcp-144-254-153-44.cisco.com
	[144.254.153.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29132;
	Tue, 17 Oct 2006 16:55:27 +0100 (BST)
Message-ID: <4534FCEF.2020807@cisco.com>
Date: Tue, 17 Oct 2006 16:55:27 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
In-Reply-To: <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2222; t=1161100529; x=1161964529;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=LBPnYUq3nLTVE7YurbHFqhcQ21nuLgAYhu4AIKNqzPbvDY0qTSTHdh55SIVwcosVQj19y1uh
	IEbQ8hy0EyzyC4vPQax0ImFJ6GSiJGth6QCvLmV++KTijh1SMmFXl/KL;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Brian,

>>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>>    - I could be OK with this.
> 
> 
> I agree with Hitoshi-san (as below) -- if the argument for having  
> systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for  
> parallelism with SNMP (an argument I agree with... now), we probably  
> don't want to change the meaning, because a sysUpBaseTimeMilliseconds  
> IE would be subtly different than the present SMTP-derived  definition. 

I think the original reason for the systemInitTimeMilliseconds IE was as 
the base time for the sysuptime IEs, since this wasn't provided in the 
IPFIX header.

If it's only ever going to be used for that reason, then I'd not be 
unhappy about renaming it to sysUpBaseTimeMilliseconds.

However, if we perceive that the systemInitTime might be useful in its 
own right, then we should keep it and create a new IE.


> (of course, now we need conflict resolution rules  should both 
> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present and 
> valid...)

Since your sysuptimes might be referenced to an updated 
sysUpBaseTimeMilliseconds, that's what you must use and not 
systemInitTimeMilliseconds.


> the proliferation of timestamp IEs and  
> formats (32-bit sec from epoch, 64-bit msec from epoch, NTP-style, 32- 
> bit negative usec from export) is, I think, confusing to implementors  
> (and is presently the most complex construct in the "universal" IPFIX  
> import code in our own Collecting Process). I understand the  
> compatibility reasons for supporting multiple timestamp IEs,  especially 
> as it is important to accommodate the variety of exporting  process 
> designs out there... but perhaps we should make  recommendations as to 
> which to use for export in the absence of other  considerations.

Implimentation guidelines?


> (Personally, I'd recommend absolute timestamps all the way, further  
> pointing out that only flow{Start,End}Milliseconds are immune from  the 
> Y2038 problem, if anyone cares to build exporting processes with  a 
> thirty-year service lifetime)

IG again :-)

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Tue Oct 17 12:01:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZrO3-0004jl-LJ; Tue, 17 Oct 2006 12:01:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrO2-0004ie-Kk
	for ipfix@ietf.org; Tue, 17 Oct 2006 12:01:50 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrO1-0008S2-BZ
	for ipfix@ietf.org; Tue, 17 Oct 2006 12:01:50 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9HG1fiP008599 for ; Tue, 17 Oct 2006 12:01:45 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9HG0wmg006400
	for ; Tue, 17 Oct 2006 12:00:58 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9HG0vqP006398;
	Tue, 17 Oct 2006 12:00:58 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-31.remote.cert.org [10.25.4.31])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9HG0vON025570; Tue, 17 Oct 2006 12:00:57 -0400
In-Reply-To: <4534FCEF.2020807@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Tue, 17 Oct 2006 12:00:23 -0400
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


On Oct 17, 2006, at 11:55 AM, Paul Aitken wrote:

> Brian,
>
>>>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>>>    - I could be OK with this.
>> I agree with Hitoshi-san (as below) -- if the argument for having   
>> systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for   
>> parallelism with SNMP (an argument I agree with... now), we  
>> probably  don't want to change the meaning, because a  
>> sysUpBaseTimeMilliseconds  IE would be subtly different than the  
>> present SMTP-derived  definition.
>
> I think the original reason for the systemInitTimeMilliseconds IE  
> was as the base time for the sysuptime IEs, since this wasn't  
> provided in the IPFIX header.
>
> If it's only ever going to be used for that reason, then I'd not be  
> unhappy about renaming it to sysUpBaseTimeMilliseconds.
>
> However, if we perceive that the systemInitTime might be useful in  
> its own right, then we should keep it and create a new IE.

I can see it being useful, as a sideband method for measuring the  
health of the measurement infrastructure itself ("hey, why'd the  
router reboot yesterday?")... Of course, this is a system management  
problem and on its own is out of scope for IPFIX, I think, but it  
could explain e.g. outages in the data (no data for a while followed  
by an updated init time => router outage as opposed to network outage).

>> (of course, now we need conflict resolution rules  should both  
>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be  
>> present and valid...)
>
> Since your sysuptimes might be referenced to an updated  
> sysUpBaseTimeMilliseconds, that's what you must use and not  
> systemInitTimeMilliseconds.

indeed; just pointing out that we'll need to note this in the  
Description of both IEs.

>
>> the proliferation of timestamp IEs and  formats (32-bit sec from  
>> epoch, 64-bit msec from epoch, NTP-style, 32- bit negative usec  
>> from export) is, I think, confusing to implementors  (and is  
>> presently the most complex construct in the "universal" IPFIX   
>> import code in our own Collecting Process). I understand the   
>> compatibility reasons for supporting multiple timestamp IEs,   
>> especially as it is important to accommodate the variety of  
>> exporting  process designs out there... but perhaps we should  
>> make  recommendations as to which to use for export in the absence  
>> of other  considerations.
>
> Implimentation guidelines?
>
>
>> (Personally, I'd recommend absolute timestamps all the way,  
>> further  pointing out that only flow{Start,End}Milliseconds are  
>> immune from  the Y2038 problem, if anyone cares to build exporting  
>> processes with  a thirty-year service lifetime)
>
> IG again :-)

Indeed on both points. I'll throw together some language...




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



From ipfix-bounces@ietf.org Tue Oct 17 12:01:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZrO3-0004jl-LJ; Tue, 17 Oct 2006 12:01:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrO2-0004ie-Kk
	for ipfix@ietf.org; Tue, 17 Oct 2006 12:01:50 -0400
Received: from franclinus.red.cert.org ([192.88.209.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrO1-0008S2-BZ
	for ipfix@ietf.org; Tue, 17 Oct 2006 12:01:50 -0400
Received: from franclinus.red.cert.org (localhost [127.0.0.1])
	by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9HG1fiP008599 for ; Tue, 17 Oct 2006 12:01:45 -0400
Received: (from defang@localhost)
	by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9HG0wmg006400
	for ; Tue, 17 Oct 2006 12:00:58 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by franclinus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9HG0vqP006398;
	Tue, 17 Oct 2006 12:00:58 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-31.remote.cert.org [10.25.4.31])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9HG0vON025570; Tue, 17 Oct 2006 12:00:57 -0400
In-Reply-To: <4534FCEF.2020807@cisco.com>
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
Date: Tue, 17 Oct 2006 12:00:23 -0400
To: Paul Aitken 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


On Oct 17, 2006, at 11:55 AM, Paul Aitken wrote:

> Brian,
>
>>>> 2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.
>>>>    - I could be OK with this.
>> I agree with Hitoshi-san (as below) -- if the argument for having   
>> systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for   
>> parallelism with SNMP (an argument I agree with... now), we  
>> probably  don't want to change the meaning, because a  
>> sysUpBaseTimeMilliseconds  IE would be subtly different than the  
>> present SMTP-derived  definition.
>
> I think the original reason for the systemInitTimeMilliseconds IE  
> was as the base time for the sysuptime IEs, since this wasn't  
> provided in the IPFIX header.
>
> If it's only ever going to be used for that reason, then I'd not be  
> unhappy about renaming it to sysUpBaseTimeMilliseconds.
>
> However, if we perceive that the systemInitTime might be useful in  
> its own right, then we should keep it and create a new IE.

I can see it being useful, as a sideband method for measuring the  
health of the measurement infrastructure itself ("hey, why'd the  
router reboot yesterday?")... Of course, this is a system management  
problem and on its own is out of scope for IPFIX, I think, but it  
could explain e.g. outages in the data (no data for a while followed  
by an updated init time => router outage as opposed to network outage).

>> (of course, now we need conflict resolution rules  should both  
>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be  
>> present and valid...)
>
> Since your sysuptimes might be referenced to an updated  
> sysUpBaseTimeMilliseconds, that's what you must use and not  
> systemInitTimeMilliseconds.

indeed; just pointing out that we'll need to note this in the  
Description of both IEs.

>
>> the proliferation of timestamp IEs and  formats (32-bit sec from  
>> epoch, 64-bit msec from epoch, NTP-style, 32- bit negative usec  
>> from export) is, I think, confusing to implementors  (and is  
>> presently the most complex construct in the "universal" IPFIX   
>> import code in our own Collecting Process). I understand the   
>> compatibility reasons for supporting multiple timestamp IEs,   
>> especially as it is important to accommodate the variety of  
>> exporting  process designs out there... but perhaps we should  
>> make  recommendations as to which to use for export in the absence  
>> of other  considerations.
>
> Implimentation guidelines?
>
>
>> (Personally, I'd recommend absolute timestamps all the way,  
>> further  pointing out that only flow{Start,End}Milliseconds are  
>> immune from  the Y2038 problem, if anyone cares to build exporting  
>> processes with  a thirty-year service lifetime)
>
> IG again :-)

Indeed on both points. I'll throw together some language...




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



From ipfix-bounces@ietf.org Wed Oct 18 15:52:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHRb-0002XZ-RC; Wed, 18 Oct 2006 15:51:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHQS-00011p-A5; Wed, 18 Oct 2006 15:50:04 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GaHQQ-0003n7-Rp; Wed, 18 Oct 2006 15:50:04 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8798932890;
	Wed, 18 Oct 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GaHQQ-0001Th-Ch; Wed, 18 Oct 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 18 Oct 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-testing-00.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: IP Flow Information eXport (IPFIX) Testing
	Author(s)	: C. Schmoll, P. Aitken
	Filename	: draft-ietf-ipfix-testing-00.txt
	Pages		: 20
	Date		: 2006-10-18
	

   This document presents a list of tests which implementers of IP Flow
   Information Export (IPFIX) compliant systems are encouraged to
   perform on their IPFIX system.  This document has been created to
   help implementers test the functionality of their IPFIX Exporter
   and/or Collector.  The goal of these tests is to ensure that all
   important functions are covered by tests and thereby to gain a level
   of confidence in the system which allows the implementer to perform
   interoperability or plug tests with other IPFIX systems.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-testing-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-testing-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-testing-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-18124652.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-testing-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-testing-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-18124652.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--





From ipfix-bounces@ietf.org Wed Oct 18 15:52:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHRb-0002XZ-RC; Wed, 18 Oct 2006 15:51:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHQS-00011p-A5; Wed, 18 Oct 2006 15:50:04 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GaHQQ-0003n7-Rp; Wed, 18 Oct 2006 15:50:04 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8798932890;
	Wed, 18 Oct 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GaHQQ-0001Th-Ch; Wed, 18 Oct 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 18 Oct 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-testing-00.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: IP Flow Information eXport (IPFIX) Testing
	Author(s)	: C. Schmoll, P. Aitken
	Filename	: draft-ietf-ipfix-testing-00.txt
	Pages		: 20
	Date		: 2006-10-18
	

   This document presents a list of tests which implementers of IP Flow
   Information Export (IPFIX) compliant systems are encouraged to
   perform on their IPFIX system.  This document has been created to
   help implementers test the functionality of their IPFIX Exporter
   and/or Collector.  The goal of these tests is to ensure that all
   important functions are covered by tests and thereby to gain a level
   of confidence in the system which allows the implementer to perform
   interoperability or plug tests with other IPFIX systems.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-testing-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-testing-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-testing-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-18124652.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-testing-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-testing-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-18124652.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--





From ipfix-bounces@ietf.org Wed Oct 18 22:23:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNXK-0001X2-Uz; Wed, 18 Oct 2006 22:21:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXI-0001UZ-RN
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:21:32 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNV6-0000cx-LH
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:19:21 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 520782000293
	for ; Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09983-04 for ;
	Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 335DC2000168
	for ; Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 19 Oct 2006 04:19:05 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrg==
From: "Thomas Dietz" 
To: 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Subject: [IPFIX] Should the IPFIX MIB be writeable?
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1492749373=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1492749373==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0047_01C6F335.B6ADD660"

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C6F335.B6ADD660
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de

------=_NextPart_000_0047_01C6F335.B6ADD660
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MDIx
OTA1WjAjBgkqhkiG9w0BCQQxFgQULb5ir049ASf7yIkklHh+Z2B+qBUwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBACdXoLrlPmrKPRYInMSaPywc
yNscPHJBmr9B3snnIBZPRrdQ1hWjOnMcnjZwp0C2FI2meNAgSaoxobrlQAX1LTfK+w8J/7fJEm4c
m7RZk5ye5uI18lYQWFPAG0GXxMRf8HTjkLo5VHtDx3kcOaGaHqSaa7+vylpHEL/0MwXsn93E4UXu
1D8BkcZbFt79JIzA5iEt5M43AIShT7USTuvEP2yv5eLMS0elLnbKDna+/GuQ2+0SuvJ0mVHjZ30H
oD5/L0BCOS6iXEioC5MUb2EeiuSBmuVhlCVHWSwBjQcAD6sZGdCVXEauJ2gViJplMoCdT4xHiJqQ
svLygNMdI1PvAiUAAAAAAAA=

------=_NextPart_000_0047_01C6F335.B6ADD660--


--===============1492749373==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1492749373==--




From ipfix-bounces@ietf.org Wed Oct 18 22:23:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNXK-0001X2-Uz; Wed, 18 Oct 2006 22:21:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXI-0001UZ-RN
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:21:32 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNV6-0000cx-LH
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:19:21 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 520782000293
	for ; Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09983-04 for ;
	Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 335DC2000168
	for ; Thu, 19 Oct 2006 04:19:46 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 19 Oct 2006 04:19:05 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrg==
From: "Thomas Dietz" 
To: 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Subject: [IPFIX] Should the IPFIX MIB be writeable?
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1492749373=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1492749373==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0047_01C6F335.B6ADD660"

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C6F335.B6ADD660
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de

------=_NextPart_000_0047_01C6F335.B6ADD660
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MDIx
OTA1WjAjBgkqhkiG9w0BCQQxFgQULb5ir049ASf7yIkklHh+Z2B+qBUwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBACdXoLrlPmrKPRYInMSaPywc
yNscPHJBmr9B3snnIBZPRrdQ1hWjOnMcnjZwp0C2FI2meNAgSaoxobrlQAX1LTfK+w8J/7fJEm4c
m7RZk5ye5uI18lYQWFPAG0GXxMRf8HTjkLo5VHtDx3kcOaGaHqSaa7+vylpHEL/0MwXsn93E4UXu
1D8BkcZbFt79JIzA5iEt5M43AIShT7USTuvEP2yv5eLMS0elLnbKDna+/GuQ2+0SuvJ0mVHjZ30H
oD5/L0BCOS6iXEioC5MUb2EeiuSBmuVhlCVHWSwBjQcAD6sZGdCVXEauJ2gViJplMoCdT4xHiJqQ
svLygNMdI1PvAiUAAAAAAAA=

------=_NextPart_000_0047_01C6F335.B6ADD660--


--===============1492749373==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1492749373==--




From ipfix-bounces@ietf.org Wed Oct 18 22:25:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNau-0003Qg-8n; Wed, 18 Oct 2006 22:25:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXv-0001pR-FD
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:22:11 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNJY-0006zI-Mj
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:07:25 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 580CB2000293;
	Thu, 19 Oct 2006 04:07:48 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09813-03; Thu, 19 Oct 2006 04:07:48 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 000E32000168;
	Thu, 19 Oct 2006 04:07:47 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] IPFIX MIB review
Date: Thu, 19 Oct 2006 04:07:17 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4B80@mx1.office>
In-Reply-To: <4533D03B.80100@cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] IPFIX MIB review
Thread-Index: AcbxUx1FGf6FGjyeRJGzRVKxcuRV+AByRrog
From: "Thomas Dietz" 
To: "Benoit Claise" , 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b59fa031b49cd6123c8bacf4dacd587a
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0547193649=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0547193649==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_002C_01C6F331.0BCAE070"

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C6F331.0BCAE070
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002D_01C6F331.0BCAE070"


------=_NextPart_001_002D_01C6F331.0BCAE070
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Benoit,
 
find my comments inline

--
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 


 



  _____  

From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Monday, October 16, 2006 8:32 PM
To: ipfix@ietf.org
Subject: [IPFIX] IPFIX MIB review


Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I sent the editorial details directly to Thomas.
Feel free to start a new email thread with one of the point below.

1.  Section 3, IPFIX Documents Overview.

I would insert the second paragraph of section 2 at the end of this
section., once we have defined the IPFIX document overview. 
Otherwise, you defined twice the information.

2. Section 5, terminology
   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. are
   semantically identical with those found in the IPFIX requirements
   document [RFC3917].  
It might be better to reference [IPFIX-PROTO], which is a normative
reference anyway.
 

For comment 1 and 2 you are definetly right but I wanted to have the
sections there and to be filled even with a preliminary text. I agree we
need to update those sections after the work on the other documents is
finished.
 

 
3.  Section 6.1.1, the Reporting Group
"ipfixCollectorGroupTable contains only indexes " I don't understand what it
means
 

You have the list of collectors where you could send your flow reports. But
an exporter could export the same flow record to multiple collectors for
redundancy or whatever reason. So I defined the that table to group
collectors together and then reference an index of this table at the
instance to indicate where the instance reports to. I guess this answers
also question 5 below.

 

4. Section 6.1.2 the Instance Group

   The ipfixTemplateTable lists all data templates that are used by the
   IPFIX exporter.  It has two indices.  The first one is the template
   id and the second one is just a running index for the field ids
   listed in the table.  So the ipfixTemplateEntry.4.x will list all
   field ids used for template id 4 in the order given by x.

   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable."
       INDEX { ipfixTemplateId, ipfixTemplateIndex }
       ::= { ipfixTemplateTable 1 }

Is there no conflict with the new definition of the template Id in
[IPFIX-PROTO], as the templateId is unique per Transport Session?

      Template ID 

          Each of the newly generated Template Records is given a unique  

          Template ID.  This uniqueness is local to the Transport 

          Session and Observation Domain that generated the Template ID.  

          Template IDs 0-255 are reserved for Template Sets, Options 

          Template Sets, and other reserved Sets yet to be created.  



If a transport session restarts, then...

5.  -- Collector Group Table, ipfixCollectorGroupTable OBJECT-TYPE
I don't see what we gain with this group?
If this group contains several entries, are these multiple exports to all
the entries.
I think this group only makes sense if we defined the notion of backup
versus multiple versus load-balancing export in there.

6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, etc...
are read-write.
Shall we limit the read-only with the "Units of Conformance"?
 

I just opened a new thread to explain the problem here. We might want to
have a writeable MIB. So for now I will remove all row status and make all
object read-only. We need to take a decission on this topics first and then
start a dicusion (if we agree to make it writeable) which object and tables
should be writable and which not.

 
 
7. ipfixInstanceReportingProcessId 

   ipfixInstanceReportingProcessId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The process id of the reporting process used by this
            instance."
       ::= { ipfixInstanceEntry 10 }

There is no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not sure what this adds to the MIB.
 

Still a remainder from the old PSAMP MIB so i will delete this object.

 
 
Note that the editorial changes have been sent directly to Thomas.

8. ipfixInstancePacketsDropped 
   ipfixInstancePacketsDropped OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of packets dropped while filtering/sampling
            packets."
       ::= { ipfixInstanceEntry 8 }

This one should be part of the PSAMP MIB, right?
 

It is definitely used in PSAMP. So I should state that.

 
 
 
9. There is something missing. As defined in the CISCO NETFLOW MIB


NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION

    STATUS  current

    DESCRIPTION        "Defines different types of interface configuration."

    SYNTAX  INTEGER{

            interfaceDirNone(0),

            interfaceDirIngress(1),

            interfaceDirEgress(2),

            interfaceDirBoth(3)

    }



cnfCIInterfaceTable OBJECT-TYPE

    SYNTAX      SEQUENCE OF CnfCIInterfaceEntry

    MAX-ACCESS  not-accessible

    STATUS      current

    DESCRIPTION        "This table provides Netflow Enable information per
interface."

    ::= { cnfCacheInfo
  1 }



cnfCIInterfaceEntry OBJECT-TYPE

    SYNTAX     CnfCIInterfaceEntry

    MAX-ACCESS not-accessible

    STATUS     current

    DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry
 ."

    INDEX { ifIndex
  }

    ::= { cnfCIInterfaceTable
  1}



CnfCIInterfaceEntry ::= SEQUENCE {

        cnfCINetflowEnable

NfInterfaceDirectionTypes

     }

  
cnfCINetflowEnable OBJECT-TYPE

    SYNTAX      NfInterfaceDirectionTypes

    MAX-ACCESS  read-write

    STATUS      current

    DESCRIPTION        "Indicates whether the netflow feature is enabled for
this

         interface, and if so, in which directions."

    ::= { cnfCIInterfaceEntry
  1 }





  
 
Well, those object describe somehow the Observation Domain (if I am not
misleaded here).
So since the notion of Observation Domain is still missing in the MIB we
should place
this somewhere and somehow there.

 

10. Do we want to foresee the version already




  IpfixCollectorEntry ::= SEQUENCE {
           ipfixCollectorIndex             Integer32,
           ipfixCollectorDstIpAddressType  InetAddressType,
           ipfixCollectorDstIpAddress      InetAddress,
           ipfixCollectorDstProtocol       Integer32,
           ipfixCollectorDstPort           Integer32,
           ipfixCollectorReportsSent       Integer32,
           ipfixExportVersion               Integer32    ???????????????????
           ipfixCollectorRowStatus         RowStatus
       } 

Good point to add. 

 
 
11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
<--------------------------------------------------
       STATUS      current          
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it mean?
Can only deleted by SNMP? And not created?
 

Let's defer this discusion of how the access to different objects need to be
set to make them writeable until we made the basic desision (see above).

 
 
12. We would really need some examples of the instance and method chain
group
 

More than true.

 
 
13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:


cnfESExportRate OBJECT-TYPE

    SYNTAX     Counter32

    UNITS      "bytes per second"

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of Bytes exported per second."

    ::= { cnfExportStatistics
  2 }



cnfESRecordsExported OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of flow statistics
  records which were exported."

    ::= { cnfExportStatistics
  3 }



cnfESPktsExported OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of packets (udp datagrams) which were
exported."

    ::= { cnfExportStatistics
  4 }



cnfESPktsFailed OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of times a flow record could not be exported
because of

         a pak allocation failure."

    ::= { cnfExportStatistics
  5 }



cnfESPktsDropped OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of export packets which were dropped at the
time of

         ipwrite operation. The reasons for this failure are no FIB,

         adjacency failure, MTU failed, enqueue failed, IPC failed etc."

    ::= { cnfExportStatistics
  6 }

 
 



Fine! I now that statistics are a little underrepresented right now. Every
comment/addition in this regard is welcome. 

 
 Note: the collectExporterStatisTable  should be aligned with the stats on
the exporter. I mean: we should be able to compare the statistics on the
exporter and the collector.

Allignment of the two parts is an issue but it will take some time and I try
to carefully align the two part in the near future. 

 
    collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus







 14. collectExporterTable  

   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can configure on my Collector which
Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, simply
listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .

 

As state already several times above: deffered!

 
 
15. I think that we are missing the observation domain as an index in many
tables
Example: as the Template IDs are unique per Observation Domain,
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable 
On the other hand, I don't clearly understand the goal of
collectObservDomainStatisTable. Should we simply add the O.D.id to the
collectExporterStatisTable  and combine those stats?
 

Agreed here. The MIB doesn't reflect the recent dicisions on Observation
Domain and Session. So those need to be integrated where needed.
 
16. 
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the
collectExporterIndex enough? (next to the O.D.id: see point 16)

17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will always
be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and
collectTemplateStatisticsTable  

18. collectTemplateStatisticsTable  
Again, why is there a rowStatus in that table?

19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to display
how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session,
missing in the index.
 
Well you find the comments in Kobayashi-sans reply.
 

Regards, Benoit.
 
 
 

------=_NextPart_001_002D_01C6F331.0BCAE070
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Dear Benoit,


 


find my comments inline


--
Thomas=20
Dietz           &n=
bsp;          =20
E-mail: Thomas.Dietz@netlab.nec.de
Network=20
Laboratories          &=
nbsp;   =20
Phone:  +49 6221 4342-128
NEC Europe=20
Ltd.           &nb=
sp;       =20
Fax:    +49 6221 4342-155
Kurfuersten-Anlage =
36
69115=20
Heidelberg, =
Germany          http://www.netlab.nec.de


 



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Monday, October 16, 2006 8:32 PM
To:=20
  ipfix@ietf.org
Subject: [IPFIX] IPFIX MIB=20
review


  

  
Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I=20
  sent the editorial details directly to Thomas.
Feel free to start a =
new=20
  email thread with one of the point below.

1.  Section 3, =
IPFIX=20
  Documents Overview.

I would insert the second paragraph =
of=20
  section 2 at the end of this section., once we have defined the IPFIX =
document=20
  overview. 
Otherwise, you defined twice the=20
  information.

2. Section=20
  5, terminology
   The definitions of the =
basic terms=20
  like IP Traffic Flow, Exporting
  =20
  Process, Collecting Process, Observation Points, etc.=20
  are
   semantically identical =
with those=20
  found in the IPFIX requirements
  =20
  document [RFC3917].  
It might be better to =
reference=20
  [IPFIX-PROTO], which is a normative reference anyway.
 


For comment 1 and=20
2 you are definetly right but I wanted to have the sections there and to =
be=20
filled even with a preliminary text. I agree we need to update those =
sections=20
after the work on the other documents is=20
finished.


 


  
 
3.  Section 6.1.1, =
the=20
  Reporting Group
"ipfixCollectorGroupTable=20
  contains only indexes " I don't understand what it means
 


You have the list=20
of collectors where you could send your flow reports. But an exporter =
could=20
export the same flow record to multiple collectors for redundancy or =
whatever=20
reason. So I defined the that table to group collectors together and =
then=20
reference an index of this table at the instance to indicate where the =
instance=20
reports to. I guess this answers also question 5=20
below.


  
 

4. Section 6.1.2 the =
Instance=20
  Group

   The ipfixTemplateTable =
lists all=20
  data templates that are used by the
  =20
  IPFIX exporter.  It has two =
indices. =20
  The first one is the template
  =20
  id and the second one is just a running index for the field=20
  ids
   listed in the =
table. =20
  So the ipfixTemplateEntry.4.x will list=20
  all
   field ids used for =
template id 4=20
  in the order given by x.

   =
ipfixTemplateEntry=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
IpfixTemplateEntry
    &nb=
sp; =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "Defines an entry in the=20
  =
ipfixTemplateTable."
     &n=
bsp;=20
  INDEX { ipfixTemplateId, ipfixTemplateIndex=20
  }
       =
::=3D {=20
  ipfixTemplateTable 1 }

Is there no conflict with the =
new=20
  definition of the template Id in [IPFIX-PROTO], as the templateId is =
unique=20
  per Transport Session?
      Template ID=20
          Each of the newly generated Template Records is given a unique =
=20
          Template ID.  This uniqueness is local to the Transport=20
          Session and Observation Domain that generated the Template ID. =
=20
          Template IDs 0-255 are reserved for Template Sets, Options=20
          Template Sets, and other reserved Sets yet to be created. =20

If a transport session restarts, then...


  

5.  -- Collector Group Table,=20
  ipfixCollectorGroupTable =
OBJECT-TYPE
I =
don't see=20
  what we gain with this group?
If this group contains several =
entries, are=20
  these multiple exports to all the entries.
I think this group only =
makes=20
  sense if we defined the notion of backup versus multiple versus =
load-balancing=20
  export in there.

6. =
And again=20
  the discussion about read-write versus read-only.
ipfixCollectorTable,=20
  ipfixCollectorGroupTable,=20
  ipfixTemplateTable,=20
  etc... are read-write.
Shall we limit the read-only with the =
"Units of =
Conformance"?
 


I =
just opened a=20
new thread to explain the problem here. We might want to have a =
writeable MIB.=20
So for now I will remove all row status and make all object read-only. =
We need=20
to take a decission on this topics first and then start a dicusion (if =
we agree=20
to make it writeable) which object and tables should be writable and =
which=20
not.


  
 

  
 
7.=20
  ipfixInstanceReportingProcessId =


  =20
  ipfixInstanceReportingProcessId=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  =
read-only
      =
=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The process id of the reporting process used by=20
  =
this
        =
   =20
  =
instance."
      =
;=20
  ::=3D { ipfixInstanceEntry 10 }

There is no =
Reporting=20
  Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not =
sure what=20
  this adds to the MIB.
 


Still a remainder=20
from the old PSAMP MIB so i will delete this =
object.


  
 

  
 
Note that the editorial =
changes have=20
  been sent directly to Thomas.

8.=20
  ipfixInstancePacketsDropped 
   =

  ipfixInstancePacketsDropped=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  =
read-only
      =
=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The number of packets dropped while=20
  =
filtering/sampling
     &nbs=
p;     =20
  =
packets."
      =
=20
  ::=3D { ipfixInstanceEntry 8 }

This one =
should be=20
  part of the PSAMP MIB, right?
 


It is definitely=20
used in PSAMP. So I should state that.


  
 

  
 

  
 
9. There is something =
missing. As=20
  defined in the CISCO NETFLOW MIB

  
NfInterfaceDirectionTypes ::=3D =
TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION        "Defines different types =
of interface configuration."
    SYNTAX  INTEGER{
            interfaceDirNone(0),
            interfaceDirIngress(1),
            interfaceDirEgress(2),
            interfaceDirBoth(3)
    }

cnfCIInterfaceTable OBJECT-TYPE
    SYNTAX      SEQUENCE =
OF CnfCIInterfaceEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION        "This table provides =
Netflow Enable information per interface."
    ::=3D { cnfCacheInfo =
1 }

cnfCIInterfaceEntry OBJECT-TYPE
    SYNTAX     CnfCIInterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION        "A conceptual row in the =
cnfCIInter=
faceEntry."
    INDEX { ifIndex }
    ::=3D { cnfCIInter=
faceTable 1}

CnfCIInterfaceEntry ::=3D SEQUENCE {
        cnfCINetflo=
wEnable              NfInterfaceDirectionTypes
     }
  
cnfCINetflowEnable OBJECT-TYPE
    SYNTAX      =
NfInterfaceDirectionTypes
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION        "Indicates whether the =
netflow feature is enabled for this
         interface, and if so, in which directions."
    ::=3D { cnfCIInter=
faceEntry 1 }


  
 


Well, =
those object describe somehow the Observation Domain (if I am not =
misleaded here).
So =
since the notion of Observation Domain is still missing in the MIB we =
should place
this somewhere and somehow =
there.


 
10. Do we want to foresee the version already


  IpfixCollectorEntry ::=3D SEQUENCE=20
  =
{
        &nb=
sp; =20
  ipfixCollectorIndex      &n=
bsp;     =20
  Integer32,
         &nb=
sp;=20
  ipfixCollectorDstIpAddressType =20
  InetAddressType,
         &nb=
sp;=20
  ipfixCollectorDstIpAddress     =20
  InetAddress,
         &nb=
sp;=20
  =
ipfixCollectorDstProtocol      =
;=20
  Integer32,
         &nb=
sp;=20
  =
ipfixCollectorDstPort      &nb=
sp;   =20
  Integer32,
     =20
  =
     ipfixCollectorReportsSe=
nt      =20
  Integer32,
       =
   =20
  =
ipfixExportVersion         &=
nbsp;    =20
  Integer32    =
???????????????????
         &nb=
sp;=20
  =
ipfixCollectorRowStatus      &=
nbsp; =20
  RowStatus
       =
}=20

Good point to add. 


 
 


  
11. only ipfixTemplateRowStatus  is =
read-write in=20
  this table
 
  =20
  IpfixTemplateEntry ::=3D SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
ipfixTemplateId       &nb=
sp; =20
  =
Integer32,
      =
;    =20
  ipfixTemplateIndex      =20
  =
Integer32,
      =
;    =20
  ipfixTemplateFieldId    =20
  =
Integer32,
      =
;    =20
  ipfixTemplateRowStatus  =20
  =
RowStatus
      =
=20
  =
}
 
&=
nbsp; =20
  ipfixTemplateId=20
  OBJECT-TYPE
      =20
  SYNTAX      Integer32=20
  =
(1..2147483647)
       =

  MAX-ACCESS =20
  not-accessible       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The unique identifier for the=20
  template."
      =20
  =
REFERENCE
      =
    =20
  "draft-ietf-ipfix-sample-tech-04.txt, Section=20
  5.1"
   -- Editor Note: get =
reference=20
  right!
       =
::=3D {=20
  ipfixTemplateEntry 1 =
}
 
  =20
  ipfixTemplateIndex=20
  OBJECT-TYPE
      =20
  SYNTAX      Integer32=20
  =
(1..2147483647)
       =

  MAX-ACCESS =20
  not-accessible       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The locally arbitrary, but unique identifier of a field=20
  =
Id
        &n=
bsp;  =20
  in the template identified by=20
  =
ipfixTemplateId.
 
  &nb=
sp;        =20
  The value is expected to remain constant at least from=20
  =
one
        &=
nbsp;  =20
  re-initialization of the entity's network management=20
  =
system
       &nbs=
p;   =20
  to the next=20
  =
re-initialization."
     &nb=
sp;=20
  ::=3D { ipfixTemplateEntry 2=20
  }

  =
ipfixTemplateFieldId=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  read-only       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  current         =20
  
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The Field Id at position ipfixTemplateIndex in the=20
  =
template
       &n=
bsp;   =20
  ipfixTemplateId. This implicitly gives the data type=20
  =
and
        &=
nbsp;  =20
  state values that are=20
  exported."
      =20
  =
REFERENCE
      =
    =20
  "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO=20
  MODEL"
   -- Editor Note: get =
reference=20
  right!
       =
::=3D {=20
  ipfixTemplateEntry 3 =
}
 
  =20
  ipfixTemplateRowStatus=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
RowStatus
      =
=20
  MAX-ACCESS =20
  =
read-create
     &nbs=
p;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The status of this row of the=20
  table."
       =
::=3D {=20
  ipfixTemplateEntry 4 }

Only=20
  ipfixTemplateRowStatus  is read-write in this =
table.=20
  What does it mean? Can only deleted by SNMP? And not created?
 


Let's defer this discusion of how the access to different =
objects need to=20
be set to make them writeable until we made the basic desision (see=20
above).


  
 

  
 
12. We =
would really=20
  need some examples of the instance and method chain group
 


More than true.


  
 

  
 
13. In =
ipfixReporting, I=20
  really would like to see some stats.
Coming from the NetFlow=20
  MIB:

  
cnfESExportRate OBJECT-TYPE
    SYNTAX     Counter32
    UNITS      "bytes per second"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of Bytes =
exported per second."
    ::=3D { cnfExportS=
tatistics 2 }

cnfESRecordsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of flow statistics =
records which were exported."
    ::=3D { cnfExportS=
tatistics 3 }

cnfESPktsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of packets (udp =
datagrams) which were exported."
    ::=3D { cnfExportS=
tatistics 4 }

cnfESPktsFailed OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of times a flow =
record could not be exported because of
         a pak allocation failure."
    ::=3D { cnfExportS=
tatistics 5 }

cnfESPktsDropped OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of export =
packets which were dropped at the time of
         ipwrite operation. The reasons for this failure are no FIB,
         adjacency failure, MTU failed, enqueue failed, IPC failed =
etc."
    ::=3D { cnfExportS=
tatistics 6 }
 
 

Fine! I now that statistics are a little underrepresented right =
now. Every comment/addition in this regard is =
welcome. 


 
 Note: the =
collectExporterStatisTable  should be aligned with =
the stats on the exporter. I mean: we should be able to compare the =
statistics on the exporter and the collector.


Allignment of the two parts is an issue but it will take some =
time and I=20
try to carefully align the two part in the near=20
future. 


  
 

  
   =20
  collectExporterStatisEntry=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
CollectExporterStatisEntry
   &=
nbsp;  =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    "Defines=20
  an entry in the=20
  =
collectExporterStatisTable"
    &=
nbsp; =20
  INDEX {=20
  =
collectExporterIndex,
     &=
nbsp;        =20
  collectExporterDstPort=20
  =
}
     =
; =20
  ::=3D { collectExporterStatisTable 1=20
  }
 
  =20
  CollectExporterStatisEntry=20
  ::=3D
       =
SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
collectExporterDstPort      &n=
bsp;   =20
  =
Integer32,
      =
;    =20
  =
collectExporterProcessId      =
  =20
  =
Integer32,
      =
;    =20
  =
collectExporterRcdPackets      =
; =20
  =
Counter32,
      =
;    =20
  =
collectExporterRcdBytes      &=
nbsp;  =20
  =
Counter32,
      =
;    =20
  =
collectExporterRcdMessages     &nbs=
p;=20
  =
Counter32,
      =
;    =20
  collectExporterDiscardMessages  =20
  =
Counter32,
      =
;    =20
  =
collectSessionElapsedTime      =
; =20
  =
Gauge32,
      &=
nbsp;   =20
  =
collectExporterRcdFlows      &=
nbsp;  =20
  =
Counter32,
      =
;    =20
  collectExporterRcdTemplates      =

  =
Counter32,
      =
;    =20
  collectExporterStatisRowStatus  =20
  RowStatus

  


 14. =
collectExporterTable  

  

   collectExporterTable =20
  =
OBJECT-TYPE
     &nbs=
p;=20
  SYNTAX      SEQUENCE=20
  =
OF
        &n=
bsp;         =20
  =
CollectExporterEntry
    &=
nbsp; =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "This table lists Exporters that received by=20
  =
collecting
       =
   =20
  process. This process manages them."
  =

       ::=3D { =
collectExporter 1=20
  }

 =20
  CollectExporterEntry=20
  ::=3D
       =
SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
collectExporterIndex      &nbs=
p;     =20
  =
Integer32,
      =
;    =20
  collectExporterSrcIpAddrType    =20
  =
InetAddressType,
     =
;     =20
  =
collectExporterSrcIpAddr      =
  =20
  =
InetAddress,
     &nb=
sp;    =20
  =
collectExporterProtocol      &=
nbsp;  =20
  =
Integer32,
      =
;    =20
  =
collectExporterSrcPort      &n=
bsp;   =20
  =
Integer32,
      =
;    =20
  =
collectLifeTimeTemplate      &=
nbsp;  =20
  =
Integer32,
      =
;    =20
  =
collectExporterRowStatus      =
  =20
  =
RowStatus
    &=
nbsp; =20
  }

What is the =
goal of that=20
  MIB table.
As this read-write, it means that I can configure =
on my=20
  Collector which Exporter I'm receiving info from. Is this supposed to =
serve as=20
  an ACL?
I would not have any problems if that MIB table would be =
read-only,=20
  simply listing the Exporters the Collector receives info from.
Same =

  question for the=20
  collectObservDomainStatisTable =20
  .

 


As=20
state already several times above: deffered!


  
 

  
 
15. I think =
that we are=20
  missing the observation domain as an index in many tables
Example: =
as the=20
  Template IDs are unique per Observation Domain, ipfixTemplateTable=20
  must contains the O.D.id as an index
Example: ipfixInstanceTable=20
  
On the other hand, I don't clearly understand the goal of =
collectObservDomainStatisTable.=20
  Should we simply add the O.D.id =
to the=20
  collectExporterStatisTable  and combine those =
stats?
 


Agreed here. The=20
MIB doesn't reflect the recent dicisions on Observation Domain and =
Session. So=20
those need to be integrated where =
needed.


 
16.=20

   collectExporterStatisEntry=20
OBJECT-TYPE
      =20
SYNTAX     =20
CollectExporterStatisEntry
   &=
nbsp;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    "Defines=20
an entry in the=20
collectExporterStatisTable"
    &=
nbsp; =20
INDEX {=20
collectExporterIndex,
     &=
nbsp;        =20
collectExporterDstPort }

I don't understand why we have =
two=20
indexes in this table? Isn't the collectExporterIndex enough? (next to =
the=20
O.D.id: see point 16)

17.

  =20
collectMeteringProcessId=20
OBJECT-TYPE
      =20
SYNTAX     =20
Integer32(1..2147483647)
   &nb=
sp;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    =20
"It uses the Metering Process id in the=20
received
       &n=
bsp;  =20
IPFIX message. It should be zero, if IPFIX message=20
don't
        =
;  =20
specify Metering Process=20
id."
       =
::=3D {=20
collectObservDomainStatisEntry 2 }

The IPFIX Message =
doesn't=20
specify the Metering Process id, so it will always be zero. So I would =
not even=20
mention it.
And remove it as index in collectObservDomainStatisTable =20
and collectTemplateStatisticsTable =20


18. collectTemplateStatisticsTable =20

Again, why is there a rowStatus in that=20
table?

19.


collectTemplateRcdTable&=
nbsp;=20
OBJECT-TYPE
     &nbs=
p;=20
SYNTAX      SEQUENCE=20
OF
        &n=
bsp;         =20
CollectTemplateRcdEntry
   &nbs=
p;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    "This=20
table lists templates that are received by=20
the
        &=
nbsp; =20
collecting process. This process manages=20
them."
       =
::=3D {=20
collectTemplate 2 =
}
 
  =20
collectTemplateRcdEntry=20
OBJECT-TYPE
      =20
SYNTAX     =20
CollectTemplateRcdEntry
   &nbs=
p;  =20
MAX-ACCESS=20
 not-accessible
   &=
nbsp;  =20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    =20
"Defines an entry in the=20
collectTemplateRcdTable"
    &nbs=
p; =20
INDEX=20
{
        &nb=
sp; =20
collectExporterIndex,
    =
      =20
collectObservDomainId,
  =
        =20
collectMeteringProcessId,
   &n=
bsp;      =20
collectTemplateRcdId,
    =
      =20
collectTemplateRcdIndex=20
}
       ::=3D =
{=20
collectTemplateRcdTable 1 }

  =20
CollectTemplateRcdEntry=20
::=3D
       =
SEQUENCE=20
{
        &nb=
sp; =20
collectTemplateRcdIndex       =

Integer32,
      =
;    =20
collectTemplateRcdInfoEltId  =20
Integer32,
      =
;    =20
collectTemplateInfoEltLength =20
Integer32,
      =
;    =20
collectTemplateRcdRowStatus  =20
RowStatus
     =20
 }

I'm wondering why we have this =
complex table=20
(5 indexes) simply to display how the templates decode.
Somehow, I =
failed to=20
find a business case for this table.
On the top of that, the template =
id are=20
unique per transport session, missing in the=20
index.
 


Well you find the=20
comments in Kobayashi-sans reply.


 

Regards, =
Benoit.
 


 
 


------=_NextPart_001_002D_01C6F331.0BCAE070--

------=_NextPart_000_002C_01C6F331.0BCAE070
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MDE0
NTQwWjAjBgkqhkiG9w0BCQQxFgQU8u1EA3fSWPOLipA2sgQ8N/hoTlAwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAI8NhxHQH8b+DUk8f3rm9svI
RQmNkruBB1jcTWzlp1EPWsV982JL9g2x9m6/xv5l8qz2P3742cQtX4JBsQVYCectiMaJnyEYN2qo
Uv+9I5IUEoIcZblQFslOkIBlwuXrwps0QS82Kn062sCAtTMBEVbNErIZcIF0D1DWfBZzOQwdf1ZJ
UoEbApKnTNA4PmvXFzD9FaRhnxEVvrYEVA+90aQVKSWSzH/jGDON0AA/9OUdOA8JIy1WNb3wkdXs
yYHoTmPNAc8xW/5ctKhOcSyMZFToi6l/fZKlAn/VYlJudyrdzUaHArPHjbtgtBeKkv9Kbt/odk8i
I5J9Z2rYP0ORuYQAAAAAAAA=

------=_NextPart_000_002C_01C6F331.0BCAE070--


--===============0547193649==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0547193649==--




From ipfix-bounces@ietf.org Wed Oct 18 22:25:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNau-0003Qg-8n; Wed, 18 Oct 2006 22:25:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNXv-0001pR-FD
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:22:11 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNJY-0006zI-Mj
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:07:25 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 580CB2000293;
	Thu, 19 Oct 2006 04:07:48 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09813-03; Thu, 19 Oct 2006 04:07:48 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 000E32000168;
	Thu, 19 Oct 2006 04:07:47 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] IPFIX MIB review
Date: Thu, 19 Oct 2006 04:07:17 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4B80@mx1.office>
In-Reply-To: <4533D03B.80100@cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] IPFIX MIB review
Thread-Index: AcbxUx1FGf6FGjyeRJGzRVKxcuRV+AByRrog
From: "Thomas Dietz" 
To: "Benoit Claise" , 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b59fa031b49cd6123c8bacf4dacd587a
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0547193649=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0547193649==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_002C_01C6F331.0BCAE070"

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C6F331.0BCAE070
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002D_01C6F331.0BCAE070"


------=_NextPart_001_002D_01C6F331.0BCAE070
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Benoit,
 
find my comments inline

--
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 


 



  _____  

From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Monday, October 16, 2006 8:32 PM
To: ipfix@ietf.org
Subject: [IPFIX] IPFIX MIB review


Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I sent the editorial details directly to Thomas.
Feel free to start a new email thread with one of the point below.

1.  Section 3, IPFIX Documents Overview.

I would insert the second paragraph of section 2 at the end of this
section., once we have defined the IPFIX document overview. 
Otherwise, you defined twice the information.

2. Section 5, terminology
   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. are
   semantically identical with those found in the IPFIX requirements
   document [RFC3917].  
It might be better to reference [IPFIX-PROTO], which is a normative
reference anyway.
 

For comment 1 and 2 you are definetly right but I wanted to have the
sections there and to be filled even with a preliminary text. I agree we
need to update those sections after the work on the other documents is
finished.
 

 
3.  Section 6.1.1, the Reporting Group
"ipfixCollectorGroupTable contains only indexes " I don't understand what it
means
 

You have the list of collectors where you could send your flow reports. But
an exporter could export the same flow record to multiple collectors for
redundancy or whatever reason. So I defined the that table to group
collectors together and then reference an index of this table at the
instance to indicate where the instance reports to. I guess this answers
also question 5 below.

 

4. Section 6.1.2 the Instance Group

   The ipfixTemplateTable lists all data templates that are used by the
   IPFIX exporter.  It has two indices.  The first one is the template
   id and the second one is just a running index for the field ids
   listed in the table.  So the ipfixTemplateEntry.4.x will list all
   field ids used for template id 4 in the order given by x.

   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable."
       INDEX { ipfixTemplateId, ipfixTemplateIndex }
       ::= { ipfixTemplateTable 1 }

Is there no conflict with the new definition of the template Id in
[IPFIX-PROTO], as the templateId is unique per Transport Session?

      Template ID 

          Each of the newly generated Template Records is given a unique  

          Template ID.  This uniqueness is local to the Transport 

          Session and Observation Domain that generated the Template ID.  

          Template IDs 0-255 are reserved for Template Sets, Options 

          Template Sets, and other reserved Sets yet to be created.  



If a transport session restarts, then...

5.  -- Collector Group Table, ipfixCollectorGroupTable OBJECT-TYPE
I don't see what we gain with this group?
If this group contains several entries, are these multiple exports to all
the entries.
I think this group only makes sense if we defined the notion of backup
versus multiple versus load-balancing export in there.

6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, etc...
are read-write.
Shall we limit the read-only with the "Units of Conformance"?
 

I just opened a new thread to explain the problem here. We might want to
have a writeable MIB. So for now I will remove all row status and make all
object read-only. We need to take a decission on this topics first and then
start a dicusion (if we agree to make it writeable) which object and tables
should be writable and which not.

 
 
7. ipfixInstanceReportingProcessId 

   ipfixInstanceReportingProcessId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The process id of the reporting process used by this
            instance."
       ::= { ipfixInstanceEntry 10 }

There is no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not sure what this adds to the MIB.
 

Still a remainder from the old PSAMP MIB so i will delete this object.

 
 
Note that the editorial changes have been sent directly to Thomas.

8. ipfixInstancePacketsDropped 
   ipfixInstancePacketsDropped OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of packets dropped while filtering/sampling
            packets."
       ::= { ipfixInstanceEntry 8 }

This one should be part of the PSAMP MIB, right?
 

It is definitely used in PSAMP. So I should state that.

 
 
 
9. There is something missing. As defined in the CISCO NETFLOW MIB


NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION

    STATUS  current

    DESCRIPTION        "Defines different types of interface configuration."

    SYNTAX  INTEGER{

            interfaceDirNone(0),

            interfaceDirIngress(1),

            interfaceDirEgress(2),

            interfaceDirBoth(3)

    }



cnfCIInterfaceTable OBJECT-TYPE

    SYNTAX      SEQUENCE OF CnfCIInterfaceEntry

    MAX-ACCESS  not-accessible

    STATUS      current

    DESCRIPTION        "This table provides Netflow Enable information per
interface."

    ::= { cnfCacheInfo
  1 }



cnfCIInterfaceEntry OBJECT-TYPE

    SYNTAX     CnfCIInterfaceEntry

    MAX-ACCESS not-accessible

    STATUS     current

    DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry
 ."

    INDEX { ifIndex
  }

    ::= { cnfCIInterfaceTable
  1}



CnfCIInterfaceEntry ::= SEQUENCE {

        cnfCINetflowEnable

NfInterfaceDirectionTypes

     }

  
cnfCINetflowEnable OBJECT-TYPE

    SYNTAX      NfInterfaceDirectionTypes

    MAX-ACCESS  read-write

    STATUS      current

    DESCRIPTION        "Indicates whether the netflow feature is enabled for
this

         interface, and if so, in which directions."

    ::= { cnfCIInterfaceEntry
  1 }





  
 
Well, those object describe somehow the Observation Domain (if I am not
misleaded here).
So since the notion of Observation Domain is still missing in the MIB we
should place
this somewhere and somehow there.

 

10. Do we want to foresee the version already




  IpfixCollectorEntry ::= SEQUENCE {
           ipfixCollectorIndex             Integer32,
           ipfixCollectorDstIpAddressType  InetAddressType,
           ipfixCollectorDstIpAddress      InetAddress,
           ipfixCollectorDstProtocol       Integer32,
           ipfixCollectorDstPort           Integer32,
           ipfixCollectorReportsSent       Integer32,
           ipfixExportVersion               Integer32    ???????????????????
           ipfixCollectorRowStatus         RowStatus
       } 

Good point to add. 

 
 
11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
<--------------------------------------------------
       STATUS      current          
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it mean?
Can only deleted by SNMP? And not created?
 

Let's defer this discusion of how the access to different objects need to be
set to make them writeable until we made the basic desision (see above).

 
 
12. We would really need some examples of the instance and method chain
group
 

More than true.

 
 
13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:


cnfESExportRate OBJECT-TYPE

    SYNTAX     Counter32

    UNITS      "bytes per second"

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of Bytes exported per second."

    ::= { cnfExportStatistics
  2 }



cnfESRecordsExported OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of flow statistics
  records which were exported."

    ::= { cnfExportStatistics
  3 }



cnfESPktsExported OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of packets (udp datagrams) which were
exported."

    ::= { cnfExportStatistics
  4 }



cnfESPktsFailed OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of times a flow record could not be exported
because of

         a pak allocation failure."

    ::= { cnfExportStatistics
  5 }



cnfESPktsDropped OBJECT-TYPE

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of export packets which were dropped at the
time of

         ipwrite operation. The reasons for this failure are no FIB,

         adjacency failure, MTU failed, enqueue failed, IPC failed etc."

    ::= { cnfExportStatistics
  6 }

 
 



Fine! I now that statistics are a little underrepresented right now. Every
comment/addition in this regard is welcome. 

 
 Note: the collectExporterStatisTable  should be aligned with the stats on
the exporter. I mean: we should be able to compare the statistics on the
exporter and the collector.

Allignment of the two parts is an issue but it will take some time and I try
to carefully align the two part in the near future. 

 
    collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus







 14. collectExporterTable  

   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can configure on my Collector which
Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, simply
listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .

 

As state already several times above: deffered!

 
 
15. I think that we are missing the observation domain as an index in many
tables
Example: as the Template IDs are unique per Observation Domain,
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable 
On the other hand, I don't clearly understand the goal of
collectObservDomainStatisTable. Should we simply add the O.D.id to the
collectExporterStatisTable  and combine those stats?
 

Agreed here. The MIB doesn't reflect the recent dicisions on Observation
Domain and Session. So those need to be integrated where needed.
 
16. 
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the
collectExporterIndex enough? (next to the O.D.id: see point 16)

17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will always
be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and
collectTemplateStatisticsTable  

18. collectTemplateStatisticsTable  
Again, why is there a rowStatus in that table?

19.


collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to display
how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session,
missing in the index.
 
Well you find the comments in Kobayashi-sans reply.
 

Regards, Benoit.
 
 
 

------=_NextPart_001_002D_01C6F331.0BCAE070
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Dear Benoit,


 


find my comments inline


--
Thomas=20
Dietz           &n=
bsp;          =20
E-mail: Thomas.Dietz@netlab.nec.de
Network=20
Laboratories          &=
nbsp;   =20
Phone:  +49 6221 4342-128
NEC Europe=20
Ltd.           &nb=
sp;       =20
Fax:    +49 6221 4342-155
Kurfuersten-Anlage =
36
69115=20
Heidelberg, =
Germany          http://www.netlab.nec.de


 



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Monday, October 16, 2006 8:32 PM
To:=20
  ipfix@ietf.org
Subject: [IPFIX] IPFIX MIB=20
review


  

  
Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I=20
  sent the editorial details directly to Thomas.
Feel free to start a =
new=20
  email thread with one of the point below.

1.  Section 3, =
IPFIX=20
  Documents Overview.

I would insert the second paragraph =
of=20
  section 2 at the end of this section., once we have defined the IPFIX =
document=20
  overview. 
Otherwise, you defined twice the=20
  information.

2. Section=20
  5, terminology
   The definitions of the =
basic terms=20
  like IP Traffic Flow, Exporting
  =20
  Process, Collecting Process, Observation Points, etc.=20
  are
   semantically identical =
with those=20
  found in the IPFIX requirements
  =20
  document [RFC3917].  
It might be better to =
reference=20
  [IPFIX-PROTO], which is a normative reference anyway.
 


For comment 1 and=20
2 you are definetly right but I wanted to have the sections there and to =
be=20
filled even with a preliminary text. I agree we need to update those =
sections=20
after the work on the other documents is=20
finished.


 


  
 
3.  Section 6.1.1, =
the=20
  Reporting Group
"ipfixCollectorGroupTable=20
  contains only indexes " I don't understand what it means
 


You have the list=20
of collectors where you could send your flow reports. But an exporter =
could=20
export the same flow record to multiple collectors for redundancy or =
whatever=20
reason. So I defined the that table to group collectors together and =
then=20
reference an index of this table at the instance to indicate where the =
instance=20
reports to. I guess this answers also question 5=20
below.


  
 

4. Section 6.1.2 the =
Instance=20
  Group

   The ipfixTemplateTable =
lists all=20
  data templates that are used by the
  =20
  IPFIX exporter.  It has two =
indices. =20
  The first one is the template
  =20
  id and the second one is just a running index for the field=20
  ids
   listed in the =
table. =20
  So the ipfixTemplateEntry.4.x will list=20
  all
   field ids used for =
template id 4=20
  in the order given by x.

   =
ipfixTemplateEntry=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
IpfixTemplateEntry
    &nb=
sp; =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "Defines an entry in the=20
  =
ipfixTemplateTable."
     &n=
bsp;=20
  INDEX { ipfixTemplateId, ipfixTemplateIndex=20
  }
       =
::=3D {=20
  ipfixTemplateTable 1 }

Is there no conflict with the =
new=20
  definition of the template Id in [IPFIX-PROTO], as the templateId is =
unique=20
  per Transport Session?
      Template ID=20
          Each of the newly generated Template Records is given a unique =
=20
          Template ID.  This uniqueness is local to the Transport=20
          Session and Observation Domain that generated the Template ID. =
=20
          Template IDs 0-255 are reserved for Template Sets, Options=20
          Template Sets, and other reserved Sets yet to be created. =20

If a transport session restarts, then...


  

5.  -- Collector Group Table,=20
  ipfixCollectorGroupTable =
OBJECT-TYPE
I =
don't see=20
  what we gain with this group?
If this group contains several =
entries, are=20
  these multiple exports to all the entries.
I think this group only =
makes=20
  sense if we defined the notion of backup versus multiple versus =
load-balancing=20
  export in there.

6. =
And again=20
  the discussion about read-write versus read-only.
ipfixCollectorTable,=20
  ipfixCollectorGroupTable,=20
  ipfixTemplateTable,=20
  etc... are read-write.
Shall we limit the read-only with the =
"Units of =
Conformance"?
 


I =
just opened a=20
new thread to explain the problem here. We might want to have a =
writeable MIB.=20
So for now I will remove all row status and make all object read-only. =
We need=20
to take a decission on this topics first and then start a dicusion (if =
we agree=20
to make it writeable) which object and tables should be writable and =
which=20
not.


  
 

  
 
7.=20
  ipfixInstanceReportingProcessId =


  =20
  ipfixInstanceReportingProcessId=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  =
read-only
      =
=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The process id of the reporting process used by=20
  =
this
        =
   =20
  =
instance."
      =
;=20
  ::=3D { ipfixInstanceEntry 10 }

There is no =
Reporting=20
  Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not =
sure what=20
  this adds to the MIB.
 


Still a remainder=20
from the old PSAMP MIB so i will delete this =
object.


  
 

  
 
Note that the editorial =
changes have=20
  been sent directly to Thomas.

8.=20
  ipfixInstancePacketsDropped 
   =

  ipfixInstancePacketsDropped=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  =
read-only
      =
=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The number of packets dropped while=20
  =
filtering/sampling
     &nbs=
p;     =20
  =
packets."
      =
=20
  ::=3D { ipfixInstanceEntry 8 }

This one =
should be=20
  part of the PSAMP MIB, right?
 


It is definitely=20
used in PSAMP. So I should state that.


  
 

  
 

  
 
9. There is something =
missing. As=20
  defined in the CISCO NETFLOW MIB

  
NfInterfaceDirectionTypes ::=3D =
TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION        "Defines different types =
of interface configuration."
    SYNTAX  INTEGER{
            interfaceDirNone(0),
            interfaceDirIngress(1),
            interfaceDirEgress(2),
            interfaceDirBoth(3)
    }

cnfCIInterfaceTable OBJECT-TYPE
    SYNTAX      SEQUENCE =
OF CnfCIInterfaceEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION        "This table provides =
Netflow Enable information per interface."
    ::=3D { cnfCacheInfo =
1 }

cnfCIInterfaceEntry OBJECT-TYPE
    SYNTAX     CnfCIInterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION        "A conceptual row in the =
cnfCIInter=
faceEntry."
    INDEX { ifIndex }
    ::=3D { cnfCIInter=
faceTable 1}

CnfCIInterfaceEntry ::=3D SEQUENCE {
        cnfCINetflo=
wEnable              NfInterfaceDirectionTypes
     }
  
cnfCINetflowEnable OBJECT-TYPE
    SYNTAX      =
NfInterfaceDirectionTypes
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION        "Indicates whether the =
netflow feature is enabled for this
         interface, and if so, in which directions."
    ::=3D { cnfCIInter=
faceEntry 1 }


  
 


Well, =
those object describe somehow the Observation Domain (if I am not =
misleaded here).
So =
since the notion of Observation Domain is still missing in the MIB we =
should place
this somewhere and somehow =
there.


 
10. Do we want to foresee the version already


  IpfixCollectorEntry ::=3D SEQUENCE=20
  =
{
        &nb=
sp; =20
  ipfixCollectorIndex      &n=
bsp;     =20
  Integer32,
         &nb=
sp;=20
  ipfixCollectorDstIpAddressType =20
  InetAddressType,
         &nb=
sp;=20
  ipfixCollectorDstIpAddress     =20
  InetAddress,
         &nb=
sp;=20
  =
ipfixCollectorDstProtocol      =
;=20
  Integer32,
         &nb=
sp;=20
  =
ipfixCollectorDstPort      &nb=
sp;   =20
  Integer32,
     =20
  =
     ipfixCollectorReportsSe=
nt      =20
  Integer32,
       =
   =20
  =
ipfixExportVersion         &=
nbsp;    =20
  Integer32    =
???????????????????
         &nb=
sp;=20
  =
ipfixCollectorRowStatus      &=
nbsp; =20
  RowStatus
       =
}=20

Good point to add. 


 
 


  
11. only ipfixTemplateRowStatus  is =
read-write in=20
  this table
 
  =20
  IpfixTemplateEntry ::=3D SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
ipfixTemplateId       &nb=
sp; =20
  =
Integer32,
      =
;    =20
  ipfixTemplateIndex      =20
  =
Integer32,
      =
;    =20
  ipfixTemplateFieldId    =20
  =
Integer32,
      =
;    =20
  ipfixTemplateRowStatus  =20
  =
RowStatus
      =
=20
  =
}
 
&=
nbsp; =20
  ipfixTemplateId=20
  OBJECT-TYPE
      =20
  SYNTAX      Integer32=20
  =
(1..2147483647)
       =

  MAX-ACCESS =20
  not-accessible       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The unique identifier for the=20
  template."
      =20
  =
REFERENCE
      =
    =20
  "draft-ietf-ipfix-sample-tech-04.txt, Section=20
  5.1"
   -- Editor Note: get =
reference=20
  right!
       =
::=3D {=20
  ipfixTemplateEntry 1 =
}
 
  =20
  ipfixTemplateIndex=20
  OBJECT-TYPE
      =20
  SYNTAX      Integer32=20
  =
(1..2147483647)
       =

  MAX-ACCESS =20
  not-accessible       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The locally arbitrary, but unique identifier of a field=20
  =
Id
        &n=
bsp;  =20
  in the template identified by=20
  =
ipfixTemplateId.
 
  &nb=
sp;        =20
  The value is expected to remain constant at least from=20
  =
one
        &=
nbsp;  =20
  re-initialization of the entity's network management=20
  =
system
       &nbs=
p;   =20
  to the next=20
  =
re-initialization."
     &nb=
sp;=20
  ::=3D { ipfixTemplateEntry 2=20
  }

  =
ipfixTemplateFieldId=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
Integer32
      =
=20
  MAX-ACCESS =20
  read-only       =20
  =
<--------------------------------------------------
      =20
  STATUS     =20
  current         =20
  
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The Field Id at position ipfixTemplateIndex in the=20
  =
template
       &n=
bsp;   =20
  ipfixTemplateId. This implicitly gives the data type=20
  =
and
        &=
nbsp;  =20
  state values that are=20
  exported."
      =20
  =
REFERENCE
      =
    =20
  "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO=20
  MODEL"
   -- Editor Note: get =
reference=20
  right!
       =
::=3D {=20
  ipfixTemplateEntry 3 =
}
 
  =20
  ipfixTemplateRowStatus=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
RowStatus
      =
=20
  MAX-ACCESS =20
  =
read-create
     &nbs=
p;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "The status of this row of the=20
  table."
       =
::=3D {=20
  ipfixTemplateEntry 4 }

Only=20
  ipfixTemplateRowStatus  is read-write in this =
table.=20
  What does it mean? Can only deleted by SNMP? And not created?
 


Let's defer this discusion of how the access to different =
objects need to=20
be set to make them writeable until we made the basic desision (see=20
above).


  
 

  
 
12. We =
would really=20
  need some examples of the instance and method chain group
 


More than true.


  
 

  
 
13. In =
ipfixReporting, I=20
  really would like to see some stats.
Coming from the NetFlow=20
  MIB:

  
cnfESExportRate OBJECT-TYPE
    SYNTAX     Counter32
    UNITS      "bytes per second"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of Bytes =
exported per second."
    ::=3D { cnfExportS=
tatistics 2 }

cnfESRecordsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of flow statistics =
records which were exported."
    ::=3D { cnfExportS=
tatistics 3 }

cnfESPktsExported OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of packets (udp =
datagrams) which were exported."
    ::=3D { cnfExportS=
tatistics 4 }

cnfESPktsFailed OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of times a flow =
record could not be exported because of
         a pak allocation failure."
    ::=3D { cnfExportS=
tatistics 5 }

cnfESPktsDropped OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION        "Number of export =
packets which were dropped at the time of
         ipwrite operation. The reasons for this failure are no FIB,
         adjacency failure, MTU failed, enqueue failed, IPC failed =
etc."
    ::=3D { cnfExportS=
tatistics 6 }
 
 

Fine! I now that statistics are a little underrepresented right =
now. Every comment/addition in this regard is =
welcome. 


 
 Note: the =
collectExporterStatisTable  should be aligned with =
the stats on the exporter. I mean: we should be able to compare the =
statistics on the exporter and the collector.


Allignment of the two parts is an issue but it will take some =
time and I=20
try to carefully align the two part in the near=20
future. 


  
 

  
   =20
  collectExporterStatisEntry=20
  OBJECT-TYPE
      =20
  SYNTAX     =20
  =
CollectExporterStatisEntry
   &=
nbsp;  =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    "Defines=20
  an entry in the=20
  =
collectExporterStatisTable"
    &=
nbsp; =20
  INDEX {=20
  =
collectExporterIndex,
     &=
nbsp;        =20
  collectExporterDstPort=20
  =
}
     =
; =20
  ::=3D { collectExporterStatisTable 1=20
  }
 
  =20
  CollectExporterStatisEntry=20
  ::=3D
       =
SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
collectExporterDstPort      &n=
bsp;   =20
  =
Integer32,
      =
;    =20
  =
collectExporterProcessId      =
  =20
  =
Integer32,
      =
;    =20
  =
collectExporterRcdPackets      =
; =20
  =
Counter32,
      =
;    =20
  =
collectExporterRcdBytes      &=
nbsp;  =20
  =
Counter32,
      =
;    =20
  =
collectExporterRcdMessages     &nbs=
p;=20
  =
Counter32,
      =
;    =20
  collectExporterDiscardMessages  =20
  =
Counter32,
      =
;    =20
  =
collectSessionElapsedTime      =
; =20
  =
Gauge32,
      &=
nbsp;   =20
  =
collectExporterRcdFlows      &=
nbsp;  =20
  =
Counter32,
      =
;    =20
  collectExporterRcdTemplates      =

  =
Counter32,
      =
;    =20
  collectExporterStatisRowStatus  =20
  RowStatus

  


 14. =
collectExporterTable  

  

   collectExporterTable =20
  =
OBJECT-TYPE
     &nbs=
p;=20
  SYNTAX      SEQUENCE=20
  =
OF
        &n=
bsp;         =20
  =
CollectExporterEntry
    &=
nbsp; =20
  MAX-ACCESS =20
  =
not-accessible
     &=
nbsp;=20
  STATUS     =20
  =
current
      =20
  =
DESCRIPTION
     &nbs=
p;    =20
  "This table lists Exporters that received by=20
  =
collecting
       =
   =20
  process. This process manages them."
  =

       ::=3D { =
collectExporter 1=20
  }

 =20
  CollectExporterEntry=20
  ::=3D
       =
SEQUENCE=20
  =
{
        &nb=
sp; =20
  =
collectExporterIndex      &nbs=
p;     =20
  =
Integer32,
      =
;    =20
  collectExporterSrcIpAddrType    =20
  =
InetAddressType,
     =
;     =20
  =
collectExporterSrcIpAddr      =
  =20
  =
InetAddress,
     &nb=
sp;    =20
  =
collectExporterProtocol      &=
nbsp;  =20
  =
Integer32,
      =
;    =20
  =
collectExporterSrcPort      &n=
bsp;   =20
  =
Integer32,
      =
;    =20
  =
collectLifeTimeTemplate      &=
nbsp;  =20
  =
Integer32,
      =
;    =20
  =
collectExporterRowStatus      =
  =20
  =
RowStatus
    &=
nbsp; =20
  }

What is the =
goal of that=20
  MIB table.
As this read-write, it means that I can configure =
on my=20
  Collector which Exporter I'm receiving info from. Is this supposed to =
serve as=20
  an ACL?
I would not have any problems if that MIB table would be =
read-only,=20
  simply listing the Exporters the Collector receives info from.
Same =

  question for the=20
  collectObservDomainStatisTable =20
  .

 


As=20
state already several times above: deffered!


  
 

  
 
15. I think =
that we are=20
  missing the observation domain as an index in many tables
Example: =
as the=20
  Template IDs are unique per Observation Domain, ipfixTemplateTable=20
  must contains the O.D.id as an index
Example: ipfixInstanceTable=20
  
On the other hand, I don't clearly understand the goal of =
collectObservDomainStatisTable.=20
  Should we simply add the O.D.id =
to the=20
  collectExporterStatisTable  and combine those =
stats?
 


Agreed here. The=20
MIB doesn't reflect the recent dicisions on Observation Domain and =
Session. So=20
those need to be integrated where =
needed.


 
16.=20

   collectExporterStatisEntry=20
OBJECT-TYPE
      =20
SYNTAX     =20
CollectExporterStatisEntry
   &=
nbsp;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    "Defines=20
an entry in the=20
collectExporterStatisTable"
    &=
nbsp; =20
INDEX {=20
collectExporterIndex,
     &=
nbsp;        =20
collectExporterDstPort }

I don't understand why we have =
two=20
indexes in this table? Isn't the collectExporterIndex enough? (next to =
the=20
O.D.id: see point 16)

17.

  =20
collectMeteringProcessId=20
OBJECT-TYPE
      =20
SYNTAX     =20
Integer32(1..2147483647)
   &nb=
sp;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    =20
"It uses the Metering Process id in the=20
received
       &n=
bsp;  =20
IPFIX message. It should be zero, if IPFIX message=20
don't
        =
;  =20
specify Metering Process=20
id."
       =
::=3D {=20
collectObservDomainStatisEntry 2 }

The IPFIX Message =
doesn't=20
specify the Metering Process id, so it will always be zero. So I would =
not even=20
mention it.
And remove it as index in collectObservDomainStatisTable =20
and collectTemplateStatisticsTable =20


18. collectTemplateStatisticsTable =20

Again, why is there a rowStatus in that=20
table?

19.


collectTemplateRcdTable&=
nbsp;=20
OBJECT-TYPE
     &nbs=
p;=20
SYNTAX      SEQUENCE=20
OF
        &n=
bsp;         =20
CollectTemplateRcdEntry
   &nbs=
p;  =20
MAX-ACCESS =20
not-accessible
     &=
nbsp;=20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    "This=20
table lists templates that are received by=20
the
        &=
nbsp; =20
collecting process. This process manages=20
them."
       =
::=3D {=20
collectTemplate 2 =
}
 
  =20
collectTemplateRcdEntry=20
OBJECT-TYPE
      =20
SYNTAX     =20
CollectTemplateRcdEntry
   &nbs=
p;  =20
MAX-ACCESS=20
 not-accessible
   &=
nbsp;  =20
STATUS     =20
current
      =20
DESCRIPTION
     &nbs=
p;    =20
"Defines an entry in the=20
collectTemplateRcdTable"
    &nbs=
p; =20
INDEX=20
{
        &nb=
sp; =20
collectExporterIndex,
    =
      =20
collectObservDomainId,
  =
        =20
collectMeteringProcessId,
   &n=
bsp;      =20
collectTemplateRcdId,
    =
      =20
collectTemplateRcdIndex=20
}
       ::=3D =
{=20
collectTemplateRcdTable 1 }

  =20
CollectTemplateRcdEntry=20
::=3D
       =
SEQUENCE=20
{
        &nb=
sp; =20
collectTemplateRcdIndex       =

Integer32,
      =
;    =20
collectTemplateRcdInfoEltId  =20
Integer32,
      =
;    =20
collectTemplateInfoEltLength =20
Integer32,
      =
;    =20
collectTemplateRcdRowStatus  =20
RowStatus
     =20
 }

I'm wondering why we have this =
complex table=20
(5 indexes) simply to display how the templates decode.
Somehow, I =
failed to=20
find a business case for this table.
On the top of that, the template =
id are=20
unique per transport session, missing in the=20
index.
 


Well you find the=20
comments in Kobayashi-sans reply.


 

Regards, =
Benoit.
 


 
 


------=_NextPart_001_002D_01C6F331.0BCAE070--

------=_NextPart_000_002C_01C6F331.0BCAE070
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MDE0
NTQwWjAjBgkqhkiG9w0BCQQxFgQU8u1EA3fSWPOLipA2sgQ8N/hoTlAwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAI8NhxHQH8b+DUk8f3rm9svI
RQmNkruBB1jcTWzlp1EPWsV982JL9g2x9m6/xv5l8qz2P3742cQtX4JBsQVYCectiMaJnyEYN2qo
Uv+9I5IUEoIcZblQFslOkIBlwuXrwps0QS82Kn062sCAtTMBEVbNErIZcIF0D1DWfBZzOQwdf1ZJ
UoEbApKnTNA4PmvXFzD9FaRhnxEVvrYEVA+90aQVKSWSzH/jGDON0AA/9OUdOA8JIy1WNb3wkdXs
yYHoTmPNAc8xW/5ctKhOcSyMZFToi6l/fZKlAn/VYlJudyrdzUaHArPHjbtgtBeKkv9Kbt/odk8i
I5J9Z2rYP0ORuYQAAAAAAAA=

------=_NextPart_000_002C_01C6F331.0BCAE070--


--===============0547193649==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0547193649==--




From ipfix-bounces@ietf.org Wed Oct 18 22:33:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNik-0008FW-Cc; Wed, 18 Oct 2006 22:33:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNij-0008FI-Ee
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:33:21 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNic-0003u7-Ey
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:33:21 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X8i2027730
	for ; Thu, 19 Oct 2006 11:33:08 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X75O005555
	for ; Thu, 19 Oct 2006 11:33:07 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X6i0027530
	for ; Thu, 19 Oct 2006 11:33:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X6tC009071
	for ; Thu, 19 Oct 2006 11:33:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X5wW007981
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X5Jx007976
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.144])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X3Oi017538
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Message-ID: <4536E3DF.5070903@lab.ntt.co.jp>
Date: Thu, 19 Oct 2006 11:33:03 +0900
From: Hitoshi Irino 
Organization: NTT
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: multipart/mixed; boundary="------------080202020107070705050605"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227
Subject: [IPFIX] [Fwd: I-D ACTION:draft-irino-ipfix-ie-order-00.txt]
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--------------080202020107070705050605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I submitted a -00 draft about order of Information Elements:
http://www.ietf.org/internet-drafts/draft-irino-ipfix-ie-order-00.txt

I suppose that IPFIX has possibility that various templates are created 
  from combination of same Information Elements, because it doesn't have 
rules about order of Information Elements. I suppose that the 
possibility increase a load and/or required resource of collector.
So, I suggest about order of Information Elements.

Comments, suggestion and objection are welcome.

Regards,
Hitoshi Irino
-- 
Hitoshi Irino
NTT Network Service Systems Laboratories

--------------080202020107070705050605
Content-Type: message/rfc822;
	name="I-D ACTION:draft-irino-ipfix-ie-order-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="I-D ACTION:draft-irino-ipfix-ie-order-00.txt"

Return-Path: 
Received: from imm.m.ecl.ntt.co.jp [129.60.5.237]
	by localhost.localdomain with POP3 (fetchmail-6.3.4)
	for  (single-drop);
	Thu, 19 Oct 2006 06:48:59 +0900 (JST)
Received: from eclscan1.m.ecl.ntt.co.jp (eclscan1.m.ecl.ntt.co.jp
	[129.60.5.67])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlRv3004508
	for ; Thu, 19 Oct 2006 06:47:27 +0900 (JST)
Received: from eclscan1.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlPY3012491
	for ; Thu, 19 Oct 2006 06:47:27 +0900 (JST)
Received: from idmb.m.ecl.ntt.co.jp. (idmb.m.ecl.ntt.co.jp [129.60.5.3])
	by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlPpW012486; Thu, 19 Oct 2006 06:47:25 +0900 (JST)
Received: from nttmail2.ecl.ntt.co.jp (nttmail2.ecl.ntt.co.jp [129.60.57.213])
	by idmb.m.ecl.ntt.co.jp. (8.13.8/8.13.8) with ESMTP id
	k9ILlPBJ023826; Thu, 19 Oct 2006 06:47:25 +0900 (JST)
Received: from vcs4.rdh.ecl.ntt.co.jp (vcs4 [129.60.39.111])
	by nttmail2.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlOFV019173; 
	Thu, 19 Oct 2006 06:47:24 +0900 (JST)
Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113])
	by vcs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlNP8019681; Thu, 19 Oct 2006 06:47:23 +0900 (JST)
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlNng011107; 
	Thu, 19 Oct 2006 06:47:23 +0900 (JST)
Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlMBl025230;
	Thu, 19 Oct 2006 06:47:22 +0900 (JST)
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHQX-00013X-I8; Wed, 18 Oct 2006 15:50:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQQ-00010O-Ht
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:02 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQP-0003mV-To
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D8C0B26E42
	for ; Wed, 18 Oct 2006 19:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GaHQP-0001SK-NS
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: 
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 18 Oct 2006 15:50:01 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: I-D ACTION:draft-irino-ipfix-ie-order-00.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: i-d-announce-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Order of Information Elements
	Author(s)	: H. Irino
	Filename	: draft-irino-ipfix-ie-order-00.txt
	Pages		: 43
	Date		: 2006-10-18
	
   This document describes about guideline of order of Information
   Elements of IPFIX protocol to create templates for exporters.  This
   document aims at definition rules to generate same template from same
   selected Information Elements independently of difference of
   implementation.  And then it can be expected for simple template
   management of collecting process and increasing speed or decreasing
   load of decoding of Information Elements.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irino-ipfix-ie-order-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-irino-ipfix-ie-order-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-irino-ipfix-ie-order-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-18110232.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-irino-ipfix-ie-order-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-irino-ipfix-ie-order-00.txt"; 
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-18110232.I-D@ietf.org>


--OtherAccess--

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



--------------080202020107070705050605
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://www1.ietf.org/mailman/listinfo/ipfix

--------------080202020107070705050605--





From ipfix-bounces@ietf.org Wed Oct 18 22:33:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaNik-0008FW-Cc; Wed, 18 Oct 2006 22:33:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNij-0008FI-Ee
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:33:21 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNic-0003u7-Ey
	for ipfix@ietf.org; Wed, 18 Oct 2006 22:33:21 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X8i2027730
	for ; Thu, 19 Oct 2006 11:33:08 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X75O005555
	for ; Thu, 19 Oct 2006 11:33:07 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X6i0027530
	for ; Thu, 19 Oct 2006 11:33:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X6tC009071
	for ; Thu, 19 Oct 2006 11:33:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X5wW007981
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9J2X5Jx007976
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.144])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9J2X3Oi017538
	for ; Thu, 19 Oct 2006 11:33:05 +0900 (JST)
Message-ID: <4536E3DF.5070903@lab.ntt.co.jp>
Date: Thu, 19 Oct 2006 11:33:03 +0900
From: Hitoshi Irino 
Organization: NTT
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: multipart/mixed; boundary="------------080202020107070705050605"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227
Subject: [IPFIX] [Fwd: I-D ACTION:draft-irino-ipfix-ie-order-00.txt]
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--------------080202020107070705050605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I submitted a -00 draft about order of Information Elements:
http://www.ietf.org/internet-drafts/draft-irino-ipfix-ie-order-00.txt

I suppose that IPFIX has possibility that various templates are created 
  from combination of same Information Elements, because it doesn't have 
rules about order of Information Elements. I suppose that the 
possibility increase a load and/or required resource of collector.
So, I suggest about order of Information Elements.

Comments, suggestion and objection are welcome.

Regards,
Hitoshi Irino
-- 
Hitoshi Irino
NTT Network Service Systems Laboratories

--------------080202020107070705050605
Content-Type: message/rfc822;
	name="I-D ACTION:draft-irino-ipfix-ie-order-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="I-D ACTION:draft-irino-ipfix-ie-order-00.txt"

Return-Path: 
Received: from imm.m.ecl.ntt.co.jp [129.60.5.237]
	by localhost.localdomain with POP3 (fetchmail-6.3.4)
	for  (single-drop);
	Thu, 19 Oct 2006 06:48:59 +0900 (JST)
Received: from eclscan1.m.ecl.ntt.co.jp (eclscan1.m.ecl.ntt.co.jp
	[129.60.5.67])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlRv3004508
	for ; Thu, 19 Oct 2006 06:47:27 +0900 (JST)
Received: from eclscan1.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlPY3012491
	for ; Thu, 19 Oct 2006 06:47:27 +0900 (JST)
Received: from idmb.m.ecl.ntt.co.jp. (idmb.m.ecl.ntt.co.jp [129.60.5.3])
	by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlPpW012486; Thu, 19 Oct 2006 06:47:25 +0900 (JST)
Received: from nttmail2.ecl.ntt.co.jp (nttmail2.ecl.ntt.co.jp [129.60.57.213])
	by idmb.m.ecl.ntt.co.jp. (8.13.8/8.13.8) with ESMTP id
	k9ILlPBJ023826; Thu, 19 Oct 2006 06:47:25 +0900 (JST)
Received: from vcs4.rdh.ecl.ntt.co.jp (vcs4 [129.60.39.111])
	by nttmail2.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlOFV019173; 
	Thu, 19 Oct 2006 06:47:24 +0900 (JST)
Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113])
	by vcs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9ILlNP8019681; Thu, 19 Oct 2006 06:47:23 +0900 (JST)
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlNng011107; 
	Thu, 19 Oct 2006 06:47:23 +0900 (JST)
Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9ILlMBl025230;
	Thu, 19 Oct 2006 06:47:22 +0900 (JST)
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaHQX-00013X-I8; Wed, 18 Oct 2006 15:50:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQQ-00010O-Ht
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:02 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQP-0003mV-To
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D8C0B26E42
	for ; Wed, 18 Oct 2006 19:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GaHQP-0001SK-NS
	for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: 
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 18 Oct 2006 15:50:01 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: I-D ACTION:draft-irino-ipfix-ie-order-00.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: i-d-announce-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Order of Information Elements
	Author(s)	: H. Irino
	Filename	: draft-irino-ipfix-ie-order-00.txt
	Pages		: 43
	Date		: 2006-10-18
	
   This document describes about guideline of order of Information
   Elements of IPFIX protocol to create templates for exporters.  This
   document aims at definition rules to generate same template from same
   selected Information Elements independently of difference of
   implementation.  And then it can be expected for simple template
   management of collecting process and increasing speed or decreasing
   load of decoding of Information Elements.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irino-ipfix-ie-order-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-irino-ipfix-ie-order-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-irino-ipfix-ie-order-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-18110232.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-irino-ipfix-ie-order-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-irino-ipfix-ie-order-00.txt"; 
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-18110232.I-D@ietf.org>


--OtherAccess--

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



--------------080202020107070705050605
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://www1.ietf.org/mailman/listinfo/ipfix

--------------080202020107070705050605--





From ipfix-bounces@ietf.org Thu Oct 19 01:33:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaQW8-0002zR-0n; Thu, 19 Oct 2006 01:32:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQW7-0002yF-F9
	for ipfix@ietf.org; Thu, 19 Oct 2006 01:32:31 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaQW5-0006mF-Qh
	for ipfix@ietf.org; Thu, 19 Oct 2006 01:32:31 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9J5NBUL016486
	for ; Thu, 19 Oct 2006 01:23:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 07:32:22 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAI0Z3A
From: "Romascanu, Dan \(Dan\)" 
To: "Thomas Dietz" , 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

My opinion as a contributor is that write operations should be allowed
in this case. The analogy is the MIB objects that allow the control of
destination and filtering of the SNMP notifications. The SNMP framework
does allow for controls on these, the are several MIB modules that
include such objects and there is enough documentation and operational
experience in the SNMP world to show how this needs to be done.=20

Dan


=20
=20

> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> Sent: Thursday, October 19, 2006 4:19 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Dear Benoit, Kobayashi and others,
>=20
> I want to summarize 2 points that arose in the current=20
> discussion of the IPFIX MIB and poll the list for comments=20
> how we should proceed with it.
>=20
> It is a fundamental decision if we should allow the IPFIX=20
> devices to be configured via SNMP. For the collector there is=20
> not much to configure but for the exporter there are many=20
> things that could be set-up, changed and deleted.
>=20
> Making the MIB writeable would have the consequence that we=20
> need to carefully review the status for each variable and=20
> table. We must define the row status and how it must be set=20
> and what each setting means. Furthermore we need to carefully=20
> elaborate the conformance section and need to discuss every=20
> writeable object in the security considerations. So it is a=20
> really big effort to make the MIB writeable so that it is=20
> secure to use it.
>=20
> Nevertheless, if the majority on the list has the opinion=20
> that it is really useful to have the MIB (especially the=20
> EXPORTER MIB) writeable than we would take that effort.
>=20
> Please keep in mind that the decision we take here would also=20
> affect the PSAMP MIB accordingly.
>=20
> Awaiting your comments,
>=20
> Thomas
>=20
> --=20
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
>=20

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



From ipfix-bounces@ietf.org Thu Oct 19 01:33:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaQW8-0002zR-0n; Thu, 19 Oct 2006 01:32:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQW7-0002yF-F9
	for ipfix@ietf.org; Thu, 19 Oct 2006 01:32:31 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaQW5-0006mF-Qh
	for ipfix@ietf.org; Thu, 19 Oct 2006 01:32:31 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9J5NBUL016486
	for ; Thu, 19 Oct 2006 01:23:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 07:32:22 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAI0Z3A
From: "Romascanu, Dan \(Dan\)" 
To: "Thomas Dietz" , 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

My opinion as a contributor is that write operations should be allowed
in this case. The analogy is the MIB objects that allow the control of
destination and filtering of the SNMP notifications. The SNMP framework
does allow for controls on these, the are several MIB modules that
include such objects and there is enough documentation and operational
experience in the SNMP world to show how this needs to be done.=20

Dan


=20
=20

> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> Sent: Thursday, October 19, 2006 4:19 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Dear Benoit, Kobayashi and others,
>=20
> I want to summarize 2 points that arose in the current=20
> discussion of the IPFIX MIB and poll the list for comments=20
> how we should proceed with it.
>=20
> It is a fundamental decision if we should allow the IPFIX=20
> devices to be configured via SNMP. For the collector there is=20
> not much to configure but for the exporter there are many=20
> things that could be set-up, changed and deleted.
>=20
> Making the MIB writeable would have the consequence that we=20
> need to carefully review the status for each variable and=20
> table. We must define the row status and how it must be set=20
> and what each setting means. Furthermore we need to carefully=20
> elaborate the conformance section and need to discuss every=20
> writeable object in the security considerations. So it is a=20
> really big effort to make the MIB writeable so that it is=20
> secure to use it.
>=20
> Nevertheless, if the majority on the list has the opinion=20
> that it is really useful to have the MIB (especially the=20
> EXPORTER MIB) writeable than we would take that effort.
>=20
> Please keep in mind that the decision we take here would also=20
> affect the PSAMP MIB accordingly.
>=20
> Awaiting your comments,
>=20
> Thomas
>=20
> --=20
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
>=20

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



From ipfix-bounces@ietf.org Thu Oct 19 02:11:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaR6x-0004o8-Fi; Thu, 19 Oct 2006 02:10:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaR6x-0004o0-3k
	for ipfix@ietf.org; Thu, 19 Oct 2006 02:10:35 -0400
Received: from mail-out-05.swisscom-eurospot.com ([83.97.120.94]
	helo=safetwo.sceur.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GaR6v-00077m-L6
	for ipfix@ietf.org; Thu, 19 Oct 2006 02:10:35 -0400
Received: from Harrington73653 (170-96-dsl-swisscomeurospot.infopact.nl
	[82.210.96.170])
	by safetwo.sceur.ch (Postfix) with ESMTP id F3FECA9C73;
	Thu, 19 Oct 2006 06:10:17 +0000 (UTC)
From: "David Harrington" 
To: "'Thomas Dietz'" , 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 02:07:56 -0400
Message-ID: <0b2a01c6f344$ec50c5c0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAJmIcg
X-Spam-Score: 1.9 (+)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi,

I generally think that technical decisions should not be based on how
much editing might be required for the security considerations. 

I also think your argument shows a problem with the current IESG
review of management security requirements. The security
considerations really should be written for the configuration
parameters whether they are configured using SNMP or some other
interface. You should NOT be allowed to not discuss the sensitivity of
a parameter just because you don't use SNMP to perform the
configuration. The current MIB security boilerplate reflects an aging
IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
technologies. The boilerplate really should be updated (and I'll work
with DanR to get it updated).

If ipfixFooParameter is sensitive if it is written using an SNMP SET,
because setting it to certain values could leave ipfix vulnerable to
man-in-the-middle attacks or could destabilize the network, then it is
also sensitive if it is configured to that value by an 
using Netconf, or a "set ipfix FooParameter=27" CLI command. The
difference is that we have a clear idea of how to secure it using
SNMPv3, and we provide boilerplate to help document it in a consistent
manner, and we do not have a clear idea of how to secure it using
other interfaces and do not have corresponding boilerplate for other
interfaces.

I think the MIB module should permit remote configuration using SNMP
so ipfix-related SNMP management applications can modify the
configuration to best meet their needs.

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> Sent: Wednesday, October 18, 2006 10:19 PM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Dear Benoit, Kobayashi and others,
> 
> I want to summarize 2 points that arose in the current 
> discussion of the
> IPFIX MIB and poll the list for comments how we should 
> proceed with it.
> 
> It is a fundamental decision if we should allow the IPFIX 
> devices to be
> configured via SNMP. For the collector there is not much to 
> configure but
> for the exporter there are many things that could be set-up, 
> changed and
> deleted.
> 
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We 
> must define the
> row status and how it must be set and what each setting 
> means. Furthermore
> we need to carefully elaborate the conformance section and 
> need to discuss
> every writeable object in the security considerations. So it 
> is a really big
> effort to make the MIB writeable so that it is secure to use it.
> 
> Nevertheless, if the majority on the list has the opinion 
> that it is really
> useful to have the MIB (especially the EXPORTER MIB) 
> writeable than we would
> take that effort.
> 
> Please keep in mind that the decision we take here would also 
> affect the
> PSAMP MIB accordingly.
> 
> Awaiting your comments,
> 
> Thomas
> 
> -- 
> Thomas Dietz                       E-mail:
Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
> 



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



From ipfix-bounces@ietf.org Thu Oct 19 02:11:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaR6x-0004o8-Fi; Thu, 19 Oct 2006 02:10:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaR6x-0004o0-3k
	for ipfix@ietf.org; Thu, 19 Oct 2006 02:10:35 -0400
Received: from mail-out-05.swisscom-eurospot.com ([83.97.120.94]
	helo=safetwo.sceur.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GaR6v-00077m-L6
	for ipfix@ietf.org; Thu, 19 Oct 2006 02:10:35 -0400
Received: from Harrington73653 (170-96-dsl-swisscomeurospot.infopact.nl
	[82.210.96.170])
	by safetwo.sceur.ch (Postfix) with ESMTP id F3FECA9C73;
	Thu, 19 Oct 2006 06:10:17 +0000 (UTC)
From: "David Harrington" 
To: "'Thomas Dietz'" , 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 02:07:56 -0400
Message-ID: <0b2a01c6f344$ec50c5c0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAJmIcg
X-Spam-Score: 1.9 (+)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi,

I generally think that technical decisions should not be based on how
much editing might be required for the security considerations. 

I also think your argument shows a problem with the current IESG
review of management security requirements. The security
considerations really should be written for the configuration
parameters whether they are configured using SNMP or some other
interface. You should NOT be allowed to not discuss the sensitivity of
a parameter just because you don't use SNMP to perform the
configuration. The current MIB security boilerplate reflects an aging
IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
technologies. The boilerplate really should be updated (and I'll work
with DanR to get it updated).

If ipfixFooParameter is sensitive if it is written using an SNMP SET,
because setting it to certain values could leave ipfix vulnerable to
man-in-the-middle attacks or could destabilize the network, then it is
also sensitive if it is configured to that value by an 
using Netconf, or a "set ipfix FooParameter=27" CLI command. The
difference is that we have a clear idea of how to secure it using
SNMPv3, and we provide boilerplate to help document it in a consistent
manner, and we do not have a clear idea of how to secure it using
other interfaces and do not have corresponding boilerplate for other
interfaces.

I think the MIB module should permit remote configuration using SNMP
so ipfix-related SNMP management applications can modify the
configuration to best meet their needs.

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> Sent: Wednesday, October 18, 2006 10:19 PM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Dear Benoit, Kobayashi and others,
> 
> I want to summarize 2 points that arose in the current 
> discussion of the
> IPFIX MIB and poll the list for comments how we should 
> proceed with it.
> 
> It is a fundamental decision if we should allow the IPFIX 
> devices to be
> configured via SNMP. For the collector there is not much to 
> configure but
> for the exporter there are many things that could be set-up, 
> changed and
> deleted.
> 
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We 
> must define the
> row status and how it must be set and what each setting 
> means. Furthermore
> we need to carefully elaborate the conformance section and 
> need to discuss
> every writeable object in the security considerations. So it 
> is a really big
> effort to make the MIB writeable so that it is secure to use it.
> 
> Nevertheless, if the majority on the list has the opinion 
> that it is really
> useful to have the MIB (especially the EXPORTER MIB) 
> writeable than we would
> take that effort.
> 
> Please keep in mind that the decision we take here would also 
> affect the
> PSAMP MIB accordingly.
> 
> Awaiting your comments,
> 
> Thomas
> 
> -- 
> Thomas Dietz                       E-mail:
Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
> 



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



From ipfix-bounces@ietf.org Thu Oct 19 05:47:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaUTl-0005r6-Nj; Thu, 19 Oct 2006 05:46:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUTk-0005qy-56
	for ipfix@ietf.org; Thu, 19 Oct 2006 05:46:20 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUTi-0003ZP-Nj
	for ipfix@ietf.org; Thu, 19 Oct 2006 05:46:20 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9J9ivd11915; Thu, 19 Oct 2006 11:44:57 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 11:46:19 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA147574A@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLA
From: "Zseby, Tanja" 
To: "Thomas Dietz" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Thomas,

in my opinion it would be extremely useful to have a writeable MIB that
would allow exporter configuration by SNMP.

Kind regards,
Tanja=20

> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> Sent: Thursday, October 19, 2006 4:19 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Dear Benoit, Kobayashi and others,
>=20
> I want to summarize 2 points that arose in the current=20
> discussion of the IPFIX MIB and poll the list for comments=20
> how we should proceed with it.
>=20
> It is a fundamental decision if we should allow the IPFIX=20
> devices to be configured via SNMP. For the collector there is=20
> not much to configure but for the exporter there are many=20
> things that could be set-up, changed and deleted.
>=20
> Making the MIB writeable would have the consequence that we=20
> need to carefully review the status for each variable and=20
> table. We must define the row status and how it must be set=20
> and what each setting means. Furthermore we need to carefully=20
> elaborate the conformance section and need to discuss every=20
> writeable object in the security considerations. So it is a=20
> really big effort to make the MIB writeable so that it is=20
> secure to use it.
>=20
> Nevertheless, if the majority on the list has the opinion=20
> that it is really useful to have the MIB (especially the=20
> EXPORTER MIB) writeable than we would take that effort.
>=20
> Please keep in mind that the decision we take here would also=20
> affect the PSAMP MIB accordingly.
>=20
> Awaiting your comments,
>=20
> Thomas
>=20
> --=20
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
>=20

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



From ipfix-bounces@ietf.org Thu Oct 19 05:47:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaUTl-0005r6-Nj; Thu, 19 Oct 2006 05:46:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUTk-0005qy-56
	for ipfix@ietf.org; Thu, 19 Oct 2006 05:46:20 -0400
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUTi-0003ZP-Nj
	for ipfix@ietf.org; Thu, 19 Oct 2006 05:46:20 -0400
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id
	k9J9ivd11915; Thu, 19 Oct 2006 11:44:57 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 11:46:19 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA147574A@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLA
From: "Zseby, Tanja" 
To: "Thomas Dietz" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Thomas,

in my opinion it would be extremely useful to have a writeable MIB that
would allow exporter configuration by SNMP.

Kind regards,
Tanja=20

> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> Sent: Thursday, October 19, 2006 4:19 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Dear Benoit, Kobayashi and others,
>=20
> I want to summarize 2 points that arose in the current=20
> discussion of the IPFIX MIB and poll the list for comments=20
> how we should proceed with it.
>=20
> It is a fundamental decision if we should allow the IPFIX=20
> devices to be configured via SNMP. For the collector there is=20
> not much to configure but for the exporter there are many=20
> things that could be set-up, changed and deleted.
>=20
> Making the MIB writeable would have the consequence that we=20
> need to carefully review the status for each variable and=20
> table. We must define the row status and how it must be set=20
> and what each setting means. Furthermore we need to carefully=20
> elaborate the conformance section and need to discuss every=20
> writeable object in the security considerations. So it is a=20
> really big effort to make the MIB writeable so that it is=20
> secure to use it.
>=20
> Nevertheless, if the majority on the list has the opinion=20
> that it is really useful to have the MIB (especially the=20
> EXPORTER MIB) writeable than we would take that effort.
>=20
> Please keep in mind that the decision we take here would also=20
> affect the PSAMP MIB accordingly.
>=20
> Awaiting your comments,
>=20
> Thomas
>=20
> --=20
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 4342-128
> NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de
>=20

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



From ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5L-0002zc-1t; Thu, 19 Oct 2006 06:25:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5J-0002yl-Nd
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:09 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaV2h-0001yH-Fy
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:22:29 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 643342000296;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19258-06; Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 42F532000294;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:22:16 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4C00@mx1.office>
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA147574A@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLAAAE27KA=
From: "Thomas Dietz" 
To: "Zseby, Tanja" ,
	
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2143201437=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2143201437==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0051_01C6F379.3724F880"

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Tanja,

It may be usefull, but I am not sure if it will be used by many people. It
is a complex task, you cannot do it easily by hand and to write a management
program (element manager or what soever) which does it for you is also a
rather tidious and complex work. In most cases the setup by a command line
interface is much faster and less error prone than using SNMP. I am quite
sure most people who configure e.g. a cisco router do it by command line
even though they might be able to do most of the work by SNMP.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: Zseby, Tanja [mailto:Tanja.Zseby@fokus.fraunhofer.de] 
> Sent: Thursday, October 19, 2006 11:46 AM
> To: Thomas Dietz; ipfix@ietf.org
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi Thomas,
> 
> in my opinion it would be extremely useful to have a 
> writeable MIB that
> would allow exporter configuration by SNMP.
> 
> Kind regards,
> Tanja 
> 
> > -----OriginalFrom ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5L-0002zc-1t; Thu, 19 Oct 2006 06:25:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5J-0002yl-Nd
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:09 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaV2h-0001yH-Fy
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:22:29 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 643342000296;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19258-06; Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 42F532000294;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:22:16 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4C00@mx1.office>
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA147574A@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLAAAE27KA=
From: "Thomas Dietz" 
To: "Zseby, Tanja" ,
	
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2143201437=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2143201437==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0051_01C6F379.3724F880"

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Tanja,

It may be usefull, but I am not sure if it will be used by many people. It
is a complex task, you cannot do it easily by hand and to write a management
program (element manager or what soever) which does it for you is also a
rather tidious and complex work. In most cases the setup by a command line
interface is much faster and less error prone than using SNMP. I am quite
sure most people who configure e.g. a cisco router do it by command line
even though they might be able to do most of the work by SNMP.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: Zseby, Tanja [mailto:Tanja.Zseby@fokus.fraunhofer.de] 
> Sent: Thursday, October 19, 2006 11:46 AM
> To: Thomas Dietz; ipfix@ietf.org
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi Thomas,
> 
> in my opinion it would be extremely useful to have a 
> writeable MIB that
> would allow exporter configuration by SNMP.
> 
> Kind regards,
> Tanja 
> 
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Thursday, October 19, 2006 4:19 AM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the IPFIX MIB and poll the list for comments 
> > how we should proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be configured via SNMP. For the collector there is 
> > not much to configure but for the exporter there are many 
> > things that could be set-up, changed and deleted.
> > 
> > Making the MIB writeable would have the consequence that we 
> > need to carefully review the status for each variable and 
> > table. We must define the row status and how it must be set 
> > and what each setting means. Furthermore we need to carefully 
> > elaborate the conformance section and need to discuss every 
> > writeable object in the security considerations. So it is a 
> > really big effort to make the MIB writeable so that it is 
> > secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really useful to have the MIB (especially the 
> > EXPORTER MIB) writeable than we would take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail: 
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzz Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Thursday, October 19, 2006 4:19 AM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the IPFIX MIB and poll the list for comments 
> > how we should proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be configured via SNMP. For the collector there is 
> > not much to configure but for the exporter there are many 
> > things that could be set-up, changed and deleted.
> > 
> > Making the MIB writeable would have the consequence that we 
> > need to carefully review the status for each variable and 
> > table. We must define the row status and how it must be set 
> > and what each setting means. Furthermore we need to carefully 
> > elaborate the conformance section and need to discuss every 
> > writeable object in the security considerations. So it is a 
> > really big effort to make the MIB writeable so that it is 
> > secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really useful to have the MIB (especially the 
> > EXPORTER MIB) writeable than we would take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail: 
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAy
MjE2WjAjBgkqhkiG9w0BCQQxFgQUVT8c/aUFZQMKgzfOQ/HQuVSEnUcwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAJQV60U4uJE6a6xJu7qs2HSg
RhiDBF2EIGoiE72mCzzxiYKeqWawJ4IAi9gSzEgPEEYKPnKglYNG6npaIIWUzpE8Lp5I923uP321
Ib1J8o5SXxmLYfhQyNNcOL4n3h/8kU2B3YFffvshekv3TWhkhSYZTIfml6MaV5yrlm0VZFvEs8Qd
sfOphbwC6fSaw+X3fp6AvBx8IG9oq8s4W7GDh/vQvJviTVgXti9Aq5ozfnrE1q6B1h04+MRLZn0d
BuY7iQtHPjca4A3V7uLHxs6QbpF099T1lJUtV9aRBgITRYHP5L7tENolizYxLonKhE5oZfYmM0d8
1ftri1c5Ncd4Jz8AAAAAAAA=

------=_NextPart_000_0051_01C6F379.3724F880--


--===============2143201437==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============2143201437==--


From ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5a-0003Kz-9i; Thu, 19 Oct 2006 06:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5Y-0003IP-FB
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:24 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUyT-0001Oi-1E
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:18:06 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 93D082000296;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19115-09; Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 704612000294;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:17:51 +0200
Message-D7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAy
MjE2WjAjBgkqhkiG9w0BCQQxFgQUVT8c/aUFZQMKgzfOQ/HQuVSEnUcwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAJQV60U4uJE6a6xJu7qs2HSg
RhiDBF2EIGoiE72mCzzxiYKeqWawJ4IAi9gSzEgPEEYKPnKglYNG6npaIIWUzpE8Lp5I923uP321
Ib1J8o5SXxmLYfhQyNNcOL4n3h/8kU2B3YFffvshekv3TWhkhSYZTIfml6MaV5yrlm0VZFvEs8Qd
sfOphbwC6fSaw+X3fp6AvBx8IG9oq8s4W7GDh/vQvJviTVgXti9Aq5ozfnrE1q6B1h04+MRLZn0d
BuY7iQtHPjca4A3V7uLHxs6QbpF099T1lJUtV9aRBgITRYHP5L7tENolizYxLonKhE5oZfYmM0d8
1ftri1c5Ncd4Jz8AAAAAAAA=

------=_NextPart_000_0051_01C6F379.3724F880--


--===============2143201437==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============2143201437==--


From ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5a-0003Kz-9i; Thu, 19 Oct 2006 06:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5Y-0003IP-FB
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:24 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUyT-0001Oi-1E
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:18:06 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 93D082000296;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19115-09; Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 704612000294;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:17:51 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4BFD@mx1.office>
In-Reply-To: <0b2a01c6f344$ec50c5c0$0600a8c0@china.huawei.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAJmIcgAAiJmVA=
From: "Thomas Dietz" 
To: "David Harrington" , 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0984205100=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0984205100==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_004C_01C6F378.98F18CF0"

This is a multi-part message in MIME format.

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear David,

I don't want to base the decision whether that MIB should be writeable or
not on the amount of work. I just wanted to point out that we have to
carefully review every object to decide which status it has to get and that
we have to consider also the security aspects on the decision to make an
object writeable.

I also want that you take into account that the IPFIX MIB will get rather
complex (even if we try to keep it as simple as possible). You need to
carefully set up several tables in the right order and link them with the
right indexes. I just wanted that you make up your mind and really think
about it carefully.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Thursday, October 19, 2006 8:08 AM
> To: Thomas Dietz; ipfix@ietf.org
> Cc: 'Romascanu, Dan (Dan)'
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi,
> 
> I generally think that technical decisions should not be based on how
> much editing might be required for the security considerations. 
> 
> I also think your argument shows a problem with the current IESG
> review of management security requirements. The security
> considerations really should be written for the configuration
> parameters whether they are configured using SNMP or some other
> interface. You should NOT be allowed to not discuss the sensitivity of
> a parameter just because you don't use SNMP to perform the
> configuration. The current MIB security boilerplate reflects an aging
> IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
> technologies. The boilerplate really should be updated (and I'll work
> with DanR to get it updated).
> 
> If ipfixFooParameter is sensitive if it is written using an SNMP SET,
> because setting it to certain values could leave ipfix vulnerable to
> man-in-the-middle attacks or could destabilize the network, then it is
> also sensitive if it is configured to that value by an 
> using Netconf, or a "set ipfix FooParameter=27" CLI command. The
> difference is that we have a clear idea of how to secure it using
> SNMPv3, and we provide boilerplate to help document it in a consistent
> manner, and we do not have a clear idea of how tID: <113091BD57179D4491C19DA7E10CD6963A4BFD@mx1.office>
In-Reply-To: <0b2a01c6f344$ec50c5c0$0600a8c0@china.huawei.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAJmIcgAAiJmVA=
From: "Thomas Dietz" 
To: "David Harrington" , 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0984205100=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0984205100==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_004C_01C6F378.98F18CF0"

This is a multi-part message in MIME format.

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear David,

I don't want to base the decision whether that MIB should be writeable or
not on the amount of work. I just wanted to point out that we have to
carefully review every object to decide which status it has to get and that
we have to consider also the security aspects on the decision to make an
object writeable.

I also want that you take into account that the IPFIX MIB will get rather
complex (even if we try to keep it as simple as possible). You need to
carefully set up several tables in the right order and link them with the
right indexes. I just wanted that you make up your mind and really think
about it carefully.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Thursday, October 19, 2006 8:08 AM
> To: Thomas Dietz; ipfix@ietf.org
> Cc: 'Romascanu, Dan (Dan)'
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi,
> 
> I generally think that technical decisions should not be based on how
> much editing might be required for the security considerations. 
> 
> I also think your argument shows a problem with the current IESG
> review of management security requirements. The security
> considerations really should be written for the configuration
> parameters whether they are configured using SNMP or some other
> interface. You should NOT be allowed to not discuss the sensitivity of
> a parameter just because you don't use SNMP to perform the
> configuration. The current MIB security boilerplate reflects an aging
> IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
> technologies. The boilerplate really should be updated (and I'll work
> with DanR to get it updated).
> 
> If ipfixFooParameter is sensitive if it is written using an SNMP SET,
> because setting it to certain values could leave ipfix vulnerable to
> man-in-the-middle attacks or could destabilize the network, then it is
> also sensitive if it is configured to that value by an 
> using Netconf, or a "set ipfix FooParameter=27" CLI command. The
> difference is that we have a clear idea of how to secure it using
> SNMPv3, and we provide boilerplate to help document it in a consistent
> manner, and we do not have a clear idea of how to secure it using
> other interfaces and do not have corresponding boilerplate for other
> interfaces.
> 
> I think the MIB module should permit remote configuration using SNMP
> so ipfix-related SNMP management applications can modify the
> configuration to best meet their needs.
> 
> David Harrington
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Wednesday, October 18, 2006 10:19 PM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the
> > IPFIX MIB and poll the list for comments how we should 
> > proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be
> > configured via SNMP. For the collector there is not much to 
> > configure but
> > for the exporter there are many things that could be set-up, 
> > changed and
> > deleted.
> > 
> > Making the MIB writeable would have the consequence that we need to
> > carefully review the status for each variable and table. We 
> > must define the
> > row status and how it must be set and what each setting 
> > means. Furthermore
> > we need to carefully elaborate the conformance section and 
> > need to discuss
> > every writeable object in the security considerations. So it 
> > is a really big
> > effort to make the MIB writeable so that it is secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really
> > useful to have the MIB (especially the EXPORTER MIB) 
> > writeable than we would
> > take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the
> > PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail:
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 
> 
> 

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2o secure it using
> other interfaces and do not have corresponding boilerplate for other
> interfaces.
> 
> I think the MIB module should permit remote configuration using SNMP
> so ipfix-related SNMP management applications can modify the
> configuration to best meet their needs.
> 
> David Harrington
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Wednesday, October 18, 2006 10:19 PM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the
> > IPFIX MIB and poll the list for comments how we should 
> > proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be
> > configured via SNMP. For the collector there is not much to 
> > configure but
> > for the exporter there are many things that could be set-up, 
> > changed and
> > deleted.
> > 
> > Making the MIB writeable would have the consequence that we need to
> > carefully review the status for each variable and table. We 
> > must define the
> > row status and how it must be set and what each setting 
> > means. Furthermore
> > we need to carefully elaborate the conformance section and 
> > need to discuss
> > every writeable object in the security considerations. So it 
> > is a really big
> > effort to make the MIB writeable so that it is secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really
> > useful to have the MIB (especially the EXPORTER MIB) 
> > writeable than we would
> > take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the
> > PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail:
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 
> 
> 

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAx
NzUxWjAjBgkqhkiG9w0BCQQxFgQUd1ylak3IA+4e5VLan1Dt5SrGspswZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAA1A4Mqz0L8ZfSMTLCN1hgWz
22kWdX6P9YBKXbEvygmUHwXfSQLEFGG+VtOT6uU83ZG4RqHo5ezZT8GBS9HmaPIuZ1wt+qVtWtpU
FQ6pPr7v8UJLP0jvIQO9fNwP6qXYUEQS6C8qzk9wc15PIJvLWXCqXzBIXL+EsdcgOaCdsXbelqI0
PQyQ13QuOim/vyp1Ct8mJKyHIr7ahOcxOdekWnMKwFPBwV8VJ4gf2xGF7PqydAy2oho/2HqJ9CiC
0s+2XeZjPRIoDda7msAOm0mlEtlBNzeX7viZkaYNB6nToC9EubCPBicp+a8AGfdCaHQ1Z+ZqCLHX
de4FqPc/TWVpDDYAAAAAAAA=

------=_NextPart_000_004C_01C6F378.98F18CF0--


--===============0984205100==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0984205100==--






VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAx
NzUxWjAjBgkqhkiG9w0BCQQxFgQUd1ylak3IA+4e5VLan1Dt5SrGspswZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAA1A4Mqz0L8ZfSMTLCN1hgWz
22kWdX6P9YBKXbEvygmUHwXfSQLEFGG+VtOT6uU83ZG4RqHo5ezZT8GBS9HmaPIuZ1wt+qVtWtpU
FQ6pPr7v8UJLP0jvIQO9fNwP6qXYUEQS6C8qzk9wc15PIJvLWXCqXzBIXL+EsdcgOaCdsXbelqI0
PQyQ13QuOim/vyp1Ct8mJKyHIr7ahOcxOdekWnMKwFPBwV8VJ4gf2xGF7PqydAy2oho/2HqJ9CiC
0s+2XeZjPRIoDda7msAOm0mlEtlBNzeX7viZkaYNB6nToC9EubCPBicp+a8AGfdCaHQ1Z+ZqCLHX
de4FqPc/TWVpDDYAAAAAAAA=

------=_NextPart_000_004C_01C6F378.98F18CF0--


--===============0984205100==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0984205100==--






From ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5L-0002zc-1t; Thu, 19 Oct 2006 06:25:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5J-0002yl-Nd
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:09 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaV2h-0001yH-Fy
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:22:29 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 643342000296;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19258-06; Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 42F532000294;
	Thu, 19 Oct 2006 12:22:57 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:22:16 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4C00@mx1.office>
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA147574A@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLAAAE27KA=
From: "Thomas Dietz" 
To: "Zseby, Tanja" ,
	
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2143201437=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2143201437==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0051_01C6F379.3724F880"

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Tanja,

It may be usefull, but I am not sure if it will be used by many people. It
is a complex task, you cannot do it easily by hand and to write a management
program (element manager or what soever) which does it for you is also a
rather tidious and complex work. In most cases the setup by a command line
interface is much faster and less error prone than using SNMP. I am quite
sure most people who configure e.g. a cisco router do it by command line
even though they might be able to do most of the work by SNMP.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: Zseby, Tanja [mailto:Tanja.Zseby@fokus.fraunhofer.de] 
> Sent: Thursday, October 19, 2006 11:46 AM
> To: Thomas Dietz; ipfix@ietf.org
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi Thomas,
> 
> in my opinion it would be extremely useful to have a 
> writeable MIB that
> would allow exporter configuration by SNMP.
> 
> Kind regards,
> Tanja 
> 
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Thursday, October 19, 2006 4:19 AM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the IPFIX MIB and poll the list for comments 
> > how we should proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be configured via SNMP. For the collector there is 
> > not much to configure but for the exporter there are many 
> > things that could be set-up, changed and deleted.
> > 
> > Making the MIB writeable would have the consequence that we 
> > need to carefully review the status for each variable and 
> > table. We must define the row status and how it must be set 
> > and what each setting means. Furthermore we need to carefully 
> > elaborate the conformance section and need to discuss every 
> > writeable object in the security considerations. So it is a 
> > really big effort to make the MIB writeable so that it is 
> > secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really useful to have the MIB (especially the 
> > EXPORTER MIB) writeable than we would take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail: 
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 

------=_NextPart_000_0051_01C6F379.3724F880
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAy
MjE2WjAjBgkqhkiG9w0BCQQxFgQUVT8c/aUFZQMKgzfOQ/HQuVSEnUcwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAJQV60U4uJE6a6xJu7qs2HSg
RhiDBF2EIGoiE72mCzzxiYKeqWawJ4IAi9gSzEgPEEYKPnKglYNG6npaIIWUzpE8Lp5I923uP321
Ib1J8o5SXxmLYfhQyNNcOL4n3h/8kU2B3YFffvshekv3TWhkhSYZTIfml6MaV5yrlm0VZFvEs8Qd
sfOphbwC6fSaw+X3fp6AvBx8IG9oq8s4W7GDh/vQvJviTVgXti9Aq5ozfnrE1q6B1h04+MRLZn0d
BuY7iQtHPjca4A3V7uLHxs6QbpF099T1lJUtV9aRBgITRYHP5L7tENolizYxLonKhE5oZfYmM0d8
1ftri1c5Ncd4Jz8AAAAAAAA=

------=_NextPart_000_0051_01C6F379.3724F880--


--===============2143201437==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============2143201437==--




From ipfix-bounces@ietf.org Thu Oct 19 06:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaV5a-0003Kz-9i; Thu, 19 Oct 2006 06:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5Y-0003IP-FB
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:25:24 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUyT-0001Oi-1E
	for ipfix@ietf.org; Thu, 19 Oct 2006 06:18:06 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 93D082000296;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 19115-09; Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 704612000294;
	Thu, 19 Oct 2006 12:18:32 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 12:17:51 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4BFD@mx1.office>
In-Reply-To: <0b2a01c6f344$ec50c5c0$0600a8c0@china.huawei.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAJmIcgAAiJmVA=
From: "Thomas Dietz" 
To: "David Harrington" , 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0984205100=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0984205100==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_004C_01C6F378.98F18CF0"

This is a multi-part message in MIME format.

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear David,

I don't want to base the decision whether that MIB should be writeable or
not on the amount of work. I just wanted to point out that we have to
carefully review every object to decide which status it has to get and that
we have to consider also the security aspects on the decision to make an
object writeable.

I also want that you take into account that the IPFIX MIB will get rather
complex (even if we try to keep it as simple as possible). You need to
carefully set up several tables in the right order and link them with the
right indexes. I just wanted that you make up your mind and really think
about it carefully.

Best Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Thursday, October 19, 2006 8:08 AM
> To: Thomas Dietz; ipfix@ietf.org
> Cc: 'Romascanu, Dan (Dan)'
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi,
> 
> I generally think that technical decisions should not be based on how
> much editing might be required for the security considerations. 
> 
> I also think your argument shows a problem with the current IESG
> review of management security requirements. The security
> considerations really should be written for the configuration
> parameters whether they are configured using SNMP or some other
> interface. You should NOT be allowed to not discuss the sensitivity of
> a parameter just because you don't use SNMP to perform the
> configuration. The current MIB security boilerplate reflects an aging
> IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
> technologies. The boilerplate really should be updated (and I'll work
> with DanR to get it updated).
> 
> If ipfixFooParameter is sensitive if it is written using an SNMP SET,
> because setting it to certain values could leave ipfix vulnerable to
> man-in-the-middle attacks or could destabilize the network, then it is
> also sensitive if it is configured to that value by an 
> using Netconf, or a "set ipfix FooParameter=27" CLI command. The
> difference is that we have a clear idea of how to secure it using
> SNMPv3, and we provide boilerplate to help document it in a consistent
> manner, and we do not have a clear idea of how to secure it using
> other interfaces and do not have corresponding boilerplate for other
> interfaces.
> 
> I think the MIB module should permit remote configuration using SNMP
> so ipfix-related SNMP management applications can modify the
> configuration to best meet their needs.
> 
> David Harrington
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] 
> > Sent: Wednesday, October 18, 2006 10:19 PM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> > 
> > Dear Benoit, Kobayashi and others,
> > 
> > I want to summarize 2 points that arose in the current 
> > discussion of the
> > IPFIX MIB and poll the list for comments how we should 
> > proceed with it.
> > 
> > It is a fundamental decision if we should allow the IPFIX 
> > devices to be
> > configured via SNMP. For the collector there is not much to 
> > configure but
> > for the exporter there are many things that could be set-up, 
> > changed and
> > deleted.
> > 
> > Making the MIB writeable would have the consequence that we need to
> > carefully review the status for each variable and table. We 
> > must define the
> > row status and how it must be set and what each setting 
> > means. Furthermore
> > we need to carefully elaborate the conformance section and 
> > need to discuss
> > every writeable object in the security considerations. So it 
> > is a really big
> > effort to make the MIB writeable so that it is secure to use it.
> > 
> > Nevertheless, if the majority on the list has the opinion 
> > that it is really
> > useful to have the MIB (especially the EXPORTER MIB) 
> > writeable than we would
> > take that effort.
> > 
> > Please keep in mind that the decision we take here would also 
> > affect the
> > PSAMP MIB accordingly.
> > 
> > Awaiting your comments,
> > 
> > Thomas
> > 
> > -- 
> > Thomas Dietz                       E-mail:
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> > 
> 
> 
> 

------=_NextPart_000_004C_01C6F378.98F18CF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE5MTAx
NzUxWjAjBgkqhkiG9w0BCQQxFgQUd1ylak3IA+4e5VLan1Dt5SrGspswZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAA1A4Mqz0L8ZfSMTLCN1hgWz
22kWdX6P9YBKXbEvygmUHwXfSQLEFGG+VtOT6uU83ZG4RqHo5ezZT8GBS9HmaPIuZ1wt+qVtWtpU
FQ6pPr7v8UJLP0jvIQO9fNwP6qXYUEQS6C8qzk9wc15PIJvLWXCqXzBIXL+EsdcgOaCdsXbelqI0
PQyQ13QuOim/vyp1Ct8mJKyHIr7ahOcxOdekWnMKwFPBwV8VJ4gf2xGF7PqydAy2oho/2HqJ9CiC
0s+2XeZjPRIoDda7msAOm0mlEtlBNzeX7viZkaYNB6nToC9EubCPBicp+a8AGfdCaHQ1Z+ZqCLHX
de4FqPc/TWVpDDYAAAAAAAA=

------=_NextPart_000_004C_01C6F378.98F18CF0--


--===============0984205100==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0984205100==--




From ipfix-bounces@ietf.org Thu Oct 19 09:25:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaXsk-0001JA-Vy; Thu, 19 Oct 2006 09:24:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXsk-0001Ht-1A
	for ipfix@ietf.org; Thu, 19 Oct 2006 09:24:22 -0400
Received: from smtp-bedford.mitre.org ([192.160.51.76])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXsa-0003xE-2a
	for ipfix@ietf.org; Thu, 19 Oct 2006 09:24:22 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id
	k9JDO9sK009656 for ; Thu, 19 Oct 2006 09:24:09 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (Postfix) with ESMTP id 8122BBF01
	for ; Thu, 19 Oct 2006 09:24:09 -0400 (EDT)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3])
	by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id
	k9JDO9rZ009631; Thu, 19 Oct 2006 09:24:09 -0400
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:24:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 09:24:08 -0400
Message-ID: <4915F014FDD99049A9C3A8C1B832004F01542CA6@IMCSRV2.MITRE.ORG>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4C00@mx1.office>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLAAAE27KAABTbrMA==
From: "Natale, Bob" 
To: "Thomas Dietz" 
X-OriginalArrivalTime: 19 Oct 2006 13:24:08.0964 (UTC)
	FILETIME=[DBBE2440:01C6F381]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Thomas,

Your observations below (and in your subsequent follow-up to Dave
Harrington's post) suggest a kind of "vicious circle" thinking that
results in:

   - SNMP applications being "unuseful"
   - because SNMP MIBs are (typically) less rich in L7 aspects than
they could be
   - because SNMP applications are "not used by many people".

In reality, however, such applications are "unuseful" because they are
"unusable"; they are "unusable" because the MIBs were not designed with
L7 "usability" in mind.

The key to an SNMP application's usability, particularly at the human
operator level, is the richness of the MIB relative to the management
operations applicable to the managed entities covered by the MIB.
This, IMHO, is where SNMP has yet to reach its full potential.  In this
view, a MIB design team should include consideration of this basic
question at the outset:  "What application-level operations are
essential and what others would be helpful, from the operational
perspective?"  Delivering those operations via an SNMP MIB will often
require design of and support for "higher-order" MIB objects that
aggregate (in various ways) multiple atomic MIB objects, that
instrument "behaviors", that summarize "state", and so forth.

Two other things I would like to note from my experience (which might
not be typical, I suppose):

1. For a fair number of moderately complex real-world applications
(e.g., configuring charging policies on an IP services switch in an
early IMS-like network context) using CLI is definitely NOT "faster and
less error-prone" than using an application-level tool, regardless of
the underlying protocol used by that app (SNMP, TL-1, CORBA, WSDL/SOAP,
etc.)

2. Given a fairly "rich" MIB (per above comments) there are many good
and accessible SNMP "management consoles" that can provide a reasonable
user interface w/o writing a specialized application.  (Yes, there are
definitely exceptions -- but in practice most of those exceptions exist
because the underlying MIBs are just too primitive for efficient
app-level operations.)

[Btw, I heartily concur with Dave's recommendation that MIB "Security
Consideration" sections should not limit their guidance to SNMP
operations only.  Long overdue.]

Cheers,
BobN

-----Original Message-----
From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
Sent: Thursday, October 19, 2006 6:22 AM
To: Zseby, Tanja; ipfix@ietf.org
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?

Dear Tanja,

It may be usefull, but I am not sure if it will be used by many people.
It
is a complex task, you cannot do it easily by hand and to write a
management
program (element manager or what soever) which does it for you is also
a
rather tidious and complex work. In most cases the setup by a command
line
interface is much faster and less error prone than using SNMP. I am
quite
sure most people who configure e.g. a cisco router do it by command
line
even though they might be able to do most of the work by SNMP.

Best Regards,

Thomas

--=20
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
=20

> -----Original Message-----
> From: Zseby, Tanja [mailto:Tanja.Zseby@fokus.fraunhofer.de]=20
> Sent: Thursday, October 19, 2006 11:46 AM
> To: Thomas Dietz; ipfix@ietf.org
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Hi Thomas,
>=20
> in my opinion it would be extremely useful to have a=20
> writeable MIB that
> would allow exporter configuration by SNMP.
>=20
> Kind regards,
> Tanja=20
>=20
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> > Sent: Thursday, October 19, 2006 4:19 AM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> >=20
> > Dear Benoit, Kobayashi and others,
> >=20
> > I want to summarize 2 points that arose in the current=20
> > discussion of the IPFIX MIB and poll the list for comments=20
> > how we should proceed with it.
> >=20
> > It is a fundamental decision if we should allow the IPFIX=20
> > devices to be configured via SNMP. For the collector there is=20
> > not much to configure but for the exporter there are many=20
> > things that could be set-up, changed and deleted.
> >=20
> > Making the MIB writeable would have the consequence that we=20
> > need to carefully review the status for each variable and=20
> > table. We must define the row status and how it must be set=20
> > and what each setting means. Furthermore we need to carefully=20
> > elaborate the conformance section and need to discuss every=20
> > writeable object in the security considerations. So it is a=20
> > really big effort to make the MIB writeable so that it is=20
> > secure to use it.
> >=20
> > Nevertheless, if the majority on the list has the opinion=20
> > that it is really useful to have the MIB (especially the=20
> > EXPORTER MIB) writeable than we would take that effort.
> >=20
> > Please keep in mind that the decision we take here would also=20
> > affect the PSAMP MIB accordingly.
> >=20
> > Awaiting your comments,
> >=20
> > Thomas
> >=20
> > --=20
> > Thomas Dietz                       E-mail:=20
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> >=20
>=20

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



From ipfix-bounces@ietf.org Thu Oct 19 09:25:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaXsk-0001JA-Vy; Thu, 19 Oct 2006 09:24:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXsk-0001Ht-1A
	for ipfix@ietf.org; Thu, 19 Oct 2006 09:24:22 -0400
Received: from smtp-bedford.mitre.org ([192.160.51.76])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXsa-0003xE-2a
	for ipfix@ietf.org; Thu, 19 Oct 2006 09:24:22 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id
	k9JDO9sK009656 for ; Thu, 19 Oct 2006 09:24:09 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (Postfix) with ESMTP id 8122BBF01
	for ; Thu, 19 Oct 2006 09:24:09 -0400 (EDT)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3])
	by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id
	k9JDO9rZ009631; Thu, 19 Oct 2006 09:24:09 -0400
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:24:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Thu, 19 Oct 2006 09:24:08 -0400
Message-ID: <4915F014FDD99049A9C3A8C1B832004F01542CA6@IMCSRV2.MITRE.ORG>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4C00@mx1.office>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: AcbzG7i0YBpMuLDHTtC5crwfHHqPrgAR0nLAAAE27KAABTbrMA==
From: "Natale, Bob" 
To: "Thomas Dietz" 
X-OriginalArrivalTime: 19 Oct 2006 13:24:08.0964 (UTC)
	FILETIME=[DBBE2440:01C6F381]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Thomas,

Your observations below (and in your subsequent follow-up to Dave
Harrington's post) suggest a kind of "vicious circle" thinking that
results in:

   - SNMP applications being "unuseful"
   - because SNMP MIBs are (typically) less rich in L7 aspects than
they could be
   - because SNMP applications are "not used by many people".

In reality, however, such applications are "unuseful" because they are
"unusable"; they are "unusable" because the MIBs were not designed with
L7 "usability" in mind.

The key to an SNMP application's usability, particularly at the human
operator level, is the richness of the MIB relative to the management
operations applicable to the managed entities covered by the MIB.
This, IMHO, is where SNMP has yet to reach its full potential.  In this
view, a MIB design team should include consideration of this basic
question at the outset:  "What application-level operations are
essential and what others would be helpful, from the operational
perspective?"  Delivering those operations via an SNMP MIB will often
require design of and support for "higher-order" MIB objects that
aggregate (in various ways) multiple atomic MIB objects, that
instrument "behaviors", that summarize "state", and so forth.

Two other things I would like to note from my experience (which might
not be typical, I suppose):

1. For a fair number of moderately complex real-world applications
(e.g., configuring charging policies on an IP services switch in an
early IMS-like network context) using CLI is definitely NOT "faster and
less error-prone" than using an application-level tool, regardless of
the underlying protocol used by that app (SNMP, TL-1, CORBA, WSDL/SOAP,
etc.)

2. Given a fairly "rich" MIB (per above comments) there are many good
and accessible SNMP "management consoles" that can provide a reasonable
user interface w/o writing a specialized application.  (Yes, there are
definitely exceptions -- but in practice most of those exceptions exist
because the underlying MIBs are just too primitive for efficient
app-level operations.)

[Btw, I heartily concur with Dave's recommendation that MIB "Security
Consideration" sections should not limit their guidance to SNMP
operations only.  Long overdue.]

Cheers,
BobN

-----Original Message-----
From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
Sent: Thursday, October 19, 2006 6:22 AM
To: Zseby, Tanja; ipfix@ietf.org
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?

Dear Tanja,

It may be usefull, but I am not sure if it will be used by many people.
It
is a complex task, you cannot do it easily by hand and to write a
management
program (element manager or what soever) which does it for you is also
a
rather tidious and complex work. In most cases the setup by a command
line
interface is much faster and less error prone than using SNMP. I am
quite
sure most people who configure e.g. a cisco router do it by command
line
even though they might be able to do most of the work by SNMP.

Best Regards,

Thomas

--=20
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
=20

> -----Original Message-----
> From: Zseby, Tanja [mailto:Tanja.Zseby@fokus.fraunhofer.de]=20
> Sent: Thursday, October 19, 2006 11:46 AM
> To: Thomas Dietz; ipfix@ietf.org
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
>=20
> Hi Thomas,
>=20
> in my opinion it would be extremely useful to have a=20
> writeable MIB that
> would allow exporter configuration by SNMP.
>=20
> Kind regards,
> Tanja=20
>=20
> > -----Original Message-----
> > From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20
> > Sent: Thursday, October 19, 2006 4:19 AM
> > To: ipfix@ietf.org
> > Subject: [IPFIX] Should the IPFIX MIB be writeable?
> >=20
> > Dear Benoit, Kobayashi and others,
> >=20
> > I want to summarize 2 points that arose in the current=20
> > discussion of the IPFIX MIB and poll the list for comments=20
> > how we should proceed with it.
> >=20
> > It is a fundamental decision if we should allow the IPFIX=20
> > devices to be configured via SNMP. For the collector there is=20
> > not much to configure but for the exporter there are many=20
> > things that could be set-up, changed and deleted.
> >=20
> > Making the MIB writeable would have the consequence that we=20
> > need to carefully review the status for each variable and=20
> > table. We must define the row status and how it must be set=20
> > and what each setting means. Furthermore we need to carefully=20
> > elaborate the conformance section and need to discuss every=20
> > writeable object in the security considerations. So it is a=20
> > really big effort to make the MIB writeable so that it is=20
> > secure to use it.
> >=20
> > Nevertheless, if the majority on the list has the opinion=20
> > that it is really useful to have the MIB (especially the=20
> > EXPORTER MIB) writeable than we would take that effort.
> >=20
> > Please keep in mind that the decision we take here would also=20
> > affect the PSAMP MIB accordingly.
> >=20
> > Awaiting your comments,
> >=20
> > Thomas
> >=20
> > --=20
> > Thomas Dietz                       E-mail:=20
> Thomas.Dietz@netlab.nec.de
> > Network Laboratories               Phone:  +49 6221 4342-128
> > NEC Europe Ltd.                    Fax:    +49 6221 4342-155
> > Kurfuersten-Anlage 36
> > 69115 Heidelberg, Germany          http://www.netlab.nec.de
> >=20
>=20

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



From bounce-15025-13739113@lists.hcfd.us Fri Oct 20 02:35:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GanyR-0003i2-Ex
	for ipfix-archive@megatron.ietf.org; Fri, 20 Oct 2006 02:35:19 -0400
Received: from lists.hcfd.us ([209.2.34.115])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1GanyQ-0000Zs-3w
	for ipfix-archive@megatron.ietf.org; Fri, 20 Oct 2006 02:35:19 -0400
From: "Pre-Sheriffsale" 
To: ipfix-archive@megatron.ietf.org
Subject: Updated Property List
Date: Fri, 20 Oct 2006 00:42:53 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="MIMEBoundary5e573dd2f92de5e3251cde48d89a9788"
List-Unsubscribe: 
Message-Id: 
X-Spam-Score: 3.1 (+++)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6

This is a multi-part message in MIME format.

--MIMEBoundary5e573dd2f92de5e3251cde48d89a9788
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

Presheriffsale Public Auction

View full listing details at http://www.presheriffsale.com

Updated Property List

1026 E Chelten 19138
1045 Nevada Ave 
1142 Venango St 19140
125 West Roosevelt Boulevard 19120
140 Apsley Street 
1634 Victoria St 19140
1863 N. 27th St 19121
1901-1905 N. 27th St 
212 Millick St 19139
225 Linton St 
2312 Turner St. 19121
2418 Cecil B. Moore Ave 19121
2757 N. Dover St 
3016 N. Bonsall St. 19132
3115 W. Gordon St 19132
3251 W. Huntingdon St. 19132
3933 Folsom St. 19104
4111 N. Broad Street 19140
4621 G Street 19120
5137 Reno St 19139
522 Mayland Street 19144
535 East Walnut Lane 
6237 N. Gratz 19141
6239 Woodstock St 19138
6742 Old York Road 19126
884 Foulkrod Street 

---
You are currently subscribed to auctions as: ipfix-archive@megatron.ietf.org.
To unsubscribe, send a blank email to:  leave-15025-13739113A@lists.hcfd.us
--MIMEBoundary5e573dd2f92de5e3251cde48d89a9788
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit


Presheriffsale Public Auction

View Property Details at http://www.presheriffsale.com

Updated Property List

1026 E Chelten 19138

1045 Nevada Ave 

1142 Venango St 19140

125 West Roosevelt Boulevard 19120

140 Apsley Street 

1634 Victoria St 19140

1863 N. 27th St 19121

1901-1905 N. 27th St 

212 Millick St 19139

225 Linton St 

2312 Turner St. 19121

2418 Cecil B. Moore Ave 19121

2757 N. Dover St 

3016 N. Bonsall St. 19132

3115 W. Gordon St 19132

3251 W. Huntingdon St. 19132

3933 Folsom St. 19104

4111 N. Broad Street 19140

4621 G Street 19120

5137 Reno St 19139

522 Mayland Street 19144

535 East Walnut Lane 

6237 N. Gratz 19141

6239 Woodstock St 19138

6742 Old York Road 19126

884 Foulkrod Street 



---
You are currently subscribed to auctions as: ipfix-archive@megatron.ietf.org.
To unsubscribe, send a blank email to leave-15025-13739113A@lists.hcfd.us


--MIMEBoundary5e573dd2f92de5e3251cde48d89a9788--




From ipfix-bounces@ietf.org Fri Oct 20 05:56:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gar5f-0003xS-3p; Fri, 20 Oct 2006 05:54:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gar5d-0003x8-3L
	for ipfix@ietf.org; Fri, 20 Oct 2006 05:54:57 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaoU2-0001D7-JF
	for ipfix@ietf.org; Fri, 20 Oct 2006 03:07:58 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaoOm-0008M0-5P
	for ipfix@ietf.org; Fri, 20 Oct 2006 03:02:34 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7F00BTXABVSC@szxga01-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:04:44 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7F00H1HABVUK@szxga01-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:04:43 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7F002GKAEEGS@szxml03-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:06:18 +0800 (CST)
Date: Fri, 20 Oct 2006 15:00:03 +0800
From: Ma Yuzhi 
In-reply-to: 
To: ipfix@ietf.org
Message-id: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: AcbvAdVY0ASX/9lhRtmWiZQNHsBiSQFEF6zw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Subject: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi,

Section 11.1 Applicability of TLS and DTLS
   Though TLS bindings to SCTP are defined in [RFC3436], they 
   require all communication to be over reliable streams, and require 
   one session per stream.  This arrangement is not compatible with the 
   rationale behind the choice of SCTP as an IPFIX transport protocol. 

RFC3436 Section 5 Connections and Bi-directional Streams
  TLS makes use of a bi-directional stream by establishing a connection
   over it.  This means that the number of connections for an
   association is limited by the number of bi-directional streams.


Does "one session per stream" mean  "one TLS session per SCTP stream"?
If so, I think the description are unsuitable.

Yuzhi

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> Sent: Saturday, October 14, 2006 3:50 AM
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> 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 Protocol 
> for the Exchange of IP Traffic Flow Information
> 	Author(s)	: B. Claise
> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> 	Pages		: 63
> 	Date		: 2006-10-13
> 	
> This document specifies the IPFIX protocol that serves for 
>    transmitting IP traffic flow information over the network. 
>  In order 
>    to transmit IP traffic flow information from an exporting 
> process to 
>    an information collecting process, a common representation of flow 
>    data and a standard means of communicating them is required. This 
>    document describes how the IPFIX data and templates records are 
>    carried over a number of transport protocols from an IPFIX 
> exporting 
>    process to an IPFIX collecting process.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to i-d-announce-request@ietf.org with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-ietf-ipfix-protocol-23.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 



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



From ipfix-bounces@ietf.org Fri Oct 20 05:56:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gar5f-0003xS-3p; Fri, 20 Oct 2006 05:54:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gar5d-0003x8-3L
	for ipfix@ietf.org; Fri, 20 Oct 2006 05:54:57 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaoU2-0001D7-JF
	for ipfix@ietf.org; Fri, 20 Oct 2006 03:07:58 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaoOm-0008M0-5P
	for ipfix@ietf.org; Fri, 20 Oct 2006 03:02:34 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7F00BTXABVSC@szxga01-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:04:44 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7F00H1HABVUK@szxga01-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:04:43 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7F002GKAEEGS@szxml03-in.huawei.com> for
	ipfix@ietf.org; Fri, 20 Oct 2006 15:06:18 +0800 (CST)
Date: Fri, 20 Oct 2006 15:00:03 +0800
From: Ma Yuzhi 
In-reply-to: 
To: ipfix@ietf.org
Message-id: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: AcbvAdVY0ASX/9lhRtmWiZQNHsBiSQFEF6zw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Subject: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi,

Section 11.1 Applicability of TLS and DTLS
   Though TLS bindings to SCTP are defined in [RFC3436], they 
   require all communication to be over reliable streams, and require 
   one session per stream.  This arrangement is not compatible with the 
   rationale behind the choice of SCTP as an IPFIX transport protocol. 

RFC3436 Section 5 Connections and Bi-directional Streams
  TLS makes use of a bi-directional stream by establishing a connection
   over it.  This means that the number of connections for an
   association is limited by the number of bi-directional streams.


Does "one session per stream" mean  "one TLS session per SCTP stream"?
If so, I think the description are unsuitable.

Yuzhi

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> Sent: Saturday, October 14, 2006 3:50 AM
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> 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 Protocol 
> for the Exchange of IP Traffic Flow Information
> 	Author(s)	: B. Claise
> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> 	Pages		: 63
> 	Date		: 2006-10-13
> 	
> This document specifies the IPFIX protocol that serves for 
>    transmitting IP traffic flow information over the network. 
>  In order 
>    to transmit IP traffic flow information from an exporting 
> process to 
>    an information collecting process, a common representation of flow 
>    data and a standard means of communicating them is required. This 
>    document describes how the IPFIX data and templates records are 
>    carried over a number of transport protocols from an IPFIX 
> exporting 
>    process to an IPFIX collecting process.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to i-d-announce-request@ietf.org with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-ietf-ipfix-protocol-23.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 



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



From ipfix-bounces@ietf.org Fri Oct 20 08:34:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GatYf-00051O-1Y; Fri, 20 Oct 2006 08:33:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GatYd-0004vC-GJ
	for ipfix@ietf.org; Fri, 20 Oct 2006 08:33:03 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GatYX-00064k-PF
	for ipfix@ietf.org; Fri, 20 Oct 2006 08:33:03 -0400
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
	k9KCWuO03723; Fri, 20 Oct 2006 14:32:56 +0200 (CEST)
Received: from [10.61.65.144] (ams3-vpn-dhcp400.cisco.com [10.61.65.144])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9KCWtP14531; Fri, 20 Oct 2006 14:32:55 +0200 (CEST)
Message-ID: <4538C1EB.7010404@cisco.com>
Date: Fri, 20 Oct 2006 14:32:43 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0522829669=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0522829669==
Content-Type: multipart/alternative;
	boundary="------------090002070000060801000204"

This is a multi-part message in MIME format.
--------------090002070000060801000204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

If the question is: "would you like to have a writable MIB",  the answer 
will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with more 
features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it 
be saved? 
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  
let me ask the question differently: will this read-write MIB be 
practical and useful?

Let me concentrate on the Exporter MIB, as the Collector MIB should be 
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such as 
where to export, which transport protocol, which port, backup or not, 
template retransmission timeout, etc...) is somehow pretty static in 
networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that relates 
to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the 
template definition from Flexible NetFlow?
     Flexible NetFlow = 
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
This would require the ipfixTemplateTable to have the following indexes:
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be quite 
a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to express 
whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra 
table for options template is required. In this table, as we can have 
multiple scope information elements, we need a way to express whether an 
I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the 
collector creates new templates.
- The collector configures the template Ids.
  Note: remember that the template Id are unique per observation domain 
and per transport session.
  So now, if the SCTP association goes down, what should the collector do?
    1. erase all the templates on the exporter, and reconfigure them? 
This implies that if only the connection is down, not the metering 
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering 
process went down and the template id allocation changed. Shall the 
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must be 
set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this MIB, 
I'm questioning this practicality/complexity... and as a consequence its 
chances to be implemented if everything is read-write
However, I agree with the configuration of the exporting process information
Finally I agree that a way to configure the templates is needed, I'm 
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the 
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor: 
SNMP versus NETCONF versus CLI

Regards, Benoit.
> Dear Benoit, Kobayashi and others,
>
> I want to summarize 2 points that arose in the current discussion of the
> IPFIX MIB and poll the list for comments how we should proceed with it.
>
> It is a fundamental decision if we should allow the IPFIX devices to be
> configured via SNMP. For the collector there is not much to configure but
> for the exporter there are many things that could be set-up, changed and
> deleted.
>
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We must define the
> row status and how it must be set and what each setting means. Furthermore
> we need to carefully elaborate the conformance section and need to discuss
> every writeable object in the security considerations. So it is a really big
> effort to make the MIB writeable so that it is secure to use it.
>
> Nevertheless, if the majority on the list has the opinion that it is really
> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
> take that effort.
>
> Please keep in mind that the decision we take here would also affect the
> PSAMP MIB accordingly.
>
> Awaiting your comments,
>
> Thomas
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Dear all,



If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"

It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.



While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful? 



Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)

Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.

However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.

For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?

     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml

This would require the ipfixTemplateTable to have the following
indexes: 

    the transport session source IP address

    the transport session destination IP address

    the transport session source port

    the transport session destination port

    the observation domain Id

    the template Id

    the information element position

A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB

Some more remarks that will add to the complexity:

- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not

- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)

- This implies that Template Ids are assigned by the collector if the
collector creates new templates.

- The collector configures the template Ids. 

  Note: remember that the template Id are unique per observation domain
and per transport session. 

  So now, if the SCTP association goes down, what should the collector
do?

    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process

    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?

    3. something else?

- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."



To summarize, my views are:

Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 

However, I agree with the configuration of the exporting process
information

Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?



Potential solution:

Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?

That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI



Regards, Benoit.



  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

  

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








--------------090002070000060801000204--


--===============0522829669==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0522829669==--




From ipfix-bounces@ietf.org Fri Oct 20 08:34:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GatYf-00051O-1Y; Fri, 20 Oct 2006 08:33:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GatYd-0004vC-GJ
	for ipfix@ietf.org; Fri, 20 Oct 2006 08:33:03 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GatYX-00064k-PF
	for ipfix@ietf.org; Fri, 20 Oct 2006 08:33:03 -0400
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
	k9KCWuO03723; Fri, 20 Oct 2006 14:32:56 +0200 (CEST)
Received: from [10.61.65.144] (ams3-vpn-dhcp400.cisco.com [10.61.65.144])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9KCWtP14531; Fri, 20 Oct 2006 14:32:55 +0200 (CEST)
Message-ID: <4538C1EB.7010404@cisco.com>
Date: Fri, 20 Oct 2006 14:32:43 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0522829669=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0522829669==
Content-Type: multipart/alternative;
	boundary="------------090002070000060801000204"

This is a multi-part message in MIME format.
--------------090002070000060801000204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

If the question is: "would you like to have a writable MIB",  the answer 
will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with more 
features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it 
be saved? 
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  
let me ask the question differently: will this read-write MIB be 
practical and useful?

Let me concentrate on the Exporter MIB, as the Collector MIB should be 
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such as 
where to export, which transport protocol, which port, backup or not, 
template retransmission timeout, etc...) is somehow pretty static in 
networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that relates 
to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the 
template definition from Flexible NetFlow?
     Flexible NetFlow = 
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
This would require the ipfixTemplateTable to have the following indexes:
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be quite 
a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to express 
whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra 
table for options template is required. In this table, as we can have 
multiple scope information elements, we need a way to express whether an 
I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the 
collector creates new templates.
- The collector configures the template Ids.
  Note: remember that the template Id are unique per observation domain 
and per transport session.
  So now, if the SCTP association goes down, what should the collector do?
    1. erase all the templates on the exporter, and reconfigure them? 
This implies that if only the connection is down, not the metering 
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering 
process went down and the template id allocation changed. Shall the 
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must be 
set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this MIB, 
I'm questioning this practicality/complexity... and as a consequence its 
chances to be implemented if everything is read-write
However, I agree with the configuration of the exporting process information
Finally I agree that a way to configure the templates is needed, I'm 
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the 
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor: 
SNMP versus NETCONF versus CLI

Regards, Benoit.
> Dear Benoit, Kobayashi and others,
>
> I want to summarize 2 points that arose in the current discussion of the
> IPFIX MIB and poll the list for comments how we should proceed with it.
>
> It is a fundamental decision if we should allow the IPFIX devices to be
> configured via SNMP. For the collector there is not much to configure but
> for the exporter there are many things that could be set-up, changed and
> deleted.
>
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We must define the
> row status and how it must be set and what each setting means. Furthermore
> we need to carefully elaborate the conformance section and need to discuss
> every writeable object in the security considerations. So it is a really big
> effort to make the MIB writeable so that it is secure to use it.
>
> Nevertheless, if the majority on the list has the opinion that it is really
> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
> take that effort.
>
> Please keep in mind that the decision we take here would also affect the
> PSAMP MIB accordingly.
>
> Awaiting your comments,
>
> Thomas
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Dear all,



If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"

It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.



While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful? 



Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)

Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.

However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.

For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?

     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml

This would require the ipfixTemplateTable to have the following
indexes: 

    the transport session source IP address

    the transport session destination IP address

    the transport session source port

    the transport session destination port

    the observation domain Id

    the template Id

    the information element position

A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB

Some more remarks that will add to the complexity:

- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not

- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)

- This implies that Template Ids are assigned by the collector if the
collector creates new templates.

- The collector configures the template Ids. 

  Note: remember that the template Id are unique per observation domain
and per transport session. 

  So now, if the SCTP association goes down, what should the collector
do?

    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process

    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?

    3. something else?

- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."



To summarize, my views are:

Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 

However, I agree with the configuration of the exporting process
information

Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?



Potential solution:

Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?

That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI



Regards, Benoit.



  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

  

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








--------------090002070000060801000204--


--===============0522829669==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0522829669==--




From ipfix-bounces@ietf.org Fri Oct 20 09:03:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gau1s-0004T9-Cg; Fri, 20 Oct 2006 09:03:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau1q-0004Fx-L5
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:03:14 -0400
Received: from nj300815-ier2.net.avaya.com ([198.152.12.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau1p-0002br-0X
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:03:14 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9KCotL4007279
	for ; Fri, 20 Oct 2006 08:51:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 15:03:02 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: Acb0RBWXPRmjEEG6QbCUgb7kw/fm6AAAgd1Q
From: "Romascanu, Dan \(Dan\)" 
To: "Benoit Claise" ,
	"Thomas Dietz" 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f0ea5880a0890be2408609376fa519aa
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1403235966=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1403235966==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6F448.13910B12"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F448.13910B12
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
If we believe that a writeable MIB will not be used, than better let us
not define it at all.=20
=20
However, if something else will be used for configuration, it will need
a standard definition for interoperability, and some of the aspects of
this discussion cannot be eluded completely.=20
=20
Dan
=20
=20
=20
=20


  _____ =20

	From: Benoit Claise [mailto:bclaise@cisco.com]=20
	Sent: Friday, October 20, 2006 2:33 PM
	To: Thomas Dietz
	Cc: ipfix@ietf.org
	Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
=09
=09
	Dear all,
=09
	If the question is: "would you like to have a writable MIB",
the answer will probably be: "sure, it's useful/nice-to-have!"
	It's a logical answer when you offer the choice of a solution
with more features compared to a solution with less features.
=09
	While I don't want to restart a discussion on SNMPset ("SNMPSet:
can it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introductio
n),  let me ask the question differently: will this read-write MIB be
practical and useful?=20
=09
	Let me concentrate on the Exporter MIB, as the Collector MIB
should be read-only (what can we configure on the collector side?)
	Even if the information related to the IPFIX exporting process
(such as where to export, which transport protocol, which port, backup
or not, template retransmission timeout, etc...) is somehow pretty
static in networks, this type of configuration via SNMP might be useful.
	However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
	For example, is it practical to specify via SNMP all the
possible the template definition from Flexible NetFlow?
	     Flexible NetFlow =3D
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd80
4be091.shtml
	This would require the ipfixTemplateTable to have the following
indexes:=20
	    the transport session source IP address
	    the transport session destination IP address
	    the transport session source port
	    the transport session destination port
	    the observation domain Id
	    the template Id
	    the information element position
	A table with 7 indexes. Sure, it's possible but this starts to
be quite a complex MIB
	Some more remarks that will add to the complexity:
	- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
	- We have the choice of template versus options template. So an
extra table for options template is required. In this table, as we can
have multiple scope information elements, we need a way to express
whether an I.E. is a scope or not (similar to flow key in
ipfixTemplateTable)
	- This implies that Template Ids are assigned by the collector
if the collector creates new templates.
	- The collector configures the template Ids.=20
	  Note: remember that the template Id are unique per observation
domain and per transport session.=20
	  So now, if the SCTP association goes down, what should the
collector do?
	    1. erase all the templates on the exporter, and reconfigure
them? This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
	    2. wait for the template retransmission? What if the
metering process went down and the template id allocation changed. Shall
the collector update his MIB?
	    3. something else?
	- As Thomas mentioned: "We must define the row status and how it
must be set and what each setting means."
=09
	To summarize, my views are:
	Even if this might be an interesting little challenge to write
this MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write=20
	However, I agree with the configuration of the exporting process
information
	Finally I agree that a way to configure the templates is needed,
I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
=09
	Potential solution:
	Could we have specify the full exporter MIB as writable, but
limit the metering part to read-only in the "Units of Conformance"?
	That way, the end customers will decide by pushing or not the
vendor: SNMP versus NETCONF versus CLI
=09
	Regards, Benoit.
=09

		Dear Benoit, Kobayashi and others,
	=09
		I want to summarize 2 points that arose in the current
discussion of the
		IPFIX MIB and poll the list for comments how we should
proceed with it.
	=09
		It is a fundamental decision if we should allow the
IPFIX devices to be
		configured via SNMP. For the collector there is not much
to configure but
		for the exporter there are many things that could be
set-up, changed and
		deleted.
	=09
		Making the MIB writeable would have the consequence that
we need to
		carefully review the status for each variable and table.
We must define the
		row status and how it must be set and what each setting
means. Furthermore
		we need to carefully elaborate the conformance section
and need to discuss
		every writeable object in the security considerations.
So it is a really big
		effort to make the MIB writeable so that it is secure to
use it.
	=09
		Nevertheless, if the majority on the list has the
opinion that it is really
		useful to have the MIB (especially the EXPORTER MIB)
writeable than we would
		take that effort.
	=09
		Please keep in mind that the decision we take here would
also affect the
		PSAMP MIB accordingly.
	=09
		Awaiting your comments,
	=09
		Thomas
	=09
		 =20
	=09
  _____ =20


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



------_=_NextPart_001_01C6F448.13910B12
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







 


If we believe that a writeable MIB will not be used, than =
better let us=20
not define it at all. 


 


However, if something else will be used for configuration, =
it will=20
need a standard definition for interoperability, and some of the =
aspects of=20
this discussion cannot be eluded completely. =



 


Dan


 


 


 


 



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas =

  Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] =
Should the=20
  IPFIX MIB be writeable?


  
Dear all,

If the question is: "would you like to =
have a=20
  writable MIB",  the answer will probably be: "sure, it's=20
  useful/nice-to-have!"
It's a logical answer when you offer the =
choice of a=20
  solution with more features compared to a solution with less=20
  features.

While I don't want to restart a discussion on SNMPset =

  ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#in=
troduction), =20
  let me ask the question differently: will this read-write MIB be =
practical and=20
  useful? 

Let me concentrate on the Exporter MIB, as the =
Collector MIB=20
  should be read-only (what can we configure on the collector =
side?)
Even if=20
  the information related to the IPFIX exporting process (such as where =
to=20
  export, which transport protocol, which port, backup or not, template=20
  retransmission timeout, etc...) is somehow pretty static in networks, =
this=20
  type of configuration via SNMP might be useful.
However, I'm not =
sure about=20
  the configuration of everything that relates to metering process as =
it's=20
  getting pretty complex.
For example, is it practical to specify via =
SNMP=20
  all the possible the template definition from Flexible=20
  NetFlow?
     Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_=
qanda_item0900aecd804be091.shtml
This=20
  would require the ipfixTemplateTable to have the following indexes:=20
  
    the transport session source IP=20
  address
    the transport session destination IP=20
  address
    the transport session source=20
  port
    the transport session destination=20
  port
    the observation domain =
Id
    the=20
  template Id
    the information element =
position
A table=20
  with 7 indexes. Sure, it's possible but this starts to be quite a =
complex=20
  MIB
Some more remarks that will add to the complexity:
- In=20
  ipfixTemplateTable, we still need to find a way via SNMP to express =
whether a=20
  specific I.E. is a flow key or not
- We have the choice of template =
versus=20
  options template. So an extra table for options template is required. =
In this=20
  table, as we can have multiple scope information elements, we need a =
way to=20
  express whether an I.E. is a scope or not (similar to flow key in=20
  ipfixTemplateTable)
- This implies that Template Ids are assigned =
by the=20
  collector if the collector creates new templates.
- The collector=20
  configures the template Ids. 
  Note: remember that the =
template Id=20
  are unique per observation domain and per transport session. =

  So=20
  now, if the SCTP association goes down, what should the collector=20
  do?
    1. erase all the templates on the exporter, =
and=20
  reconfigure them? This implies that if only the connection is down, =
not the=20
  metering process, then this action basically stopped the metering=20
  process
    2. wait for the template retransmission? =
What if=20
  the metering process went down and the template id allocation changed. =
Shall=20
  the collector update his MIB?
    3. something =
else?
- As=20
  Thomas mentioned: "We must define the row status and how it must be =
set and=20
  what each setting means."

To summarize, my views are:
Even =
if this=20
  might be an interesting little challenge to write this MIB, I'm =
questioning=20
  this practicality/complexity... and as a consequence its chances to be =

  implemented if everything is read-write 
However, I agree with the=20
  configuration of the exporting process information
Finally I agree =
that a=20
  way to configure the templates is needed, I'm wondering whether SNMP =
is the=20
  right way to do. Maybe NETCONF?

Potential solution:
Could we =
have=20
  specify the full exporter MIB as writable, but limit the metering part =
to=20
  read-only in the "Units of =

  Conformance"?
That way, the end customers will decide by pushing or =
not the=20
  vendor: SNMP versus NETCONF versus CLI

Regards,=20
  Benoit.

  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipfix
  



------_=_NextPart_001_01C6F448.13910B12--


--===============1403235966==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1403235966==--




From ipfix-bounces@ietf.org Fri Oct 20 09:03:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gau1s-0004T9-Cg; Fri, 20 Oct 2006 09:03:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau1q-0004Fx-L5
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:03:14 -0400
Received: from nj300815-ier2.net.avaya.com ([198.152.12.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau1p-0002br-0X
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:03:14 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9KCotL4007279
	for ; Fri, 20 Oct 2006 08:51:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 15:03:02 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Should the IPFIX MIB be writeable?
Thread-Index: Acb0RBWXPRmjEEG6QbCUgb7kw/fm6AAAgd1Q
From: "Romascanu, Dan \(Dan\)" 
To: "Benoit Claise" ,
	"Thomas Dietz" 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f0ea5880a0890be2408609376fa519aa
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1403235966=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1403235966==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6F448.13910B12"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F448.13910B12
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
If we believe that a writeable MIB will not be used, than better let us
not define it at all.=20
=20
However, if something else will be used for configuration, it will need
a standard definition for interoperability, and some of the aspects of
this discussion cannot be eluded completely.=20
=20
Dan
=20
=20
=20
=20


  _____ =20

	From: Benoit Claise [mailto:bclaise@cisco.com]=20
	Sent: Friday, October 20, 2006 2:33 PM
	To: Thomas Dietz
	Cc: ipfix@ietf.org
	Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
=09
=09
	Dear all,
=09
	If the question is: "would you like to have a writable MIB",
the answer will probably be: "sure, it's useful/nice-to-have!"
	It's a logical answer when you offer the choice of a solution
with more features compared to a solution with less features.
=09
	While I don't want to restart a discussion on SNMPset ("SNMPSet:
can it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introductio
n),  let me ask the question differently: will this read-write MIB be
practical and useful?=20
=09
	Let me concentrate on the Exporter MIB, as the Collector MIB
should be read-only (what can we configure on the collector side?)
	Even if the information related to the IPFIX exporting process
(such as where to export, which transport protocol, which port, backup
or not, template retransmission timeout, etc...) is somehow pretty
static in networks, this type of configuration via SNMP might be useful.
	However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
	For example, is it practical to specify via SNMP all the
possible the template definition from Flexible NetFlow?
	     Flexible NetFlow =3D
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd80
4be091.shtml
	This would require the ipfixTemplateTable to have the following
indexes:=20
	    the transport session source IP address
	    the transport session destination IP address
	    the transport session source port
	    the transport session destination port
	    the observation domain Id
	    the template Id
	    the information element position
	A table with 7 indexes. Sure, it's possible but this starts to
be quite a complex MIB
	Some more remarks that will add to the complexity:
	- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
	- We have the choice of template versus options template. So an
extra table for options template is required. In this table, as we can
have multiple scope information elements, we need a way to express
whether an I.E. is a scope or not (similar to flow key in
ipfixTemplateTable)
	- This implies that Template Ids are assigned by the collector
if the collector creates new templates.
	- The collector configures the template Ids.=20
	  Note: remember that the template Id are unique per observation
domain and per transport session.=20
	  So now, if the SCTP association goes down, what should the
collector do?
	    1. erase all the templates on the exporter, and reconfigure
them? This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
	    2. wait for the template retransmission? What if the
metering process went down and the template id allocation changed. Shall
the collector update his MIB?
	    3. something else?
	- As Thomas mentioned: "We must define the row status and how it
must be set and what each setting means."
=09
	To summarize, my views are:
	Even if this might be an interesting little challenge to write
this MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write=20
	However, I agree with the configuration of the exporting process
information
	Finally I agree that a way to configure the templates is needed,
I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
=09
	Potential solution:
	Could we have specify the full exporter MIB as writable, but
limit the metering part to read-only in the "Units of Conformance"?
	That way, the end customers will decide by pushing or not the
vendor: SNMP versus NETCONF versus CLI
=09
	Regards, Benoit.
=09

		Dear Benoit, Kobayashi and others,
	=09
		I want to summarize 2 points that arose in the current
discussion of the
		IPFIX MIB and poll the list for comments how we should
proceed with it.
	=09
		It is a fundamental decision if we should allow the
IPFIX devices to be
		configured via SNMP. For the collector there is not much
to configure but
		for the exporter there are many things that could be
set-up, changed and
		deleted.
	=09
		Making the MIB writeable would have the consequence that
we need to
		carefully review the status for each variable and table.
We must define the
		row status and how it must be set and what each setting
means. Furthermore
		we need to carefully elaborate the conformance section
and need to discuss
		every writeable object in the security considerations.
So it is a really big
		effort to make the MIB writeable so that it is secure to
use it.
	=09
		Nevertheless, if the majority on the list has the
opinion that it is really
		useful to have the MIB (especially the EXPORTER MIB)
writeable than we would
		take that effort.
	=09
		Please keep in mind that the decision we take here would
also affect the
		PSAMP MIB accordingly.
	=09
		Awaiting your comments,
	=09
		Thomas
	=09
		 =20
	=09
  _____ =20


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



------_=_NextPart_001_01C6F448.13910B12
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







 


If we believe that a writeable MIB will not be used, than =
better let us=20
not define it at all. 


 


However, if something else will be used for configuration, =
it will=20
need a standard definition for interoperability, and some of the =
aspects of=20
this discussion cannot be eluded completely. =



 


Dan


 


 


 


 



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas =

  Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] =
Should the=20
  IPFIX MIB be writeable?


  
Dear all,

If the question is: "would you like to =
have a=20
  writable MIB",  the answer will probably be: "sure, it's=20
  useful/nice-to-have!"
It's a logical answer when you offer the =
choice of a=20
  solution with more features compared to a solution with less=20
  features.

While I don't want to restart a discussion on SNMPset =

  ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#in=
troduction), =20
  let me ask the question differently: will this read-write MIB be =
practical and=20
  useful? 

Let me concentrate on the Exporter MIB, as the =
Collector MIB=20
  should be read-only (what can we configure on the collector =
side?)
Even if=20
  the information related to the IPFIX exporting process (such as where =
to=20
  export, which transport protocol, which port, backup or not, template=20
  retransmission timeout, etc...) is somehow pretty static in networks, =
this=20
  type of configuration via SNMP might be useful.
However, I'm not =
sure about=20
  the configuration of everything that relates to metering process as =
it's=20
  getting pretty complex.
For example, is it practical to specify via =
SNMP=20
  all the possible the template definition from Flexible=20
  NetFlow?
     Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_=
qanda_item0900aecd804be091.shtml
This=20
  would require the ipfixTemplateTable to have the following indexes:=20
  
    the transport session source IP=20
  address
    the transport session destination IP=20
  address
    the transport session source=20
  port
    the transport session destination=20
  port
    the observation domain =
Id
    the=20
  template Id
    the information element =
position
A table=20
  with 7 indexes. Sure, it's possible but this starts to be quite a =
complex=20
  MIB
Some more remarks that will add to the complexity:
- In=20
  ipfixTemplateTable, we still need to find a way via SNMP to express =
whether a=20
  specific I.E. is a flow key or not
- We have the choice of template =
versus=20
  options template. So an extra table for options template is required. =
In this=20
  table, as we can have multiple scope information elements, we need a =
way to=20
  express whether an I.E. is a scope or not (similar to flow key in=20
  ipfixTemplateTable)
- This implies that Template Ids are assigned =
by the=20
  collector if the collector creates new templates.
- The collector=20
  configures the template Ids. 
  Note: remember that the =
template Id=20
  are unique per observation domain and per transport session. =

  So=20
  now, if the SCTP association goes down, what should the collector=20
  do?
    1. erase all the templates on the exporter, =
and=20
  reconfigure them? This implies that if only the connection is down, =
not the=20
  metering process, then this action basically stopped the metering=20
  process
    2. wait for the template retransmission? =
What if=20
  the metering process went down and the template id allocation changed. =
Shall=20
  the collector update his MIB?
    3. something =
else?
- As=20
  Thomas mentioned: "We must define the row status and how it must be =
set and=20
  what each setting means."

To summarize, my views are:
Even =
if this=20
  might be an interesting little challenge to write this MIB, I'm =
questioning=20
  this practicality/complexity... and as a consequence its chances to be =

  implemented if everything is read-write 
However, I agree with the=20
  configuration of the exporting process information
Finally I agree =
that a=20
  way to configure the templates is needed, I'm wondering whether SNMP =
is the=20
  right way to do. Maybe NETCONF?

Potential solution:
Could we =
have=20
  specify the full exporter MIB as writable, but limit the metering part =
to=20
  read-only in the "Units of =

  Conformance"?
That way, the end customers will decide by pushing or =
not the=20
  vendor: SNMP versus NETCONF versus CLI

Regards,=20
  Benoit.

  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipfix
  



------_=_NextPart_001_01C6F448.13910B12--


--===============1403235966==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1403235966==--




From ipfix-bounces@ietf.org Fri Oct 20 09:04:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gau2u-0006q8-Bi; Fri, 20 Oct 2006 09:04:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau2t-0006q0-6O
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:04:19 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau2r-0002id-Dn
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:04:19 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E0FD8125
	for ; Fri, 20 Oct 2006 15:04:15 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
	by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 14962-02 for ; Fri, 20 Oct 2006 15:04:13 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E565A11C
	for ; Fri, 20 Oct 2006 15:04:12 +0200 (MST)
Message-ID: <4538C98C.50304@informatik.uni-tuebingen.de>
Date: Fri, 20 Oct 2006 15:05:16 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
	<4538C1EB.7010404@cisco.com>
In-Reply-To: <4538C1EB.7010404@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear all,

I assume that talking about Netconf implies talking about XML-based
configuration. Apart from offering the possiblity to reflect complex
configurations in an intuitive and comprehensible way, I see the
following advantage: XML makes it easy to extend the configuration with
new standardized or device/vendor-specific parameters. This means, the
data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
probably have to cope with more dependencies which make it more
complicated to change its definition.

Regards,
Gerhard


Benoit Claise wrote:
>  Dear all,
> 
> If the question is: "would you like to have a writable MIB",  the answer
> will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with more
> features compared to a solution with less features.
> 
> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
> be saved?
> http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
> let me ask the question differently: will this read-write MIB be
> practical and useful?
> 
> Let me concentrate on the Exporter MIB, as the Collector MIB should be
> read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process (such as
> where to export, which transport protocol, which port, backup or not,
> template retransmission timeout, etc...) is somehow pretty static in
> networks, this type of configuration via SNMP might be useful.
> However, I'm not sure about the configuration of everything that relates
> to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible the
> template definition from Flexible NetFlow?
>      Flexible NetFlow =
> http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be quite
> a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to express
> whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an extra
> table for options template is required. In this table, as we can have
> multiple scope information elements, we need a way to express whether an
> I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if the
> collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation domain
> and per transport session.
>   So now, if the SCTP association goes down, what should the collector do?
>     1. erase all the templates on the exporter, and reconfigure them?
> This implies that if only the connection is down, not the metering
> process, then this action basically stopped the metering process
>     2. wait for the template retransmission? What if the metering
> process went down and the template id allocation changed. Shall the
> collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it must be
> set and what each setting means."
> 
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this MIB,
> I'm questioning this practicality/complexity... and as a consequence its
> chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process information
> Finally I agree that a way to configure the templates is needed, I'm
> wondering whether SNMP is the right way to do. Maybe NETCONF?
> 
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit the
> metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the vendor:
> SNMP versus NETCONF versus CLI
> 
> Regards, Benoit.
>> Dear Benoit, Kobayashi and others,
>>
>> I want to summarize 2 points that arose in the current discussion of the
>> IPFIX MIB and poll the list for comments how we should proceed with it.
>>
>> It is a fundamental decision if we should allow the IPFIX devices to be
>> configured via SNMP. For the collector there is not much to configure but
>> for the exporter there are many things that could be set-up, changed and
>> deleted.
>>
>> Making the MIB writeable would have the consequence that we need to
>> carefully review the status for each variable and table. We must define the
>> row status and how it must be set and what each setting means. Furthermore
>> we need to carefully elaborate the conformance section and need to discuss
>> every writeable object in the security considerations. So it is a really big
>> effort to make the MIB writeable so that it is secure to use it.
>>
>> Nevertheless, if the majority on the list has the opinion that it is really
>> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>> take that effort.
>>
>> Please keep in mind that the decision we take here would also affect the
>> PSAMP MIB accordingly.
>>
>> Awaiting your comments,
>>
>> Thomas
>>
>>   
>>  
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Fri Oct 20 09:04:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gau2u-0006q8-Bi; Fri, 20 Oct 2006 09:04:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau2t-0006q0-6O
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:04:19 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau2r-0002id-Dn
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:04:19 -0400
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E0FD8125
	for ; Fri, 20 Oct 2006 15:04:15 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
	by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 14962-02 for ; Fri, 20 Oct 2006 15:04:13 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E565A11C
	for ; Fri, 20 Oct 2006 15:04:12 +0200 (MST)
Message-ID: <4538C98C.50304@informatik.uni-tuebingen.de>
Date: Fri, 20 Oct 2006 15:05:16 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: ipfix@ietf.org
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>
	<4538C1EB.7010404@cisco.com>
In-Reply-To: <4538C1EB.7010404@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
	informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear all,

I assume that talking about Netconf implies talking about XML-based
configuration. Apart from offering the possiblity to reflect complex
configurations in an intuitive and comprehensible way, I see the
following advantage: XML makes it easy to extend the configuration with
new standardized or device/vendor-specific parameters. This means, the
data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
probably have to cope with more dependencies which make it more
complicated to change its definition.

Regards,
Gerhard


Benoit Claise wrote:
>  Dear all,
> 
> If the question is: "would you like to have a writable MIB",  the answer
> will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with more
> features compared to a solution with less features.
> 
> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
> be saved?
> http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
> let me ask the question differently: will this read-write MIB be
> practical and useful?
> 
> Let me concentrate on the Exporter MIB, as the Collector MIB should be
> read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process (such as
> where to export, which transport protocol, which port, backup or not,
> template retransmission timeout, etc...) is somehow pretty static in
> networks, this type of configuration via SNMP might be useful.
> However, I'm not sure about the configuration of everything that relates
> to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible the
> template definition from Flexible NetFlow?
>      Flexible NetFlow =
> http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be quite
> a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to express
> whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an extra
> table for options template is required. In this table, as we can have
> multiple scope information elements, we need a way to express whether an
> I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if the
> collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation domain
> and per transport session.
>   So now, if the SCTP association goes down, what should the collector do?
>     1. erase all the templates on the exporter, and reconfigure them?
> This implies that if only the connection is down, not the metering
> process, then this action basically stopped the metering process
>     2. wait for the template retransmission? What if the metering
> process went down and the template id allocation changed. Shall the
> collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it must be
> set and what each setting means."
> 
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this MIB,
> I'm questioning this practicality/complexity... and as a consequence its
> chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process information
> Finally I agree that a way to configure the templates is needed, I'm
> wondering whether SNMP is the right way to do. Maybe NETCONF?
> 
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit the
> metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the vendor:
> SNMP versus NETCONF versus CLI
> 
> Regards, Benoit.
>> Dear Benoit, Kobayashi and others,
>>
>> I want to summarize 2 points that arose in the current discussion of the
>> IPFIX MIB and poll the list for comments how we should proceed with it.
>>
>> It is a fundamental decision if we should allow the IPFIX devices to be
>> configured via SNMP. For the collector there is not much to configure but
>> for the exporter there are many things that could be set-up, changed and
>> deleted.
>>
>> Making the MIB writeable would have the consequence that we need to
>> carefully review the status for each variable and table. We must define the
>> row status and how it must be set and what each setting means. Furthermore
>> we need to carefully elaborate the conformance section and need to discuss
>> every writeable object in the security considerations. So it is a really big
>> effort to make the MIB writeable so that it is secure to use it.
>>
>> Nevertheless, if the majority on the list has the opinion that it is really
>> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>> take that effort.
>>
>> Please keep in mind that the decision we take here would also affect the
>> PSAMP MIB accordingly.
>>
>> Awaiting your comments,
>>
>> Thomas
>>
>>   
>>  
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix


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



From ipfix-bounces@ietf.org Fri Oct 20 09:32:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GauUF-0004bX-23; Fri, 20 Oct 2006 09:32:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GauUD-0004bQ-Qo
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:32:33 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GauUA-0007Xp-Ne
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:32:33 -0400
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
	k9KDWTA07578; Fri, 20 Oct 2006 15:32:29 +0200 (CEST)
Received: from [10.61.82.125] (ams3-vpn-dhcp4734.cisco.com [10.61.82.125])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9KDWSP18743; Fri, 20 Oct 2006 15:32:28 +0200 (CEST)
Message-ID: <4538CFEC.9020209@cisco.com>
Date: Fri, 20 Oct 2006 15:32:28 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Gerhard Muenz 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>	<4538C1EB.7010404@cisco.com>
	<4538C98C.50304@informatik.uni-tuebingen.de>
In-Reply-To: <4538C98C.50304@informatik.uni-tuebingen.de>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2101131682=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============2101131682==
Content-Type: multipart/alternative;
	boundary="------------080703030909020000050003"

This is a multi-part message in MIME format.
--------------080703030909020000050003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gerhard,
> Dear all,
>
> I assume that talking about Netconf implies talking about XML-based
> configuration. Apart from offering the possiblity to reflect complex
> configurations in an intuitive and comprehensible way, I see the
> following advantage: XML makes it easy to extend the configuration with
> new standardized or device/vendor-specific parameters. 
Good point. I forgot about the vendor-specific parameters.

Regards, Benoit.
> This means, the
> data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
> probably have to cope with more dependencies which make it more
> complicated to change its definition.
>   
> Regards,
> Gerhard
>
>
> Benoit Claise wrote:
>   
>>  Dear all,
>>
>> If the question is: "would you like to have a writable MIB",  the answer
>> will probably be: "sure, it's useful/nice-to-have!"
>> It's a logical answer when you offer the choice of a solution with more
>> features compared to a solution with less features.
>>
>> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
>> be saved?
>> http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
>> let me ask the question differently: will this read-write MIB be
>> practical and useful?
>>
>> Let me concentrate on the Exporter MIB, as the Collector MIB should be
>> read-only (what can we configure on the collector side?)
>> Even if the information related to the IPFIX exporting process (such as
>> where to export, which transport protocol, which port, backup or not,
>> template retransmission timeout, etc...) is somehow pretty static in
>> networks, this type of configuration via SNMP might be useful.
>> However, I'm not sure about the configuration of everything that relates
>> to metering process as it's getting pretty complex.
>> For example, is it practical to specify via SNMP all the possible the
>> template definition from Flexible NetFlow?
>>      Flexible NetFlow =
>> http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
>> This would require the ipfixTemplateTable to have the following indexes:
>>     the transport session source IP address
>>     the transport session destination IP address
>>     the transport session source port
>>     the transport session destination port
>>     the observation domain Id
>>     the template Id
>>     the information element position
>> A table with 7 indexes. Sure, it's possible but this starts to be quite
>> a complex MIB
>> Some more remarks that will add to the complexity:
>> - In ipfixTemplateTable, we still need to find a way via SNMP to express
>> whether a specific I.E. is a flow key or not
>> - We have the choice of template versus options template. So an extra
>> table for options template is required. In this table, as we can have
>> multiple scope information elements, we need a way to express whether an
>> I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
>> - This implies that Template Ids are assigned by the collector if the
>> collector creates new templates.
>> - The collector configures the template Ids.
>>   Note: remember that the template Id are unique per observation domain
>> and per transport session.
>>   So now, if the SCTP association goes down, what should the collector do?
>>     1. erase all the templates on the exporter, and reconfigure them?
>> This implies that if only the connection is down, not the metering
>> process, then this action basically stopped the metering process
>>     2. wait for the template retransmission? What if the metering
>> process went down and the template id allocation changed. Shall the
>> collector update his MIB?
>>     3. something else?
>> - As Thomas mentioned: "We must define the row status and how it must be
>> set and what each setting means."
>>
>> To summarize, my views are:
>> Even if this might be an interesting little challenge to write this MIB,
>> I'm questioning this practicality/complexity... and as a consequence its
>> chances to be implemented if everything is read-write
>> However, I agree with the configuration of the exporting process information
>> Finally I agree that a way to configure the templates is needed, I'm
>> wondering whether SNMP is the right way to do. Maybe NETCONF?
>>
>> Potential solution:
>> Could we have specify the full exporter MIB as writable, but limit the
>> metering part to read-only in the "Units of Conformance"?
>> That way, the end customers will decide by pushing or not the vendor:
>> SNMP versus NETCONF versus CLI
>>
>> Regards, Benoit.
>>     
>>> Dear Benoit, Kobayashi and others,
>>>
>>> I want to summarize 2 points that arose in the current discussion of the
>>> IPFIX MIB and poll the list for comments how we should proceed with it.
>>>
>>> It is a fundamental decision if we should allow the IPFIX devices to be
>>> configured via SNMP. For the collector there is not much to configure but
>>> for the exporter there are many things that could be set-up, changed and
>>> deleted.
>>>
>>> Making the MIB writeable would have the consequence that we need to
>>> carefully review the status for each variable and table. We must define the
>>> row status and how it must be set and what each setting means. Furthermore
>>> we need to carefully elaborate the conformance section and need to discuss
>>> every writeable object in the security considerations. So it is a really big
>>> effort to make the MIB writeable so that it is secure to use it.
>>>
>>> Nevertheless, if the majority on the list has the opinion that it is really
>>> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>>> take that effort.
>>>
>>> Please keep in mind that the decision we take here would also affect the
>>> PSAMP MIB accordingly.
>>>
>>> Awaiting your comments,
>>>
>>> Thomas
>>>
>>>   
>>>  
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>>>   
>>>       
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>     
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Gerhard,


  
Dear all,

I assume that talking about Netconf implies talking about XML-based
configuration. Apart from offering the possiblity to reflect complex
configurations in an intuitive and comprehensible way, I see the
following advantage: XML makes it easy to extend the configuration with
new standardized or device/vendor-specific parameters. 



Good point. I forgot about the vendor-specific parameters.



Regards, Benoit.



  
This means, the
data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
probably have to cope with more dependencies which make it more
complicated to change its definition.
  





  
Regards,
Gerhard


Benoit Claise wrote:
  

  

    
 Dear all,

If the question is: "would you like to have a writable MIB",  the answer
will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful?

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that relates
to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?
     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
This would require the ipfixTemplateTable to have the following indexes:
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to express
whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether an
I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the
collector creates new templates.
- The collector configures the template Ids.
  Note: remember that the template Id are unique per observation domain
and per transport session.
  So now, if the SCTP association goes down, what should the collector do?
    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must be
set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this MIB,
I'm questioning this practicality/complexity... and as a consequence its
chances to be implemented if everything is read-write
However, I agree with the configuration of the exporting process information
Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

Regards, Benoit.
    

    

      
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  
 
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org <mailto:IPFIX@ietf.org>
https://www1.ietf.org/mailman/listinfo/ipfix
  
      

    

    
------------------------------------------------------------------------

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

  

  


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








--------------080703030909020000050003--


--===============2101131682==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============2101131682==--




From ipfix-bounces@ietf.org Fri Oct 20 09:32:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GauUF-0004bX-23; Fri, 20 Oct 2006 09:32:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GauUD-0004bQ-Qo
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:32:33 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GauUA-0007Xp-Ne
	for ipfix@ietf.org; Fri, 20 Oct 2006 09:32:33 -0400
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
	k9KDWTA07578; Fri, 20 Oct 2006 15:32:29 +0200 (CEST)
Received: from [10.61.82.125] (ams3-vpn-dhcp4734.cisco.com [10.61.82.125])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9KDWSP18743; Fri, 20 Oct 2006 15:32:28 +0200 (CEST)
Message-ID: <4538CFEC.9020209@cisco.com>
Date: Fri, 20 Oct 2006 15:32:28 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Gerhard Muenz 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <113091BD57179D4491C19DA7E10CD6963A4B81@mx1.office>	<4538C1EB.7010404@cisco.com>
	<4538C98C.50304@informatik.uni-tuebingen.de>
In-Reply-To: <4538C98C.50304@informatik.uni-tuebingen.de>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2101131682=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============2101131682==
Content-Type: multipart/alternative;
	boundary="------------080703030909020000050003"

This is a multi-part message in MIME format.
--------------080703030909020000050003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gerhard,
> Dear all,
>
> I assume that talking about Netconf implies talking about XML-based
> configuration. Apart from offering the possiblity to reflect complex
> configurations in an intuitive and comprehensible way, I see the
> following advantage: XML makes it easy to extend the configuration with
> new standardized or device/vendor-specific parameters. 
Good point. I forgot about the vendor-specific parameters.

Regards, Benoit.
> This means, the
> data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
> probably have to cope with more dependencies which make it more
> complicated to change its definition.
>   
> Regards,
> Gerhard
>
>
> Benoit Claise wrote:
>   
>>  Dear all,
>>
>> If the question is: "would you like to have a writable MIB",  the answer
>> will probably be: "sure, it's useful/nice-to-have!"
>> It's a logical answer when you offer the choice of a solution with more
>> features compared to a solution with less features.
>>
>> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
>> be saved?
>> http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
>> let me ask the question differently: will this read-write MIB be
>> practical and useful?
>>
>> Let me concentrate on the Exporter MIB, as the Collector MIB should be
>> read-only (what can we configure on the collector side?)
>> Even if the information related to the IPFIX exporting process (such as
>> where to export, which transport protocol, which port, backup or not,
>> template retransmission timeout, etc...) is somehow pretty static in
>> networks, this type of configuration via SNMP might be useful.
>> However, I'm not sure about the configuration of everything that relates
>> to metering process as it's getting pretty complex.
>> For example, is it practical to specify via SNMP all the possible the
>> template definition from Flexible NetFlow?
>>      Flexible NetFlow =
>> http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
>> This would require the ipfixTemplateTable to have the following indexes:
>>     the transport session source IP address
>>     the transport session destination IP address
>>     the transport session source port
>>     the transport session destination port
>>     the observation domain Id
>>     the template Id
>>     the information element position
>> A table with 7 indexes. Sure, it's possible but this starts to be quite
>> a complex MIB
>> Some more remarks that will add to the complexity:
>> - In ipfixTemplateTable, we still need to find a way via SNMP to express
>> whether a specific I.E. is a flow key or not
>> - We have the choice of template versus options template. So an extra
>> table for options template is required. In this table, as we can have
>> multiple scope information elements, we need a way to express whether an
>> I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
>> - This implies that Template Ids are assigned by the collector if the
>> collector creates new templates.
>> - The collector configures the template Ids.
>>   Note: remember that the template Id are unique per observation domain
>> and per transport session.
>>   So now, if the SCTP association goes down, what should the collector do?
>>     1. erase all the templates on the exporter, and reconfigure them?
>> This implies that if only the connection is down, not the metering
>> process, then this action basically stopped the metering process
>>     2. wait for the template retransmission? What if the metering
>> process went down and the template id allocation changed. Shall the
>> collector update his MIB?
>>     3. something else?
>> - As Thomas mentioned: "We must define the row status and how it must be
>> set and what each setting means."
>>
>> To summarize, my views are:
>> Even if this might be an interesting little challenge to write this MIB,
>> I'm questioning this practicality/complexity... and as a consequence its
>> chances to be implemented if everything is read-write
>> However, I agree with the configuration of the exporting process information
>> Finally I agree that a way to configure the templates is needed, I'm
>> wondering whether SNMP is the right way to do. Maybe NETCONF?
>>
>> Potential solution:
>> Could we have specify the full exporter MIB as writable, but limit the
>> metering part to read-only in the "Units of Conformance"?
>> That way, the end customers will decide by pushing or not the vendor:
>> SNMP versus NETCONF versus CLI
>>
>> Regards, Benoit.
>>     
>>> Dear Benoit, Kobayashi and others,
>>>
>>> I want to summarize 2 points that arose in the current discussion of the
>>> IPFIX MIB and poll the list for comments how we should proceed with it.
>>>
>>> It is a fundamental decision if we should allow the IPFIX devices to be
>>> configured via SNMP. For the collector there is not much to configure but
>>> for the exporter there are many things that could be set-up, changed and
>>> deleted.
>>>
>>> Making the MIB writeable would have the consequence that we need to
>>> carefully review the status for each variable and table. We must define the
>>> row status and how it must be set and what each setting means. Furthermore
>>> we need to carefully elaborate the conformance section and need to discuss
>>> every writeable object in the security considerations. So it is a really big
>>> effort to make the MIB writeable so that it is secure to use it.
>>>
>>> Nevertheless, if the majority on the list has the opinion that it is really
>>> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>>> take that effort.
>>>
>>> Please keep in mind that the decision we take here would also affect the
>>> PSAMP MIB accordingly.
>>>
>>> Awaiting your comments,
>>>
>>> Thomas
>>>
>>>   
>>>  
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/ipfix
>>>   
>>>       
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>     
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   


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




  


Gerhard,


  
Dear all,

I assume that talking about Netconf implies talking about XML-based
configuration. Apart from offering the possiblity to reflect complex
configurations in an intuitive and comprehensible way, I see the
following advantage: XML makes it easy to extend the configuration with
new standardized or device/vendor-specific parameters. 



Good point. I forgot about the vendor-specific parameters.



Regards, Benoit.



  
This means, the
data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
probably have to cope with more dependencies which make it more
complicated to change its definition.
  





  
Regards,
Gerhard


Benoit Claise wrote:
  

  

    
 Dear all,

If the question is: "would you like to have a writable MIB",  the answer
will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful?

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that relates
to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?
     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
This would require the ipfixTemplateTable to have the following indexes:
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to express
whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether an
I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the
collector creates new templates.
- The collector configures the template Ids.
  Note: remember that the template Id are unique per observation domain
and per transport session.
  So now, if the SCTP association goes down, what should the collector do?
    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must be
set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this MIB,
I'm questioning this practicality/complexity... and as a consequence its
chances to be implemented if everything is read-write
However, I agree with the configuration of the exporting process information
Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

Regards, Benoit.
    

    

      
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  
 
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org <mailto:IPFIX@ietf.org>
https://www1.ietf.org/mailman/listinfo/ipfix
  
      

    

    
------------------------------------------------------------------------

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

  

  


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








--------------080703030909020000050003--


--===============2101131682==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============2101131682==--




From ipfix-bounces@ietf.org Fri Oct 20 10:14:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gav7U-0004an-HM; Fri, 20 Oct 2006 10:13:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav7T-0004ZP-Cp
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:13:07 -0400
Received: from sccrmhc14.comcast.net ([204.127.200.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gav7O-0006Dq-GV
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:13:07 -0400
Received: from harrington73653 (x176.flex.surfnet.nl[192.87.117.176])
	by comcast.net (sccrmhc14) with SMTP
	id <2006102014130101400q5hfve>; Fri, 20 Oct 2006 14:13:01 +0000
From: "David Harrington" 
To: "'Benoit Claise'" ,
	"'Thomas Dietz'" 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 16:10:33 +0200
Message-ID: <030301c6f451$85959960$b07557c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4538C1EB.7010404@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: Acb0RB9+25UOHNvST2WB+lKYgQCmDAAB1DxA
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1938187425=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1938187425==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0304_01C6F462.491E6960"

This is a multi-part message in MIME format.

------=_NextPart_000_0304_01C6F462.491E6960
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
The question that was originally proposed was "should the IPFIX MIB be
writable?"
I believe there would be benefit to making IPFIX manageable.
Since you have defined a MIB module to perform management, it seems a
simple extension to make some of the objects writable, rather than
requring a whole extra protocol be supported to configure ipfix
parameters. 
 
Has anybody argued that every aspect of IPFIX should be configurable
using the MIB module? I haven't seen anybody make such an argument,
and I am not making such an argument. Deciding that none of the
objects CAN be used by an application to modify the configuration of
IPFIX may make it difficiult to configure ipfix functionality. 
 
Some of the questions below deal with anomalies, such as SCTP going
down. The question is not about SNMP, it is about interoperable IPFIX
behavior and should be addressed regardless of the management protocol
being used to do configuration.
If a collector uses Netconf to configure the templates, and SCTP goes
down, what should the collector do? delete the templates and
reconfigure them from scratch? wait for the template retransmission?
something else? What if CLI is used? The fact that some of the config
is done using SNMP should not be the telling factor; the appropriate
behavior should be specified regardless of config protocol.
 
Even if template management were to be addressed, there are ways to
reduce the complexity of configuration.
 
The question that should be asked is "which aspects of ipfix should be
made manageable, and how?". Such a discussion should consider issues
of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and
so on. And thsi discussion should happen whether the MIB module is
made writable or not.
 
David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net



  _____  

From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?


Dear all,

If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with
more features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can
it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduct
ion),  let me ask the question differently: will this read-write MIB
be practical and useful? 

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such
as where to export, which transport protocol, which port, backup or
not, template retransmission timeout, etc...) is somehow pretty static
in networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?
     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd
804be091.shtml
This would require the ipfixTemplateTable to have the following
indexes: 
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be
quite a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the
collector creates new templates.
- The collector configures the template Ids. 
  Note: remember that the template Id are unique per observation
domain and per transport session. 
  So now, if the SCTP association goes down, what should the collector
do?
    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 
However, I agree with the configuration of the exporting process
information
Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

Regards, Benoit.


Dear Benoit, Kobayashi and others,



I want to summarize 2 points that arose in the current discussion of
the

IPFIX MIB and poll the list for comments how we should proceed with
it.



It is a fundamental decision if we should allow the IPFIX devices to
be

configured via SNMP. For the collector there is not much to configure
but

for the exporter there are many things that could be set-up, changed
and

deleted.



Making the MIB writeable would have the consequence that we need to

carefully review the status for each variable and table. We must
define the

row status and how it must be set and what each setting means.
Furthermore

we need to carefully elaborate the conformance section and need to
discuss

every writeable object in the security considerations. So it is a
really big

effort to make the MIB writeable so that it is secure to use it.



Nevertheless, if the majority on the list has the opinion that it is
really

useful to have the MIB (especially the EXPORTER MIB) writeable than we
would

take that effort.



Please keep in mind that the decision we take here would also affect
the

PSAMP MIB accordingly.



Awaiting your comments,



Thomas



  


  _____  


_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www1.ietf.org/mailman/listinfo/ipfix

  



------=_NextPart_000_0304_01C6F462.491E6960
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi,


 


The question that was originally proposed was =
"should the=20
IPFIX MIB be writable?"


I believe there would be benefit to making =
IPFIX=20
manageable.


Since you have defined a MIB module to perform =
management,=20
it seems a simple extension to make some of the objects writable, rather =
than=20
requring a whole extra protocol be supported to configure ipfix =
parameters.=20



 


Has anybody argued that every aspect of IPFIX =
should be=20
configurable using the MIB module? I haven't seen anybody make such an =
argument,=20
and I am not making such an argument. Deciding that none of the objects =
CAN be used by=20
an application to modify the configuration of IPFIX may make it =
difficiult to=20
configure ipfix functionality. 


 


Some of the questions below deal with =
anomalies, such as=20
SCTP going down. The question is not about SNMP, it is about =
interoperable IPFIX=20
behavior and should be addressed regardless of the management protocol =
being=20
used to do configuration.


If a collector uses Netconf to configure =
the=20
templates, and SCTP goes down, what should the collector do? delete the=20
templates and reconfigure them from scratch? wait for the template=20
retransmission? something else? What if CLI is used? The fact that some =
of the=20
config is done using SNMP should not be the telling factor; the =
appropriate=20
behavior should be specified regardless of config =
protocol.


 




Even if template management were to be =
addressed,=20
there are ways to reduce the complexity of=20
configuration.


 


The question that should be asked is "which =
aspects of=20
ipfix should be made manageable, and how?". Such a discussion should =
consider=20
issues of persistence, fate-sharing, static vs. dynamic aspects of =
ipfix, and so=20
on. And thsi discussion should happen whether the MIB module is made =
writable or=20
not.


 




David=20
Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfd=
bh@comcast.net



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas =

  Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] =
Should the=20
  IPFIX MIB be writeable?


  
Dear all,

If the question is: "would you like to =
have a=20
  writable MIB",  the answer will probably be: "sure, it's=20
  useful/nice-to-have!"
It's a logical answer when you offer the =
choice of a=20
  solution with more features compared to a solution with less=20
  features.

While I don't want to restart a discussion on SNMPset =

  ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#in=
troduction), =20
  let me ask the question differently: will this read-write MIB be =
practical and=20
  useful? 

Let me concentrate on the Exporter MIB, as the =
Collector MIB=20
  should be read-only (what can we configure on the collector =
side?)
Even if=20
  the information related to the IPFIX exporting process (such as where =
to=20
  export, which transport protocol, which port, backup or not, template=20
  retransmission timeout, etc...) is somehow pretty static in networks, =
this=20
  type of configuration via SNMP might be useful.
However, I'm not =
sure about=20
  the configuration of everything that relates to metering process as =
it's=20
  getting pretty complex.
For example, is it practical to specify via =
SNMP=20
  all the possible the template definition from Flexible=20
  NetFlow?
     Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_=
qanda_item0900aecd804be091.shtml
This=20
  would require the ipfixTemplateTable to have the following indexes:=20
  
    the transport session source IP=20
  address
    the transport session destination IP=20
  address
    the transport session source=20
  port
    the transport session destination=20
  port
    the observation domain =
Id
    the=20
  template Id
    the information element =
position
A table=20
  with 7 indexes. Sure, it's possible but this starts to be quite a =
complex=20
  MIB
Some more remarks that will add to the complexity:
- In=20
  ipfixTemplateTable, we still need to find a way via SNMP to express =
whether a=20
  specific I.E. is a flow key or not
- We have the choice of template =
versus=20
  options template. So an extra table for options template is required. =
In this=20
  table, as we can have multiple scope information elements, we need a =
way to=20
  express whether an I.E. is a scope or not (similar to flow key in=20
  ipfixTemplateTable)
- This implies that Template Ids are assigned =
by the=20
  collector if the collector creates new templates.
- The collector=20
  configures the template Ids. 
  Note: remember that the =
template Id=20
  are unique per observation domain and per transport session. =

  So=20
  now, if the SCTP association goes down, what should the collector=20
  do?
    1. erase all the templates on the exporter, =
and=20
  reconfigure them? This implies that if only the connection is down, =
not the=20
  metering process, then this action basically stopped the metering=20
  process
    2. wait for the template retransmission? =
What if=20
  the metering process went down and the template id allocation changed. =
Shall=20
  the collector update his MIB?
    3. something =
else?
- As=20
  Thomas mentioned: "We must define the row status and how it must be =
set and=20
  what each setting means."

To summarize, my views are:
Even =
if this=20
  might be an interesting little challenge to write this MIB, I'm =
questioning=20
  this practicality/complexity... and as a consequence its chances to be =

  implemented if everything is read-write 
However, I agree with the=20
  configuration of the exporting process information
Finally I agree =
that a=20
  way to configure the templates is needed, I'm wondering whether SNMP =
is the=20
  right way to do. Maybe NETCONF?

Potential solution:
Could we =
have=20
  specify the full exporter MIB as writable, but limit the metering part =
to=20
  read-only in the "Units of =

  Conformance"?
That way, the end customers will decide by pushing or =
not the=20
  vendor: SNMP versus NETCONF versus CLI

Regards,=20
  Benoit.

  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipfix
  



------=_NextPart_000_0304_01C6F462.491E6960--




--===============1938187425==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1938187425==--






From ipfix-bounces@ietf.org Fri Oct 20 10:14:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gav7U-0004an-HM; Fri, 20 Oct 2006 10:13:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav7T-0004ZP-Cp
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:13:07 -0400
Received: from sccrmhc14.comcast.net ([204.127.200.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gav7O-0006Dq-GV
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:13:07 -0400
Received: from harrington73653 (x176.flex.surfnet.nl[192.87.117.176])
	by comcast.net (sccrmhc14) with SMTP
	id <2006102014130101400q5hfve>; Fri, 20 Oct 2006 14:13:01 +0000
From: "David Harrington" 
To: "'Benoit Claise'" ,
	"'Thomas Dietz'" 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 16:10:33 +0200
Message-ID: <030301c6f451$85959960$b07557c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4538C1EB.7010404@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: Acb0RB9+25UOHNvST2WB+lKYgQCmDAAB1DxA
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1938187425=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1938187425==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0304_01C6F462.491E6960"

This is a multi-part message in MIME format.

------=_NextPart_000_0304_01C6F462.491E6960
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
The question that was originally proposed was "should the IPFIX MIB be
writable?"
I believe there would be benefit to making IPFIX manageable.
Since you have defined a MIB module to perform management, it seems a
simple extension to make some of the objects writable, rather than
requring a whole extra protocol be supported to configure ipfix
parameters. 
 
Has anybody argued that every aspect of IPFIX should be configurable
using the MIB module? I haven't seen anybody make such an argument,
and I am not making such an argument. Deciding that none of the
objects CAN be used by an application to modify the configuration of
IPFIX may make it difficiult to configure ipfix functionality. 
 
Some of the questions below deal with anomalies, such as SCTP going
down. The question is not about SNMP, it is about interoperable IPFIX
behavior and should be addressed regardless of the management protocol
being used to do configuration.
If a collector uses Netconf to configure the templates, and SCTP goes
down, what should the collector do? delete the templates and
reconfigure them from scratch? wait for the template retransmission?
something else? What if CLI is used? The fact that some of the config
is done using SNMP should not be the telling factor; the appropriate
behavior should be specified regardless of config protocol.
 
Even if template management were to be addressed, there are ways to
reduce the complexity of configuration.
 
The question that should be asked is "which aspects of ipfix should be
made manageable, and how?". Such a discussion should consider issues
of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and
so on. And thsi discussion should happen whether the MIB module is
made writable or not.
 
David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net



  _____  

From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?


Dear all,

If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with
more features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can
it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduct
ion),  let me ask the question differently: will this read-write MIB
be practical and useful? 

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such
as where to export, which transport protocol, which port, backup or
not, template retransmission timeout, etc...) is somehow pretty static
in networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?
     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd
804be091.shtml
This would require the ipfixTemplateTable to have the following
indexes: 
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be
quite a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the
collector creates new templates.
- The collector configures the template Ids. 
  Note: remember that the template Id are unique per observation
domain and per transport session. 
  So now, if the SCTP association goes down, what should the collector
do?
    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 
However, I agree with the configuration of the exporting process
information
Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

Regards, Benoit.


Dear Benoit, Kobayashi and others,



I want to summarize 2 points that arose in the current discussion of
the

IPFIX MIB and poll the list for comments how we should proceed with
it.



It is a fundamental decision if we should allow the IPFIX devices to
be

configured via SNMP. For the collector there is not much to configure
but

for the exporter there are many things that could be set-up, changed
and

deleted.



Making the MIB writeable would have the consequence that we need to

carefully review the status for each variable and table. We must
define the

row status and how it must be set and what each setting means.
Furthermore

we need to carefully elaborate the conformance section and need to
discuss

every writeable object in the security considerations. So it is a
really big

effort to make the MIB writeable so that it is secure to use it.



Nevertheless, if the majority on the list has the opinion that it is
really

useful to have the MIB (especially the EXPORTER MIB) writeable than we
would

take that effort.



Please keep in mind that the decision we take here would also affect
the

PSAMP MIB accordingly.



Awaiting your comments,



Thomas



  


  _____  


_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www1.ietf.org/mailman/listinfo/ipfix

  



------=_NextPart_000_0304_01C6F462.491E6960
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi,


 


The question that was originally proposed was =
"should the=20
IPFIX MIB be writable?"


I believe there would be benefit to making =
IPFIX=20
manageable.


Since you have defined a MIB module to perform =
management,=20
it seems a simple extension to make some of the objects writable, rather =
than=20
requring a whole extra protocol be supported to configure ipfix =
parameters.=20



 


Has anybody argued that every aspect of IPFIX =
should be=20
configurable using the MIB module? I haven't seen anybody make such an =
argument,=20
and I am not making such an argument. Deciding that none of the objects =
CAN be used by=20
an application to modify the configuration of IPFIX may make it =
difficiult to=20
configure ipfix functionality. 


 


Some of the questions below deal with =
anomalies, such as=20
SCTP going down. The question is not about SNMP, it is about =
interoperable IPFIX=20
behavior and should be addressed regardless of the management protocol =
being=20
used to do configuration.


If a collector uses Netconf to configure =
the=20
templates, and SCTP goes down, what should the collector do? delete the=20
templates and reconfigure them from scratch? wait for the template=20
retransmission? something else? What if CLI is used? The fact that some =
of the=20
config is done using SNMP should not be the telling factor; the =
appropriate=20
behavior should be specified regardless of config =
protocol.


 




Even if template management were to be =
addressed,=20
there are ways to reduce the complexity of=20
configuration.


 


The question that should be asked is "which =
aspects of=20
ipfix should be made manageable, and how?". Such a discussion should =
consider=20
issues of persistence, fate-sharing, static vs. dynamic aspects of =
ipfix, and so=20
on. And thsi discussion should happen whether the MIB module is made =
writable or=20
not.


 




David=20
Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfd=
bh@comcast.net



  

  

  From: Benoit Claise =
[mailto:bclaise@cisco.com]=20
  
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas =

  Dietz
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] =
Should the=20
  IPFIX MIB be writeable?


  
Dear all,

If the question is: "would you like to =
have a=20
  writable MIB",  the answer will probably be: "sure, it's=20
  useful/nice-to-have!"
It's a logical answer when you offer the =
choice of a=20
  solution with more features compared to a solution with less=20
  features.

While I don't want to restart a discussion on SNMPset =

  ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#in=
troduction), =20
  let me ask the question differently: will this read-write MIB be =
practical and=20
  useful? 

Let me concentrate on the Exporter MIB, as the =
Collector MIB=20
  should be read-only (what can we configure on the collector =
side?)
Even if=20
  the information related to the IPFIX exporting process (such as where =
to=20
  export, which transport protocol, which port, backup or not, template=20
  retransmission timeout, etc...) is somehow pretty static in networks, =
this=20
  type of configuration via SNMP might be useful.
However, I'm not =
sure about=20
  the configuration of everything that relates to metering process as =
it's=20
  getting pretty complex.
For example, is it practical to specify via =
SNMP=20
  all the possible the template definition from Flexible=20
  NetFlow?
     Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_=
qanda_item0900aecd804be091.shtml
This=20
  would require the ipfixTemplateTable to have the following indexes:=20
  
    the transport session source IP=20
  address
    the transport session destination IP=20
  address
    the transport session source=20
  port
    the transport session destination=20
  port
    the observation domain =
Id
    the=20
  template Id
    the information element =
position
A table=20
  with 7 indexes. Sure, it's possible but this starts to be quite a =
complex=20
  MIB
Some more remarks that will add to the complexity:
- In=20
  ipfixTemplateTable, we still need to find a way via SNMP to express =
whether a=20
  specific I.E. is a flow key or not
- We have the choice of template =
versus=20
  options template. So an extra table for options template is required. =
In this=20
  table, as we can have multiple scope information elements, we need a =
way to=20
  express whether an I.E. is a scope or not (similar to flow key in=20
  ipfixTemplateTable)
- This implies that Template Ids are assigned =
by the=20
  collector if the collector creates new templates.
- The collector=20
  configures the template Ids. 
  Note: remember that the =
template Id=20
  are unique per observation domain and per transport session. =

  So=20
  now, if the SCTP association goes down, what should the collector=20
  do?
    1. erase all the templates on the exporter, =
and=20
  reconfigure them? This implies that if only the connection is down, =
not the=20
  metering process, then this action basically stopped the metering=20
  process
    2. wait for the template retransmission? =
What if=20
  the metering process went down and the template id allocation changed. =
Shall=20
  the collector update his MIB?
    3. something =
else?
- As=20
  Thomas mentioned: "We must define the row status and how it must be =
set and=20
  what each setting means."

To summarize, my views are:
Even =
if this=20
  might be an interesting little challenge to write this MIB, I'm =
questioning=20
  this practicality/complexity... and as a consequence its chances to be =

  implemented if everything is read-write 
However, I agree with the=20
  configuration of the exporting process information
Finally I agree =
that a=20
  way to configure the templates is needed, I'm wondering whether SNMP =
is the=20
  right way to do. Maybe NETCONF?

Potential solution:
Could we =
have=20
  specify the full exporter MIB as writable, but limit the metering part =
to=20
  read-only in the "Units of =

  Conformance"?
That way, the end customers will decide by pushing or =
not the=20
  vendor: SNMP versus NETCONF versus CLI

Regards,=20
  Benoit.

  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipfix
  



------=_NextPart_000_0304_01C6F462.491E6960--




--===============1938187425==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1938187425==--






From ipfix-bounces@ietf.org Fri Oct 20 10:59:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GavpJ-00058a-5B; Fri, 20 Oct 2006 10:58:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GavpH-00056v-AM
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:58:23 -0400
Received: from relay01.pair.com ([209.68.5.15])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GavpC-0005Zm-2f
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:58:23 -0400
Received: (qmail 24849 invoked from network); 20 Oct 2006 14:58:15 -0000
Received: from unknown (HELO ?192.168.0.66?) (unknown)
	by unknown with SMTP; 20 Oct 2006 14:58:15 -0000
X-pair-Authenticated: 207.237.36.98
In-Reply-To: <030301c6f451$85959960$b07557c0@china.huawei.com>
References: <030301c6f451$85959960$b07557c0@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: 
From: Carter Bullard 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 10:58:10 -0400
To: "David Harrington" 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0546861161=="
Errors-To: ipfix-bounces@ietf.org


--===============0546861161==
Content-Type: multipart/alternative; boundary=Apple-Mail-1-512980457


--Apple-Mail-1-512980457
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Gentle people,
    I brought up this question much earlier.  If the IPFIX WG is  
genuinely specifying a
transport protocol, then the nature of the MIB should resemble those  
of other transport
protocols.   SCTP (RFC 3873) and TCP (RFC 4022) are good examples,  
there is only
one object in either MIB that is "read-write", and that allows a  
management station to
'delete' or 'close' an SCTP or TCP connection.   All other MIB  
objects are read-only.

Which is what you would expect for a transport protocol MIB.

Carter


On Oct 20, 2006, at 10:10 AM, David Harrington wrote:

> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB  
> be writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems  
> a simple extension to make some of the objects writable, rather  
> than requring a whole extra protocol be supported to configure  
> ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be  
> configurable using the MIB module? I haven't seen anybody make such  
> an argument, and I am not making such an argument. Deciding that  
> none of the objects CAN be used by an application to modify the  
> configuration of IPFIX may make it difficiult to configure ipfix  
> functionality.
>
> Some of the questions below deal with anomalies, such as SCTP going  
> down. The question is not about SNMP, it is about interoperable  
> IPFIX behavior and should be addressed regardless of the management  
> protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP  
> goes down, what should the collector do? delete the templates and  
> reconfigure them from scratch? wait for the template  
> retransmission? something else? What if CLI is used? The fact that  
> some of the config is done using SNMP should not be the telling  
> factor; the appropriate behavior should be specified regardless of  
> config protocol.
>
> Even if template management were to be addressed, there are ways to  
> reduce the complexity of configuration.
>
> The question that should be asked is "which aspects of ipfix should  
> be made manageable, and how?". Such a discussion should consider  
> issues of persistence, fate-sharing, static vs. dynamic aspects of  
> ipfix, and so on. And thsi discussion should happen whether the MIB  
> module is made writable or not.
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Friday, October 20, 2006 2:33 PM
> To: Thomas Dietz
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
>
> Dear all,
>
> If the question is: "would you like to have a writable MIB",  the  
> answer will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with  
> more features compared to a solution with less features.
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet:  
> can it be saved? http://www.simple-times.org/pub/simple-times/ 
> issues/9-1.html#introduction),  let me ask the question  
> differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should  
> be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process  
> (such as where to export, which transport protocol, which port,  
> backup or not, template retransmission timeout, etc...) is somehow  
> pretty static in networks, this type of configuration via SNMP  
> might be useful.
> However, I'm not sure about the configuration of everything that  
> relates to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible  
> the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/ 
> products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following  
> indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be  
> quite a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to  
> express whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an  
> extra table for options template is required. In this table, as we  
> can have multiple scope information elements, we need a way to  
> express whether an I.E. is a scope or not (similar to flow key in  
> ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if  
> the collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation  
> domain and per transport session.
>   So now, if the SCTP association goes down, what should the  
> collector do?
>     1. erase all the templates on the exporter, and reconfigure  
> them? This implies that if only the connection is down, not the  
> metering process, then this action basically stopped the metering  
> process
>     2. wait for the template retransmission? What if the metering  
> process went down and the template id allocation changed. Shall the  
> collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it  
> must be set and what each setting means."
>
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this  
> MIB, I'm questioning this practicality/complexity... and as a  
> consequence its chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process  
> information
> Finally I agree that a way to configure the templates is needed,  
> I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit  
> the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the  
> vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.
>> Dear Benoit, Kobayashi and others,
>>
>> I want to summarize 2 points that arose in the current discussion  
>> of the
>> IPFIX MIB and poll the list for comments how we should proceed  
>> with it.
>>
>> It is a fundamental decision if we should allow the IPFIX devices  
>> to be
>> configured via SNMP. For the collector there is not much to  
>> configure but
>> for the exporter there are many things that could be set-up,  
>> changed and
>> deleted.
>>
>> Making the MIB writeable would have the consequence that we need to
>> carefully review the status for each variable and table. We must  
>> define the
>> row status and how it must be set and what each setting means.  
>> Furthermore
>> we need to carefully elaborate the conformance section and need to  
>> discuss
>> every writeable object in the security considerations. So it is a  
>> really big
>> effort to make the MIB writeable so that it is secure to use it.
>>
>> Nevertheless, if the majority on the list has the opinion that it  
>> is really
>> useful to have the MIB (especially the EXPORTER MIB) writeable  
>> than we would
>> take that effort.
>>
>> Please keep in mind that the decision we take here would also  
>> affect the
>> PSAMP MIB accordingly.
>>
>> Awaiting your comments,
>>
>> Thomas
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>
>





--Apple-Mail-1-512980457
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

Gentle people,
=A0 =A0I =
brought up this question much earlier.=A0 If the IPFIX WG =
is=A0genuinely=A0specifying a
transport protocol, then the =
nature of the MIB should resemble those of other =
transport
protocols.=A0 =A0SCTP (RFC 3873) and TCP (RFC 4022) =
are good examples, there is only
one object in either MIB that =
is=A0"read-write", and that allows a management station =
to
'delete' or 'close' an SCTP or TCP connection.=A0 =A0All =
other MIB objects are read-only.

Which is what you would =
expect for a=A0transport protocol MIB.

Carter


On Oct 20, =
2006, at 10:10 AM, David Harrington wrote:

 
Hi,
 
=A0
 
The question that was =
originally proposed was "should the IPFIX MIB be =
writable?"
 
I believe there would be benefit to making IPFIX =
manageable.
 
Since you have defined a MIB module to perform management, it =
seems a simple extension to make some of the objects writable, rather =
than requring a whole extra protocol be supported to configure ipfix =
parameters. 
 
=A0
 
Has anybody argued that =
every aspect of IPFIX should be configurable using the MIB module? I =
haven't seen anybody make such an argument, and I am not making such an =
argument. Deciding that none of the objects CAN be =
used by an application to modify the configuration of IPFIX may make it =
difficiult to configure ipfix functionality. =

 
=A0
 
Some of the questions below deal with anomalies, such as SCTP =
going down. The question is not about SNMP, it is about interoperable =
IPFIX behavior and should be addressed regardless of the management =
protocol being used to do configuration.
 
If a collector uses =
Netconf=A0to configure the templates, and SCTP goes down, what should =
the collector do? delete the templates and reconfigure them from =
scratch? wait for the template retransmission? something else? What if =
CLI is used? The fact that some of the config is done using SNMP should =
not be the telling factor; the appropriate behavior should be specified =
regardless of config protocol.
 
=A0
 
 
Even if template management were to be =
addressed, there=A0are ways=A0to reduce the complexity of =
configuration.
 
=A0
 
The question that should be asked is "which =
aspects of ipfix should be made manageable, and how?". Such a discussion =
should consider issues of persistence, fate-sharing, static vs. dynamic =
aspects of ipfix, and so on. And thsi discussion should happen whether =
the MIB module is made writable or not.
 
=A0
 
David Harrington
dharrington@huawei.com
dbhar=
rington@comcast.net
ietfdbh@comcast.net

 
  
 =
 
  From: =
Benoit Claise [mailto:bclaise@cisco.com]   =

Sent: Friday, October 20, 2006 2:33 PM
To: Thomas   =
Dietz
Cc: ipfix@ietf.org
Subject: Re: =
[IPFIX] Should the   IPFIX MIB be writeable?

  =

Dear all,

If the question is: "would you like to have =
a   writable MIB",=A0 the answer will probably be: "sure, it's   =
useful/nice-to-have!"
It's a logical answer when you offer the choice =
of a   solution with more features compared to a solution with less   =
features.

While I don't want to restart a discussion on SNMPset   =
("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#intr=
oduction),=A0   let me ask the question differently: will this =
read-write MIB be practical and   useful? 

Let me concentrate on =
the Exporter MIB, as the Collector MIB   should be read-only (what can =
we configure on the collector side?)
Even if   the information =
related to the IPFIX exporting process (such as where to   export, which =
transport protocol, which port, backup or not, template   retransmission =
timeout, etc...) is somehow pretty static in networks, this   type of =
configuration via SNMP might be useful.
However, I'm not sure about   =
the configuration of everything that relates to metering process as it's =
  getting pretty complex.
For example, is it practical to specify via =
SNMP   all the possible the template definition from Flexible   =
NetFlow?
=A0=A0=A0=A0 Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_qa=
nda_item0900aecd804be091.shtml
This   would require the =
ipfixTemplateTable to have the following indexes:   
=A0=A0=A0 the =
transport session source IP   address
=A0=A0=A0 the transport session =
destination IP   address
=A0=A0=A0 the transport session source   =
port
=A0=A0=A0 the transport session destination   port
=A0=A0=A0 =
the observation domain Id
=A0=A0=A0 the   template Id
=A0=A0=A0 =
the information element position
A table   with 7 indexes. Sure, it's =
possible but this starts to be quite a complex   MIB
Some more =
remarks that will add to the complexity:
- In   ipfixTemplateTable, =
we still need to find a way via SNMP to express whether a   specific =
I.E. is a flow key or not
- We have the choice of template versus   =
options template. So an extra table for options template is required. In =
this   table, as we can have multiple scope information elements, we =
need a way to   express whether an I.E. is a scope or not (similar to =
flow key in   ipfixTemplateTable)
- This implies that Template Ids =
are assigned by the   collector if the collector creates new =
templates.
- The collector   configures the template Ids. 
=A0 =
Note: remember that the template Id   are unique per observation domain =
and per transport session. 
=A0 So   now, if the SCTP association =
goes down, what should the collector   do?
=A0=A0=A0 1. erase all the =
templates on the exporter, and   reconfigure them? This implies that if =
only the connection is down, not the   metering process, then this =
action basically stopped the metering   process
=A0=A0=A0 2. wait for =
the template retransmission? What if   the metering process went down =
and the template id allocation changed. Shall   the collector update his =
MIB?
=A0=A0=A0 3. something else?
- As   Thomas mentioned: "We =
must define the row status and how it must be set and   what each =
setting means."

To summarize, my views are:
Even if this   =
might be an interesting little challenge to write this MIB, I'm =
questioning   this practicality/complexity... and as a consequence its =
chances to be   implemented if everything is read-write 
However, I =
agree with the   configuration of the exporting process =
information
Finally I agree that a   way to configure the templates =
is needed, I'm wondering whether SNMP is the   right way to do. Maybe =
NETCONF?

Potential solution:
Could we have   specify the full =
exporter MIB as writable, but limit the metering part to   read-only in =
the "Units of   =
Conformance"?
That way, the end customers will decide by pushing or =
not the   vendor: SNMP versus NETCONF versus =
CLI

Regards,   Benoit.
  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/ipfix
  




 =


=

--Apple-Mail-1-512980457--


--===============0546861161==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0546861161==--




From ipfix-bounces@ietf.org Fri Oct 20 10:59:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GavpJ-00058a-5B; Fri, 20 Oct 2006 10:58:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GavpH-00056v-AM
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:58:23 -0400
Received: from relay01.pair.com ([209.68.5.15])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GavpC-0005Zm-2f
	for ipfix@ietf.org; Fri, 20 Oct 2006 10:58:23 -0400
Received: (qmail 24849 invoked from network); 20 Oct 2006 14:58:15 -0000
Received: from unknown (HELO ?192.168.0.66?) (unknown)
	by unknown with SMTP; 20 Oct 2006 14:58:15 -0000
X-pair-Authenticated: 207.237.36.98
In-Reply-To: <030301c6f451$85959960$b07557c0@china.huawei.com>
References: <030301c6f451$85959960$b07557c0@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: 
From: Carter Bullard 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
Date: Fri, 20 Oct 2006 10:58:10 -0400
To: "David Harrington" 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0546861161=="
Errors-To: ipfix-bounces@ietf.org


--===============0546861161==
Content-Type: multipart/alternative; boundary=Apple-Mail-1-512980457


--Apple-Mail-1-512980457
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Gentle people,
    I brought up this question much earlier.  If the IPFIX WG is  
genuinely specifying a
transport protocol, then the nature of the MIB should resemble those  
of other transport
protocols.   SCTP (RFC 3873) and TCP (RFC 4022) are good examples,  
there is only
one object in either MIB that is "read-write", and that allows a  
management station to
'delete' or 'close' an SCTP or TCP connection.   All other MIB  
objects are read-only.

Which is what you would expect for a transport protocol MIB.

Carter


On Oct 20, 2006, at 10:10 AM, David Harrington wrote:

> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB  
> be writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems  
> a simple extension to make some of the objects writable, rather  
> than requring a whole extra protocol be supported to configure  
> ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be  
> configurable using the MIB module? I haven't seen anybody make such  
> an argument, and I am not making such an argument. Deciding that  
> none of the objects CAN be used by an application to modify the  
> configuration of IPFIX may make it difficiult to configure ipfix  
> functionality.
>
> Some of the questions below deal with anomalies, such as SCTP going  
> down. The question is not about SNMP, it is about interoperable  
> IPFIX behavior and should be addressed regardless of the management  
> protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP  
> goes down, what should the collector do? delete the templates and  
> reconfigure them from scratch? wait for the template  
> retransmission? something else? What if CLI is used? The fact that  
> some of the config is done using SNMP should not be the telling  
> factor; the appropriate behavior should be specified regardless of  
> config protocol.
>
> Even if template management were to be addressed, there are ways to  
> reduce the complexity of configuration.
>
> The question that should be asked is "which aspects of ipfix should  
> be made manageable, and how?". Such a discussion should consider  
> issues of persistence, fate-sharing, static vs. dynamic aspects of  
> ipfix, and so on. And thsi discussion should happen whether the MIB  
> module is made writable or not.
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Friday, October 20, 2006 2:33 PM
> To: Thomas Dietz
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
>
> Dear all,
>
> If the question is: "would you like to have a writable MIB",  the  
> answer will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with  
> more features compared to a solution with less features.
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet:  
> can it be saved? http://www.simple-times.org/pub/simple-times/ 
> issues/9-1.html#introduction),  let me ask the question  
> differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should  
> be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process  
> (such as where to export, which transport protocol, which port,  
> backup or not, template retransmission timeout, etc...) is somehow  
> pretty static in networks, this type of configuration via SNMP  
> might be useful.
> However, I'm not sure about the configuration of everything that  
> relates to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible  
> the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/ 
> products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following  
> indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be  
> quite a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to  
> express whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an  
> extra table for options template is required. In this table, as we  
> can have multiple scope information elements, we need a way to  
> express whether an I.E. is a scope or not (similar to flow key in  
> ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if  
> the collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation  
> domain and per transport session.
>   So now, if the SCTP association goes down, what should the  
> collector do?
>     1. erase all the templates on the exporter, and reconfigure  
> them? This implies that if only the connection is down, not the  
> metering process, then this action basically stopped the metering  
> process
>     2. wait for the template retransmission? What if the metering  
> process went down and the template id allocation changed. Shall the  
> collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it  
> must be set and what each setting means."
>
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this  
> MIB, I'm questioning this practicality/complexity... and as a  
> consequence its chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process  
> information
> Finally I agree that a way to configure the templates is needed,  
> I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit  
> the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the  
> vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.
>> Dear Benoit, Kobayashi and others,
>>
>> I want to summarize 2 points that arose in the current discussion  
>> of the
>> IPFIX MIB and poll the list for comments how we should proceed  
>> with it.
>>
>> It is a fundamental decision if we should allow the IPFIX devices  
>> to be
>> configured via SNMP. For the collector there is not much to  
>> configure but
>> for the exporter there are many things that could be set-up,  
>> changed and
>> deleted.
>>
>> Making the MIB writeable would have the consequence that we need to
>> carefully review the status for each variable and table. We must  
>> define the
>> row status and how it must be set and what each setting means.  
>> Furthermore
>> we need to carefully elaborate the conformance section and need to  
>> discuss
>> every writeable object in the security considerations. So it is a  
>> really big
>> effort to make the MIB writeable so that it is secure to use it.
>>
>> Nevertheless, if the majority on the list has the opinion that it  
>> is really
>> useful to have the MIB (especially the EXPORTER MIB) writeable  
>> than we would
>> take that effort.
>>
>> Please keep in mind that the decision we take here would also  
>> affect the
>> PSAMP MIB accordingly.
>>
>> Awaiting your comments,
>>
>> Thomas
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>
>





--Apple-Mail-1-512980457
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

Gentle people,
=A0 =A0I =
brought up this question much earlier.=A0 If the IPFIX WG =
is=A0genuinely=A0specifying a
transport protocol, then the =
nature of the MIB should resemble those of other =
transport
protocols.=A0 =A0SCTP (RFC 3873) and TCP (RFC 4022) =
are good examples, there is only
one object in either MIB that =
is=A0"read-write", and that allows a management station =
to
'delete' or 'close' an SCTP or TCP connection.=A0 =A0All =
other MIB objects are read-only.

Which is what you would =
expect for a=A0transport protocol MIB.

Carter


On Oct 20, =
2006, at 10:10 AM, David Harrington wrote:

 
Hi,
 
=A0
 
The question that was =
originally proposed was "should the IPFIX MIB be =
writable?"
 
I believe there would be benefit to making IPFIX =
manageable.
 
Since you have defined a MIB module to perform management, it =
seems a simple extension to make some of the objects writable, rather =
than requring a whole extra protocol be supported to configure ipfix =
parameters. 
 
=A0
 
Has anybody argued that =
every aspect of IPFIX should be configurable using the MIB module? I =
haven't seen anybody make such an argument, and I am not making such an =
argument. Deciding that none of the objects CAN be =
used by an application to modify the configuration of IPFIX may make it =
difficiult to configure ipfix functionality. =

 
=A0
 
Some of the questions below deal with anomalies, such as SCTP =
going down. The question is not about SNMP, it is about interoperable =
IPFIX behavior and should be addressed regardless of the management =
protocol being used to do configuration.
 
If a collector uses =
Netconf=A0to configure the templates, and SCTP goes down, what should =
the collector do? delete the templates and reconfigure them from =
scratch? wait for the template retransmission? something else? What if =
CLI is used? The fact that some of the config is done using SNMP should =
not be the telling factor; the appropriate behavior should be specified =
regardless of config protocol.
 
=A0
 
 
Even if template management were to be =
addressed, there=A0are ways=A0to reduce the complexity of =
configuration.
 
=A0
 
The question that should be asked is "which =
aspects of ipfix should be made manageable, and how?". Such a discussion =
should consider issues of persistence, fate-sharing, static vs. dynamic =
aspects of ipfix, and so on. And thsi discussion should happen whether =
the MIB module is made writable or not.
 
=A0
 
David Harrington
dharrington@huawei.com
dbhar=
rington@comcast.net
ietfdbh@comcast.net

 
  
 =
 
  From: =
Benoit Claise [mailto:bclaise@cisco.com]   =

Sent: Friday, October 20, 2006 2:33 PM
To: Thomas   =
Dietz
Cc: ipfix@ietf.org
Subject: Re: =
[IPFIX] Should the   IPFIX MIB be writeable?

  =

Dear all,

If the question is: "would you like to have =
a   writable MIB",=A0 the answer will probably be: "sure, it's   =
useful/nice-to-have!"
It's a logical answer when you offer the choice =
of a   solution with more features compared to a solution with less   =
features.

While I don't want to restart a discussion on SNMPset   =
("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#intr=
oduction),=A0   let me ask the question differently: will this =
read-write MIB be practical and   useful? 

Let me concentrate on =
the Exporter MIB, as the Collector MIB   should be read-only (what can =
we configure on the collector side?)
Even if   the information =
related to the IPFIX exporting process (such as where to   export, which =
transport protocol, which port, backup or not, template   retransmission =
timeout, etc...) is somehow pretty static in networks, this   type of =
configuration via SNMP might be useful.
However, I'm not sure about   =
the configuration of everything that relates to metering process as it's =
  getting pretty complex.
For example, is it practical to specify via =
SNMP   all the possible the template definition from Flexible   =
NetFlow?
=A0=A0=A0=A0 Flexible NetFlow =3D http://www.cisco.com/en/US/products/ps6601/products_qa=
nda_item0900aecd804be091.shtml
This   would require the =
ipfixTemplateTable to have the following indexes:   
=A0=A0=A0 the =
transport session source IP   address
=A0=A0=A0 the transport session =
destination IP   address
=A0=A0=A0 the transport session source   =
port
=A0=A0=A0 the transport session destination   port
=A0=A0=A0 =
the observation domain Id
=A0=A0=A0 the   template Id
=A0=A0=A0 =
the information element position
A table   with 7 indexes. Sure, it's =
possible but this starts to be quite a complex   MIB
Some more =
remarks that will add to the complexity:
- In   ipfixTemplateTable, =
we still need to find a way via SNMP to express whether a   specific =
I.E. is a flow key or not
- We have the choice of template versus   =
options template. So an extra table for options template is required. In =
this   table, as we can have multiple scope information elements, we =
need a way to   express whether an I.E. is a scope or not (similar to =
flow key in   ipfixTemplateTable)
- This implies that Template Ids =
are assigned by the   collector if the collector creates new =
templates.
- The collector   configures the template Ids. 
=A0 =
Note: remember that the template Id   are unique per observation domain =
and per transport session. 
=A0 So   now, if the SCTP association =
goes down, what should the collector   do?
=A0=A0=A0 1. erase all the =
templates on the exporter, and   reconfigure them? This implies that if =
only the connection is down, not the   metering process, then this =
action basically stopped the metering   process
=A0=A0=A0 2. wait for =
the template retransmission? What if   the metering process went down =
and the template id allocation changed. Shall   the collector update his =
MIB?
=A0=A0=A0 3. something else?
- As   Thomas mentioned: "We =
must define the row status and how it must be set and   what each =
setting means."

To summarize, my views are:
Even if this   =
might be an interesting little challenge to write this MIB, I'm =
questioning   this practicality/complexity... and as a consequence its =
chances to be   implemented if everything is read-write 
However, I =
agree with the   configuration of the exporting process =
information
Finally I agree that a   way to configure the templates =
is needed, I'm wondering whether SNMP is the   right way to do. Maybe =
NETCONF?

Potential solution:
Could we have   specify the full =
exporter MIB as writable, but limit the metering part to   read-only in =
the "Units of   =
Conformance"?
That way, the end customers will decide by pushing or =
not the   vendor: SNMP versus NETCONF versus =
CLI

Regards,   Benoit.
  
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure =
but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define =
the
row status and how it must be set and what each setting means. =
Furthermore
we need to carefully elaborate the conformance section and need to =
discuss
every writeable object in the security considerations. So it is a really =
big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is =
really
useful to have the MIB (especially the EXPORTER MIB) writeable than we =
would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/ipfix
  




 =


=

--Apple-Mail-1-512980457--


--===============0546861161==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0546861161==--




From ipfix-bounces@ietf.org Fri Oct 20 12:01:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GawnG-00077b-ET; Fri, 20 Oct 2006 12:00:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GawnF-00076v-69
	for ipfix@ietf.org; Fri, 20 Oct 2006 12:00:21 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawnC-00081g-QE
	for ipfix@ietf.org; Fri, 20 Oct 2006 12:00:21 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9KG09xn005233 for ; Fri, 20 Oct 2006 12:00:10 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9KFwJHC005052
	for ; Fri, 20 Oct 2006 11:58:19 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9KFwIHX005049;
	Fri, 20 Oct 2006 11:58:19 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-26.remote.cert.org [10.25.4.26])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9KFwIHU028698; Fri, 20 Oct 2006 11:58:18 -0400
In-Reply-To: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
References: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <39900288-9972-49FE-B26B-2E51A1B7F399@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
Date: Fri, 20 Oct 2006 11:57:43 -0400
To: Ma Yuzhi 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Yuzhi,

Ah, yes... after reviewing RFC 3436 section 5, especially on TLS  
session resumption, the language here confuses TLS Sessions and  
Connections; it should read:

    Though TLS bindings to SCTP are defined in [RFC3436], they
    require all communication to be over reliable, bi-directional  
streams,
    and require one TLS Connection per stream.  This arrangement is not
    compatible with the rationale behind the choice of SCTP as an IPFIX
    transport protocol.

Thanks,

Brian

On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:

> Hi,
>
> Section 11.1 Applicability of TLS and DTLS
>    Though TLS bindings to SCTP are defined in [RFC3436], they
>    require all communication to be over reliable streams, and require
>    one session per stream.  This arrangement is not compatible with  
> the
>    rationale behind the choice of SCTP as an IPFIX transport protocol.
>
> RFC3436 Section 5 Connections and Bi-directional Streams
>   TLS makes use of a bi-directional stream by establishing a  
> connection
>    over it.  This means that the number of connections for an
>    association is limited by the number of bi-directional streams.
>
>
> Does "one session per stream" mean  "one TLS session per SCTP stream"?
> If so, I think the description are unsuitable.
>
> Yuzhi
>
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Saturday, October 14, 2006 3:50 AM
>> To: i-d-announce@ietf.org
>> Cc: ipfix@ietf.org
>> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>>
>> 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 Protocol
>> for the Exchange of IP Traffic Flow Information
>> 	Author(s)	: B. Claise
>> 	Filename	: draft-ietf-ipfix-protocol-23.txt
>> 	Pages		: 63
>> 	Date		: 2006-10-13
>> 	
>> This document specifies the IPFIX protocol that serves for
>>    transmitting IP traffic flow information over the network.
>>  In order
>>    to transmit IP traffic flow information from an exporting
>> process to
>>    an information collecting process, a common representation of flow
>>    data and a standard means of communicating them is required. This
>>    document describes how the IPFIX data and templates records are
>>    carried over a number of transport protocols from an IPFIX
>> exporting
>>    process to an IPFIX collecting process.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to i-d-announce-request@ietf.org with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>> "get draft-ietf-ipfix-protocol-23.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	mailserv@ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

Brian H. Trammell                            +1 412 268  
9748
Technical Lead, Engineering       CERT Network Situational Awareness  
Group
Software Engineering Institute, Carnegie Mellon University,  
Pittsburgh, PA




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



From ipfix-bounces@ietf.org Fri Oct 20 12:01:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GawnG-00077b-ET; Fri, 20 Oct 2006 12:00:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GawnF-00076v-69
	for ipfix@ietf.org; Fri, 20 Oct 2006 12:00:21 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawnC-00081g-QE
	for ipfix@ietf.org; Fri, 20 Oct 2006 12:00:21 -0400
Received: from beniaminus.red.cert.org (localhost [127.0.0.1])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9KG09xn005233 for ; Fri, 20 Oct 2006 12:00:10 -0400
Received: (from defang@localhost)
	by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k9KFwJHC005052
	for ; Fri, 20 Oct 2006 11:58:19 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (envelope-sender )
	(MIMEDefang) with ESMTP id k9KFwIHX005049;
	Fri, 20 Oct 2006 11:58:19 -0400 (EDT)
Received: from [128.237.229.127] (vpn-10-25-4-26.remote.cert.org [10.25.4.26])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9KFwIHU028698; Fri, 20 Oct 2006 11:58:18 -0400
In-Reply-To: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
References: <01c001c6f415$5e365f30$410c6f0a@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <39900288-9972-49FE-B26B-2E51A1B7F399@cert.org>
Content-Transfer-Encoding: 7bit
From: Brian Trammell 
Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
Date: Fri, 20 Oct 2006 11:57:43 -0400
To: Ma Yuzhi 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Yuzhi,

Ah, yes... after reviewing RFC 3436 section 5, especially on TLS  
session resumption, the language here confuses TLS Sessions and  
Connections; it should read:

    Though TLS bindings to SCTP are defined in [RFC3436], they
    require all communication to be over reliable, bi-directional  
streams,
    and require one TLS Connection per stream.  This arrangement is not
    compatible with the rationale behind the choice of SCTP as an IPFIX
    transport protocol.

Thanks,

Brian

On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:

> Hi,
>
> Section 11.1 Applicability of TLS and DTLS
>    Though TLS bindings to SCTP are defined in [RFC3436], they
>    require all communication to be over reliable streams, and require
>    one session per stream.  This arrangement is not compatible with  
> the
>    rationale behind the choice of SCTP as an IPFIX transport protocol.
>
> RFC3436 Section 5 Connections and Bi-directional Streams
>   TLS makes use of a bi-directional stream by establishing a  
> connection
>    over it.  This means that the number of connections for an
>    association is limited by the number of bi-directional streams.
>
>
> Does "one session per stream" mean  "one TLS session per SCTP stream"?
> If so, I think the description are unsuitable.
>
> Yuzhi
>
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Saturday, October 14, 2006 3:50 AM
>> To: i-d-announce@ietf.org
>> Cc: ipfix@ietf.org
>> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>>
>> 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 Protocol
>> for the Exchange of IP Traffic Flow Information
>> 	Author(s)	: B. Claise
>> 	Filename	: draft-ietf-ipfix-protocol-23.txt
>> 	Pages		: 63
>> 	Date		: 2006-10-13
>> 	
>> This document specifies the IPFIX protocol that serves for
>>    transmitting IP traffic flow information over the network.
>>  In order
>>    to transmit IP traffic flow information from an exporting
>> process to
>>    an information collecting process, a common representation of flow
>>    data and a standard means of communicating them is required. This
>>    document describes how the IPFIX data and templates records are
>>    carried over a number of transport protocols from an IPFIX
>> exporting
>>    process to an IPFIX collecting process.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to i-d-announce-request@ietf.org with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>> "get draft-ietf-ipfix-protocol-23.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	mailserv@ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix

Brian H. Trammell                            +1 412 268  
9748
Technical Lead, Engineering       CERT Network Situational Awareness  
Group
Software Engineering Institute, Carnegie Mellon University,  
Pittsburgh, PA




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



From ipfix-bounces@ietf.org Fri Oct 20 21:54:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gb61U-0000p4-Ff; Fri, 20 Oct 2006 21:51:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb61U-0000oC-1k
	for ipfix@ietf.org; Fri, 20 Oct 2006 21:51:40 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb61L-0006Ug-56
	for ipfix@ietf.org; Fri, 20 Oct 2006 21:51:40 -0400
Received: from [58.98.36.125] (unknown [58.98.36.125])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 76B841BAC4D;
	Sat, 21 Oct 2006 03:51:28 +0200 (CEST)
Date: Sat, 21 Oct 2006 02:05:01 +0200
From: Juergen Quittek 
To: David Harrington ,
	'Benoit Claise' ,
	'Thomas Dietz' 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Message-ID: <1806BC2CD46A7E603A72D031@753F3B888A9969457862729D>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Please let's not spend too much time on discussing whether or
not SMIv2 is a good language for defining device configuration
interfaces.

As contributors have said before, there is no strict reason for
constraining the MIB modules to be read-only. (However, we will
give implementers the option to build them read-only.)

So let's focus on the open issue.  The next version will be
posted on Monday and it probably will not yet be affected by
this discussion.  It will still be an individual draft.

Based on this draft, I would like the authors to post a concrete
suggestion on this list stating which parts of the two MIB modules
should be writeable.

Please post your suggestion in the week before the IETF meeting.
Then we can start the discussion on the list and try to get close
to a consensus during our session in San Diego.  After the San
Diego meeting the results of our discussion should be reflected
by an update of the MIB modules to be posted as WG draft.

Thanks,

    Juergen


--On 20.10.2006 16:10 Uhr +0200 David Harrington wrote:

>
> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB be writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems a simple extension to make some of the objects writable, rather than requring a whole extra protocol be supported to configure ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be configurable using the MIB module? I haven't seen anybody make such an argument, and I am not making such an argument. Deciding that none of the objects CAN be used by an application to modify the
> configuration of IPFIX may make it difficiult to configure ipfix functionality.
>
> Some of the questions below deal with anomalies, such as SCTP going down. The question is not about SNMP, it is about interoperable IPFIX behavior and should be addressed regardless of the management protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP goes down, what should the collector do? delete the templates and reconfigure them from scratch? wait for the template retransmission? something else? What if CLI is used? The fact that
> some of the config is done using SNMP should not be the telling factor; the appropriate behavior should be specified regardless of config protocol.
>
>
> Even if template management were to be addressed, there are ways to reduce the complexity of configuration.
>
> The question that should be asked is "which aspects of ipfix should be made manageable, and how?". Such a discussion should consider issues of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and so on. And thsi discussion should happen
> whether the MIB module is made writable or not.
>
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>
>
> __________________________________________________
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Friday, October 20, 2006 2:33 PM
> To: Thomas Dietz
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
>
>
> Dear all,
>
> If the question is: "would you like to have a writable MIB",  the answer will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with more features compared to a solution with less features.
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  let me ask the question differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process (such as where to export, which transport protocol, which port, backup or not, template retransmission timeout, etc...) is somehow pretty static in networks, this type of configuration via
> SNMP might be useful.
> However, I'm not sure about the configuration of everything that relates to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be quite a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to express whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an extra table for options template is required. In this table, as we can have multiple scope information elements, we need a way to express whether an I.E. is a scope or not (similar to flow
> key in ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if the collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation domain and per transport session.
>   So now, if the SCTP association goes down, what should the collector do?
>     1. erase all the templates on the exporter, and reconfigure them? This implies that if only the connection is down, not the metering process, then this action basically stopped the metering process
>     2. wait for the template retransmission? What if the metering process went down and the template id allocation changed. Shall the collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it must be set and what each setting means."
>
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this MIB, I'm questioning this practicality/complexity... and as a consequence its chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process information
> Finally I agree that a way to configure the templates is needed, I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.
>
>
>
> Dear Benoit, Kobayashi and others,
>
> I want to summarize 2 points that arose in the current discussion of the
> IPFIX MIB and poll the list for comments how we should proceed with it.
>
> It is a fundamental decision if we should allow the IPFIX devices to be
> configured via SNMP. For the collector there is not much to configure but
> for the exporter there are many things that could be set-up, changed and
> deleted.
>
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We must define the
> row status and how it must be set and what each setting means. Furthermore
> we need to carefully elaborate the conformance section and need to discuss
> every writeable object in the security considerations. So it is a really big
> effort to make the MIB writeable so that it is secure to use it.
>
> Nevertheless, if the majority on the list has the opinion that it is really
> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
> take that effort.
>
> Please keep in mind that the decision we take here would also affect the
> PSAMP MIB accordingly.
>
> Awaiting your comments,
>
> Thomas
>
>
>
>
> __________________________________________________
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>
>
>
>

 

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



From ipfix-bounces@ietf.org Fri Oct 20 21:54:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gb61U-0000p4-Ff; Fri, 20 Oct 2006 21:51:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb61U-0000oC-1k
	for ipfix@ietf.org; Fri, 20 Oct 2006 21:51:40 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb61L-0006Ug-56
	for ipfix@ietf.org; Fri, 20 Oct 2006 21:51:40 -0400
Received: from [58.98.36.125] (unknown [58.98.36.125])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 76B841BAC4D;
	Sat, 21 Oct 2006 03:51:28 +0200 (CEST)
Date: Sat, 21 Oct 2006 02:05:01 +0200
From: Juergen Quittek 
To: David Harrington ,
	'Benoit Claise' ,
	'Thomas Dietz' 
Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
Message-ID: <1806BC2CD46A7E603A72D031@753F3B888A9969457862729D>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Please let's not spend too much time on discussing whether or
not SMIv2 is a good language for defining device configuration
interfaces.

As contributors have said before, there is no strict reason for
constraining the MIB modules to be read-only. (However, we will
give implementers the option to build them read-only.)

So let's focus on the open issue.  The next version will be
posted on Monday and it probably will not yet be affected by
this discussion.  It will still be an individual draft.

Based on this draft, I would like the authors to post a concrete
suggestion on this list stating which parts of the two MIB modules
should be writeable.

Please post your suggestion in the week before the IETF meeting.
Then we can start the discussion on the list and try to get close
to a consensus during our session in San Diego.  After the San
Diego meeting the results of our discussion should be reflected
by an update of the MIB modules to be posted as WG draft.

Thanks,

    Juergen


--On 20.10.2006 16:10 Uhr +0200 David Harrington wrote:

>
> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB be writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems a simple extension to make some of the objects writable, rather than requring a whole extra protocol be supported to configure ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be configurable using the MIB module? I haven't seen anybody make such an argument, and I am not making such an argument. Deciding that none of the objects CAN be used by an application to modify the
> configuration of IPFIX may make it difficiult to configure ipfix functionality.
>
> Some of the questions below deal with anomalies, such as SCTP going down. The question is not about SNMP, it is about interoperable IPFIX behavior and should be addressed regardless of the management protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP goes down, what should the collector do? delete the templates and reconfigure them from scratch? wait for the template retransmission? something else? What if CLI is used? The fact that
> some of the config is done using SNMP should not be the telling factor; the appropriate behavior should be specified regardless of config protocol.
>
>
> Even if template management were to be addressed, there are ways to reduce the complexity of configuration.
>
> The question that should be asked is "which aspects of ipfix should be made manageable, and how?". Such a discussion should consider issues of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and so on. And thsi discussion should happen
> whether the MIB module is made writable or not.
>
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>
>
> __________________________________________________
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Friday, October 20, 2006 2:33 PM
> To: Thomas Dietz
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
>
>
> Dear all,
>
> If the question is: "would you like to have a writable MIB",  the answer will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with more features compared to a solution with less features.
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  let me ask the question differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process (such as where to export, which transport protocol, which port, backup or not, template retransmission timeout, etc...) is somehow pretty static in networks, this type of configuration via
> SNMP might be useful.
> However, I'm not sure about the configuration of everything that relates to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following indexes:
>     the transport session source IP address
>     the transport session destination IP address
>     the transport session source port
>     the transport session destination port
>     the observation domain Id
>     the template Id
>     the information element position
> A table with 7 indexes. Sure, it's possible but this starts to be quite a complex MIB
> Some more remarks that will add to the complexity:
> - In ipfixTemplateTable, we still need to find a way via SNMP to express whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an extra table for options template is required. In this table, as we can have multiple scope information elements, we need a way to express whether an I.E. is a scope or not (similar to flow
> key in ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if the collector creates new templates.
> - The collector configures the template Ids.
>   Note: remember that the template Id are unique per observation domain and per transport session.
>   So now, if the SCTP association goes down, what should the collector do?
>     1. erase all the templates on the exporter, and reconfigure them? This implies that if only the connection is down, not the metering process, then this action basically stopped the metering process
>     2. wait for the template retransmission? What if the metering process went down and the template id allocation changed. Shall the collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it must be set and what each setting means."
>
> To summarize, my views are:
> Even if this might be an interesting little challenge to write this MIB, I'm questioning this practicality/complexity... and as a consequence its chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process information
> Finally I agree that a way to configure the templates is needed, I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.
>
>
>
> Dear Benoit, Kobayashi and others,
>
> I want to summarize 2 points that arose in the current discussion of the
> IPFIX MIB and poll the list for comments how we should proceed with it.
>
> It is a fundamental decision if we should allow the IPFIX devices to be
> configured via SNMP. For the collector there is not much to configure but
> for the exporter there are many things that could be set-up, changed and
> deleted.
>
> Making the MIB writeable would have the consequence that we need to
> carefully review the status for each variable and table. We must define the
> row status and how it must be set and what each setting means. Furthermore
> we need to carefully elaborate the conformance section and need to discuss
> every writeable object in the security considerations. So it is a really big
> effort to make the MIB writeable so that it is secure to use it.
>
> Nevertheless, if the majority on the list has the opinion that it is really
> useful to have the MIB (especially the EXPORTER MIB) writeable than we would
> take that effort.
>
> Please keep in mind that the decision we take here would also affect the
> PSAMP MIB accordingly.
>
> Awaiting your comments,
>
> Thomas
>
>
>
>
> __________________________________________________
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>
>
>
>

 

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



From ipfix-bounces@ietf.org Sun Oct 22 03:26:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbXh0-0001gy-3M; Sun, 22 Oct 2006 03:24:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbXgy-0001gq-Uf
	for ipfix@ietf.org; Sun, 22 Oct 2006 03:24:20 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbXgq-0004Tm-Cw
	for ipfix@ietf.org; Sun, 22 Oct 2006 03:24:20 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id B6F561BAC99;
	Sun, 22 Oct 2006 09:24:11 +0200 (CEST)
Date: Sat, 21 Oct 2006 15:21:05 +0200
From: Juergen Quittek 
To: Hitoshi Irino , ipfix@ietf.org
Subject: Re: [IPFIX] Question about data types of some IEs
Message-ID: 
In-Reply-To: <4532D411.9090006@lab.ntt.co.jp>
References: <4532D411.9090006@lab.ntt.co.jp>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Irino-san,

Thanks for carefully checking the data types used in the
info model.  Please find replies to your comments inline.
For three IEs I followed your suggestion and replaced the
data type for the next version of the draft.

--On 16.10.2006 9:36 Uhr +0900 Hitoshi Irino wrote:

> Dear all,
>
> I have a question and suggestion about data types of some IEs.
>
> 1.
>   5.5.12.  tcpHeaderLength
>   Abstract Data Type: unsigned16
>
> TCP headers has 4 bit "Data Offset" field which has the number of 32 bit
> words in the TCP header. Therefore, I think TCP header max size is 2^4*4
> = 64 octets. Therefore I think that unsigned8 is sufficient for this IE.

I agree.  Would anyone have problems with changing the type to unsigned 8?

> Is there any reason that is unsigned16?
>
> 2.
>   5.6.9.  mplsTopLabelTTL
>   Abstract Data Type: unsigned32
>
> According to 2.1. Encoding the Label Stack in RFC3032
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
>|                Label                  | Exp |S|       TTL     | Stack
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
>
>                      Label:  Label Value, 20 bits
>                      Exp:    Experimental Use, 3 bits
>                      S:      Bottom of Stack, 1 bit
>                      TTL:    Time to Live, 8 bits
>
> I think that unsigned8 is sufficient for this IE.

Also agreed. Any objections?

> Is there any reason that is unsigned32?
>
> 3.
>   5.4.30.  ipPayloadLength
>   Abstract Data Type: unsigned64
>
> totalLengthIPv4 is 16bit, payloadLengthIPv6 is 32bit for jumbo payload
> (rfc2675). I think unsigned32 is sufficient for ipPayloadLength.
> Why Does Abstract Data Type of this IE have unsigned64?

Also agreed.  Would anyone complain if we changed it to unsigned32?

> 4.
>    5.7.12.  mplsVpnRouteDistinguisher
>    Abstract Data Type: octetArray
>
> According to section 4.2 in rfc4364,
> a VPN-IPv4 address consists of an 8-byte Route Distinguisher
> followed by a 4-byte IPv4 address.
>
> Is unsigned64 sufficient for this IE?
>
> According to page 7 of rfc4382,
> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
> SYNTAX  OCTET STRING(SIZE (0..256))
>
> I think that Abstract Data Type of this IE should be "string",
> if this IE is in conformity to rfc4382.

RFC 4364 defines the size of a route distinguisher as 64 bits
(8 octets) which exactly matches the current data type in the
info model.

However, you are right that the MIB module in RFC 4382 chooses
the SMI type for a route distinguisher to be an octet string
with up to 256 octets.  I do not understand why the in the MIB
module in RFC 4382 does not use a shorter array.

I sent this question to the editors of RFC 4382.
Let's hope they can help us.  Or can somebody on the list
answer this question?

> 5.
> Can Exporter implementation be chosen which use fixed or variable
> length for IEs that have octetArray or string data type?
> Is it correct?  Should Information model draft define which use
> fixed or variable for these IEs?

I think exporters should be free to choose between fixed or
variable length encoding of a particular IE.  I do not see a
good reason to restrict the use.  But I am open to discuss it
if you bring up a good reason.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

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



From ipfix-bounces@ietf.org Sun Oct 22 03:26:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbXh0-0001gy-3M; Sun, 22 Oct 2006 03:24:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbXgy-0001gq-Uf
	for ipfix@ietf.org; Sun, 22 Oct 2006 03:24:20 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbXgq-0004Tm-Cw
	for ipfix@ietf.org; Sun, 22 Oct 2006 03:24:20 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id B6F561BAC99;
	Sun, 22 Oct 2006 09:24:11 +0200 (CEST)
Date: Sat, 21 Oct 2006 15:21:05 +0200
From: Juergen Quittek 
To: Hitoshi Irino , ipfix@ietf.org
Subject: Re: [IPFIX] Question about data types of some IEs
Message-ID: 
In-Reply-To: <4532D411.9090006@lab.ntt.co.jp>
References: <4532D411.9090006@lab.ntt.co.jp>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Irino-san,

Thanks for carefully checking the data types used in the
info model.  Please find replies to your comments inline.
For three IEs I followed your suggestion and replaced the
data type for the next version of the draft.

--On 16.10.2006 9:36 Uhr +0900 Hitoshi Irino wrote:

> Dear all,
>
> I have a question and suggestion about data types of some IEs.
>
> 1.
>   5.5.12.  tcpHeaderLength
>   Abstract Data Type: unsigned16
>
> TCP headers has 4 bit "Data Offset" field which has the number of 32 bit
> words in the TCP header. Therefore, I think TCP header max size is 2^4*4
> = 64 octets. Therefore I think that unsigned8 is sufficient for this IE.

I agree.  Would anyone have problems with changing the type to unsigned 8?

> Is there any reason that is unsigned16?
>
> 2.
>   5.6.9.  mplsTopLabelTTL
>   Abstract Data Type: unsigned32
>
> According to 2.1. Encoding the Label Stack in RFC3032
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
>|                Label                  | Exp |S|       TTL     | Stack
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
>
>                      Label:  Label Value, 20 bits
>                      Exp:    Experimental Use, 3 bits
>                      S:      Bottom of Stack, 1 bit
>                      TTL:    Time to Live, 8 bits
>
> I think that unsigned8 is sufficient for this IE.

Also agreed. Any objections?

> Is there any reason that is unsigned32?
>
> 3.
>   5.4.30.  ipPayloadLength
>   Abstract Data Type: unsigned64
>
> totalLengthIPv4 is 16bit, payloadLengthIPv6 is 32bit for jumbo payload
> (rfc2675). I think unsigned32 is sufficient for ipPayloadLength.
> Why Does Abstract Data Type of this IE have unsigned64?

Also agreed.  Would anyone complain if we changed it to unsigned32?

> 4.
>    5.7.12.  mplsVpnRouteDistinguisher
>    Abstract Data Type: octetArray
>
> According to section 4.2 in rfc4364,
> a VPN-IPv4 address consists of an 8-byte Route Distinguisher
> followed by a 4-byte IPv4 address.
>
> Is unsigned64 sufficient for this IE?
>
> According to page 7 of rfc4382,
> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
> SYNTAX  OCTET STRING(SIZE (0..256))
>
> I think that Abstract Data Type of this IE should be "string",
> if this IE is in conformity to rfc4382.

RFC 4364 defines the size of a route distinguisher as 64 bits
(8 octets) which exactly matches the current data type in the
info model.

However, you are right that the MIB module in RFC 4382 chooses
the SMI type for a route distinguisher to be an octet string
with up to 256 octets.  I do not understand why the in the MIB
module in RFC 4382 does not use a shorter array.

I sent this question to the editors of RFC 4382.
Let's hope they can help us.  Or can somebody on the list
answer this question?

> 5.
> Can Exporter implementation be chosen which use fixed or variable
> length for IEs that have octetArray or string data type?
> Is it correct?  Should Information model draft define which use
> fixed or variable for these IEs?

I think exporters should be free to choose between fixed or
variable length encoding of a particular IE.  I do not see a
good reason to restrict the use.  But I am open to discuss it
if you bring up a good reason.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

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



From ipfix-bounces@ietf.org Sun Oct 22 15:01:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbiYR-0008NE-0u; Sun, 22 Oct 2006 15:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbiYQ-0008Mr-Bk
	for ipfix@ietf.org; Sun, 22 Oct 2006 15:00:14 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbiQO-0002pp-FW
	for ipfix@ietf.org; Sun, 22 Oct 2006 14:51:57 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9MIgSFs027804
	for ; Sun, 22 Oct 2006 14:42:30 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Sun, 22 Oct 2006 20:51:52 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
Thread-Index: Acb0YQ/xQk6WVcbETKCYd6zGhU7rYQBbmvJQ
From: "Romascanu, Dan \(Dan\)" 
To: "Brian Trammell" , "Ma Yuzhi" 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Please note that the document is on the agenda of the 10/26 IESG meting.


If you believe that the document should not be approved in its current
form you need to let the IESG know.=20

Dan


=20
=20

> -----Original Message-----
> From: Brian Trammell [mailto:bht@cert.org]=20
> Sent: Friday, October 20, 2006 5:58 PM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>=20
> Yuzhi,
>=20
> Ah, yes... after reviewing RFC 3436 section 5, especially on=20
> TLS session resumption, the language here confuses TLS=20
> Sessions and Connections; it should read:
>=20
>     Though TLS bindings to SCTP are defined in [RFC3436], they
>     require all communication to be over reliable,=20
> bi-directional streams,
>     and require one TLS Connection per stream.  This=20
> arrangement is not
>     compatible with the rationale behind the choice of SCTP=20
> as an IPFIX
>     transport protocol.
>=20
> Thanks,
>=20
> Brian
>=20
> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
>=20
> > Hi,
> >
> > Section 11.1 Applicability of TLS and DTLS
> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >    require all communication to be over reliable streams,=20
> and require
> >    one session per stream.  This arrangement is not compatible with=20
> > the
> >    rationale behind the choice of SCTP as an IPFIX=20
> transport protocol.
> >
> > RFC3436 Section 5 Connections and Bi-directional Streams
> >   TLS makes use of a bi-directional stream by establishing a=20
> > connection
> >    over it.  This means that the number of connections for an
> >    association is limited by the number of bi-directional streams.
> >
> >
> > Does "one session per stream" mean  "one TLS session per=20
> SCTP stream"?
> > If so, I think the description are unsuitable.
> >
> > Yuzhi
> >
> >> -----Original Message-----
> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> To: i-d-announce@ietf.org
> >> Cc: ipfix@ietf.org
> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts=20
> >> directories.
> >> This draft is a work item of the IP Flow Information=20
> Export Working=20
> >> Group of the IETF.
> >>
> >> 	Title		: Specification of the IPFIX Protocol
> >> for the Exchange of IP Traffic Flow Information
> >> 	Author(s)	: B. Claise
> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> 	Pages		: 63
> >> 	Date		: 2006-10-13
> >> =09
> >> This document specifies the IPFIX protocol that serves for
> >>    transmitting IP traffic flow information over the network.
> >>  In order
> >>    to transmit IP traffic flow information from an=20
> exporting process=20
> >> to
> >>    an information collecting process, a common=20
> representation of flow
> >>    data and a standard means of communicating them is=20
> required. This
> >>    document describes how the IPFIX data and templates records are
> >>    carried over a number of transport protocols from an IPFIX=20
> >> exporting
> >>    process to an IPFIX collecting process.
> >>
> >> A URL for this Internet-Draft is:
> >>=20
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a=20
> message to=20
> >> i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body=20
> >> of the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login=20
> with the=20
> >> username "anonymous" and a password of your e-mail address. After=20
> >> logging in, type "cd internet-drafts" and then "get=20
> >> draft-ietf-ipfix-protocol-23.txt".
> >>
> >> A list of Internet-Drafts directories can be found in=20
> >> http://www.ietf.org/shadow.html or=20
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	mailserv@ietf.org.
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> =09
> >> NOTE:	The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader=20
> >> implementation to automatically retrieve the ASCII version of the=20
> >> Internet-Draft.
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
>=20
> Brian H. Trammell                            +1=20
> 412 268 =20
> 9748
> Technical Lead, Engineering       CERT Network Situational Awareness =20
> Group
> Software Engineering Institute, Carnegie Mellon University,=20
> Pittsburgh, PA
>=20
>=20
>=20
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>=20

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



From ipfix-bounces@ietf.org Sun Oct 22 15:01:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbiYR-0008NE-0u; Sun, 22 Oct 2006 15:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbiYQ-0008Mr-Bk
	for ipfix@ietf.org; Sun, 22 Oct 2006 15:00:14 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbiQO-0002pp-FW
	for ipfix@ietf.org; Sun, 22 Oct 2006 14:51:57 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k9MIgSFs027804
	for ; Sun, 22 Oct 2006 14:42:30 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Sun, 22 Oct 2006 20:51:52 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
Thread-Index: Acb0YQ/xQk6WVcbETKCYd6zGhU7rYQBbmvJQ
From: "Romascanu, Dan \(Dan\)" 
To: "Brian Trammell" , "Ma Yuzhi" 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Please note that the document is on the agenda of the 10/26 IESG meting.


If you believe that the document should not be approved in its current
form you need to let the IESG know.=20

Dan


=20
=20

> -----Original Message-----
> From: Brian Trammell [mailto:bht@cert.org]=20
> Sent: Friday, October 20, 2006 5:58 PM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>=20
> Yuzhi,
>=20
> Ah, yes... after reviewing RFC 3436 section 5, especially on=20
> TLS session resumption, the language here confuses TLS=20
> Sessions and Connections; it should read:
>=20
>     Though TLS bindings to SCTP are defined in [RFC3436], they
>     require all communication to be over reliable,=20
> bi-directional streams,
>     and require one TLS Connection per stream.  This=20
> arrangement is not
>     compatible with the rationale behind the choice of SCTP=20
> as an IPFIX
>     transport protocol.
>=20
> Thanks,
>=20
> Brian
>=20
> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
>=20
> > Hi,
> >
> > Section 11.1 Applicability of TLS and DTLS
> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >    require all communication to be over reliable streams,=20
> and require
> >    one session per stream.  This arrangement is not compatible with=20
> > the
> >    rationale behind the choice of SCTP as an IPFIX=20
> transport protocol.
> >
> > RFC3436 Section 5 Connections and Bi-directional Streams
> >   TLS makes use of a bi-directional stream by establishing a=20
> > connection
> >    over it.  This means that the number of connections for an
> >    association is limited by the number of bi-directional streams.
> >
> >
> > Does "one session per stream" mean  "one TLS session per=20
> SCTP stream"?
> > If so, I think the description are unsuitable.
> >
> > Yuzhi
> >
> >> -----Original Message-----
> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> To: i-d-announce@ietf.org
> >> Cc: ipfix@ietf.org
> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts=20
> >> directories.
> >> This draft is a work item of the IP Flow Information=20
> Export Working=20
> >> Group of the IETF.
> >>
> >> 	Title		: Specification of the IPFIX Protocol
> >> for the Exchange of IP Traffic Flow Information
> >> 	Author(s)	: B. Claise
> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> 	Pages		: 63
> >> 	Date		: 2006-10-13
> >> =09
> >> This document specifies the IPFIX protocol that serves for
> >>    transmitting IP traffic flow information over the network.
> >>  In order
> >>    to transmit IP traffic flow information from an=20
> exporting process=20
> >> to
> >>    an information collecting process, a common=20
> representation of flow
> >>    data and a standard means of communicating them is=20
> required. This
> >>    document describes how the IPFIX data and templates records are
> >>    carried over a number of transport protocols from an IPFIX=20
> >> exporting
> >>    process to an IPFIX collecting process.
> >>
> >> A URL for this Internet-Draft is:
> >>=20
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a=20
> message to=20
> >> i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body=20
> >> of the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login=20
> with the=20
> >> username "anonymous" and a password of your e-mail address. After=20
> >> logging in, type "cd internet-drafts" and then "get=20
> >> draft-ietf-ipfix-protocol-23.txt".
> >>
> >> A list of Internet-Drafts directories can be found in=20
> >> http://www.ietf.org/shadow.html or=20
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	mailserv@ietf.org.
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> =09
> >> NOTE:	The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader=20
> >> implementation to automatically retrieve the ASCII version of the=20
> >> Internet-Draft.
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
>=20
> Brian H. Trammell                            +1=20
> 412 268 =20
> 9748
> Technical Lead, Engineering       CERT Network Situational Awareness =20
> Group
> Software Engineering Institute, Carnegie Mellon University,=20
> Pittsburgh, PA
>=20
>=20
>=20
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>=20

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



From ipfix-bounces@ietf.org Mon Oct 23 03:59:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbuhO-0006u9-0R; Mon, 23 Oct 2006 03:58:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuhM-0006tj-Ib
	for ipfix@ietf.org; Mon, 23 Oct 2006 03:58:16 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbuhG-00022N-L6
	for ipfix@ietf.org; Mon, 23 Oct 2006 03:58:16 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7K00GGBXASND@szxga03-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:08:52 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7K00C7GXARTO@szxga03-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:08:51 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7K00MIMXDV2R@szxml04-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:10:46 +0800 (CST)
Date: Mon, 23 Oct 2006 15:57:09 +0800
From: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
In-reply-to: <39900288-9972-49FE-B26B-2E51A1B7F399@cert.org>
To: 'Brian Trammell' 
Message-id: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acb0YN2wi5SdlE6qTHiB20daqN9kLgCEfb6A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi, Brain

Due to the reasons below, can we conclude that TLS is improper for IPFIX
while the transport protocol is SCTP?
Maybe it need more WG discussion. 

Yuzhi


> -----Original Message-----
> From: Brian Trammell [mailto:bht@cert.org] 
> Sent: Friday, October 20, 2006 11:58 PM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> Yuzhi,
> 
> Ah, yes... after reviewing RFC 3436 section 5, especially on 
> TLS session resumption, the language here confuses TLS 
> Sessions and Connections; it should read:
> 
>     Though TLS bindings to SCTP are defined in [RFC3436], they
>     require all communication to be over reliable, 
> bi-directional streams,
>     and require one TLS Connection per stream.  This 
> arrangement is not
>     compatible with the rationale behind the choice of SCTP 
> as an IPFIX
>     transport protocol.
> 
> Thanks,
> 
> Brian
> 
> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
> 
> > Hi,
> >
> > Section 11.1 Applicability of TLS and DTLS
> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >    require all communication to be over reliable streams, 
> and require
> >    one session per stream.  This arrangement is not compatible with 
> > the
> >    rationale behind the choice of SCTP as an IPFIX 
> transport protocol.
> >
> > RFC3436 Section 5 Connections and Bi-directional Streams
> >   TLS makes use of a bi-directional stream by establishing a 
> > connection
> >    over it.  This means that the number of connections for an
> >    association is limited by the number of bi-directional streams.
> >
> >
> > Does "one session per stream" mean  "one TLS session per 
> SCTP stream"?
> > If so, I think the description are unsuitable.
> >
> > Yuzhi
> >
> >> -----Original Message-----
> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> To: i-d-announce@ietf.org
> >> Cc: ipfix@ietf.org
> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> 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 Protocol
> >> for the Exchange of IP Traffic Flow Information
> >> 	Author(s)	: B. Claise
> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> 	Pages		: 63
> >> 	Date		: 2006-10-13
> >> 	
> >> This document specifies the IPFIX protocol that serves for
> >>    transmitting IP traffic flow information over the network.
> >>  In order
> >>    to transmit IP traffic flow information from an 
> exporting process 
> >> to
> >>    an information collecting process, a common 
> representation of flow
> >>    data and a standard means of communicating them is 
> required. This
> >>    document describes how the IPFIX data and templates records are
> >>    carried over a number of transport protocols from an IPFIX 
> >> exporting
> >>    process to an IPFIX collecting process.
> >>
> >> A URL for this Internet-Draft is:
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a 
> message to 
> >> i-d-announce-request@ietf.org with the word unsubscribe in 
> the body 
> >> of the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login 
> with the 
> >> username "anonymous" and a password of your e-mail address. After 
> >> logging in, type "cd internet-drafts" and then "get 
> >> draft-ietf-ipfix-protocol-23.txt".
> >>
> >> A list of Internet-Drafts directories can be found in 
> >> http://www.ietf.org/shadow.html or 
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	mailserv@ietf.org.
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> 	
> >> NOTE:	The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader 
> >> implementation to automatically retrieve the ASCII version of the 
> >> Internet-Draft.
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
> 
> Brian H. Trammell                            +1 
> 412 268  
> 9748
> Technical Lead, Engineering       CERT Network Situational Awareness  
> Group
> Software Engineering Institute, Carnegie Mellon University, 
> Pittsburgh, PA
> 
> 
> 
> 



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



From ipfix-bounces@ietf.org Mon Oct 23 03:59:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GbuhO-0006u9-0R; Mon, 23 Oct 2006 03:58:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuhM-0006tj-Ib
	for ipfix@ietf.org; Mon, 23 Oct 2006 03:58:16 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbuhG-00022N-L6
	for ipfix@ietf.org; Mon, 23 Oct 2006 03:58:16 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7K00GGBXASND@szxga03-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:08:52 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7K00C7GXARTO@szxga03-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:08:51 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7K00MIMXDV2R@szxml04-in.huawei.com> for
	ipfix@ietf.org; Mon, 23 Oct 2006 16:10:46 +0800 (CST)
Date: Mon, 23 Oct 2006 15:57:09 +0800
From: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
In-reply-to: <39900288-9972-49FE-B26B-2E51A1B7F399@cert.org>
To: 'Brian Trammell' 
Message-id: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acb0YN2wi5SdlE6qTHiB20daqN9kLgCEfb6A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi, Brain

Due to the reasons below, can we conclude that TLS is improper for IPFIX
while the transport protocol is SCTP?
Maybe it need more WG discussion. 

Yuzhi


> -----Original Message-----
> From: Brian Trammell [mailto:bht@cert.org] 
> Sent: Friday, October 20, 2006 11:58 PM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> Yuzhi,
> 
> Ah, yes... after reviewing RFC 3436 section 5, especially on 
> TLS session resumption, the language here confuses TLS 
> Sessions and Connections; it should read:
> 
>     Though TLS bindings to SCTP are defined in [RFC3436], they
>     require all communication to be over reliable, 
> bi-directional streams,
>     and require one TLS Connection per stream.  This 
> arrangement is not
>     compatible with the rationale behind the choice of SCTP 
> as an IPFIX
>     transport protocol.
> 
> Thanks,
> 
> Brian
> 
> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
> 
> > Hi,
> >
> > Section 11.1 Applicability of TLS and DTLS
> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >    require all communication to be over reliable streams, 
> and require
> >    one session per stream.  This arrangement is not compatible with 
> > the
> >    rationale behind the choice of SCTP as an IPFIX 
> transport protocol.
> >
> > RFC3436 Section 5 Connections and Bi-directional Streams
> >   TLS makes use of a bi-directional stream by establishing a 
> > connection
> >    over it.  This means that the number of connections for an
> >    association is limited by the number of bi-directional streams.
> >
> >
> > Does "one session per stream" mean  "one TLS session per 
> SCTP stream"?
> > If so, I think the description are unsuitable.
> >
> > Yuzhi
> >
> >> -----Original Message-----
> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> To: i-d-announce@ietf.org
> >> Cc: ipfix@ietf.org
> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> 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 Protocol
> >> for the Exchange of IP Traffic Flow Information
> >> 	Author(s)	: B. Claise
> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> 	Pages		: 63
> >> 	Date		: 2006-10-13
> >> 	
> >> This document specifies the IPFIX protocol that serves for
> >>    transmitting IP traffic flow information over the network.
> >>  In order
> >>    to transmit IP traffic flow information from an 
> exporting process 
> >> to
> >>    an information collecting process, a common 
> representation of flow
> >>    data and a standard means of communicating them is 
> required. This
> >>    document describes how the IPFIX data and templates records are
> >>    carried over a number of transport protocols from an IPFIX 
> >> exporting
> >>    process to an IPFIX collecting process.
> >>
> >> A URL for this Internet-Draft is:
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a 
> message to 
> >> i-d-announce-request@ietf.org with the word unsubscribe in 
> the body 
> >> of the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login 
> with the 
> >> username "anonymous" and a password of your e-mail address. After 
> >> logging in, type "cd internet-drafts" and then "get 
> >> draft-ietf-ipfix-protocol-23.txt".
> >>
> >> A list of Internet-Drafts directories can be found in 
> >> http://www.ietf.org/shadow.html or 
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	mailserv@ietf.org.
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> 	
> >> NOTE:	The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader 
> >> implementation to automatically retrieve the ASCII version of the 
> >> Internet-Draft.
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
> 
> Brian H. Trammell                            +1 
> 412 268  
> 9748
> Technical Lead, Engineering       CERT Network Situational Awareness  
> Group
> Software Engineering Institute, Carnegie Mellon University, 
> Pittsburgh, PA
> 
> 
> 
> 



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



From ipfix-bounces@ietf.org Mon Oct 23 09:21:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gbzib-0006Yt-Lw; Mon, 23 Oct 2006 09:19:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gbzia-0006YT-3g; Mon, 23 Oct 2006 09:19:52 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GbziW-0006Q8-8X; Mon, 23 Oct 2006 09:19:52 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 6864520031EF;
	Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 13850-08; Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 479C72000294;
	Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 23 Oct 2006 15:19:45 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Please post draft-dietz-ipfix-mib-01.txt
Thread-Index: Acb2peeFbnKItwv8SQ6mVFYnyV1vNg==
From: "Thomas Dietz" 
To: 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Juergen Quittek , ipfix@ietf.org
Subject: [IPFIX] Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0838791664=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0838791664==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_000A_01C6F6B6.AB1097F0"

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C6F6B6.AB1097F0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi,

please publish the following document as Internet Draft:

ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-mib-01.txt

Please announce the I-D ACTION also to the ipfix mailing list at
ipfix@ietf.org

Thank you.

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de

------=_NextPart_000_000A_01C6F6B6.AB1097F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDIzMTMx
OTQ0WjAjBgkqhkiG9w0BCQQxFgQUDaWTy5mLUBQPL+0yFY+2LbcvF2owZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBACR3YGUGYpiK+6TKpIWVGQiT
C7+bkjnv8ifHLqvOmiQKWQQdBDTMHJI0Kr6ZiXCWLshZQTFqrJN3dAS8myDMTlsEwiaIrtbZyDeK
QFuw0i7sxd+7eQjo2POT0ekzKEMkdCJ9/CE2X9LaetUirxzmLZuaF7r3m/qel/0r0e1GcDHl6XRT
2FObuoRMUjeF24R0IjaWs14HYhq5lLrA1CX1HXYWzmOzyiemcHjO1Dd1UOIZpLm9Ttiiui4N5D04
Ufx562bTUHhgpQVy6UIFm/P5IVbbUxMOlvLDb5z/wvmuai1OJ7rXTl07RyoVFZ+o6eUXJdk4S/iA
iGf+O3UC+TzdzdIAAAAAAAA=

------=_NextPart_000_000A_01C6F6B6.AB1097F0--


--===============0838791664==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0838791664==--




From ipfix-bounces@ietf.org Mon Oct 23 09:21:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gbzib-0006Yt-Lw; Mon, 23 Oct 2006 09:19:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gbzia-0006YT-3g; Mon, 23 Oct 2006 09:19:52 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GbziW-0006Q8-8X; Mon, 23 Oct 2006 09:19:52 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 6864520031EF;
	Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 13850-08; Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 479C72000294;
	Mon, 23 Oct 2006 15:20:18 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 23 Oct 2006 15:19:45 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Please post draft-dietz-ipfix-mib-01.txt
Thread-Index: Acb2peeFbnKItwv8SQ6mVFYnyV1vNg==
From: "Thomas Dietz" 
To: 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Juergen Quittek , ipfix@ietf.org
Subject: [IPFIX] Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0838791664=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0838791664==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_000A_01C6F6B6.AB1097F0"

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C6F6B6.AB1097F0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi,

please publish the following document as Internet Draft:

ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-mib-01.txt

Please announce the I-D ACTION also to the ipfix mailing list at
ipfix@ietf.org

Thank you.

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de

------=_NextPart_000_000A_01C6F6B6.AB1097F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDIzMTMx
OTQ0WjAjBgkqhkiG9w0BCQQxFgQUDaWTy5mLUBQPL+0yFY+2LbcvF2owZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBACR3YGUGYpiK+6TKpIWVGQiT
C7+bkjnv8ifHLqvOmiQKWQQdBDTMHJI0Kr6ZiXCWLshZQTFqrJN3dAS8myDMTlsEwiaIrtbZyDeK
QFuw0i7sxd+7eQjo2POT0ekzKEMkdCJ9/CE2X9LaetUirxzmLZuaF7r3m/qel/0r0e1GcDHl6XRT
2FObuoRMUjeF24R0IjaWs14HYhq5lLrA1CX1HXYWzmOzyiemcHjO1Dd1UOIZpLm9Ttiiui4N5D04
Ufx562bTUHhgpQVy6UIFm/P5IVbbUxMOlvLDb5z/wvmuai1OJ7rXTl07RyoVFZ+o6eUXJdk4S/iA
iGf+O3UC+TzdzdIAAAAAAAA=

------=_NextPart_000_000A_01C6F6B6.AB1097F0--


--===============0838791664==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0838791664==--




From ipfix-bounces@ietf.org Mon Oct 23 14:30:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc4YO-0000ZD-7s; Mon, 23 Oct 2006 14:29:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4YM-0000Z4-RF
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:29:38 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gc4Y1-0000Q8-R4
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:29:38 -0400
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
	k9NITG801057; Mon, 23 Oct 2006 20:29:16 +0200 (CEST)
Received: from [10.61.65.207] (ams3-vpn-dhcp463.cisco.com [10.61.65.207])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9NITDP18410; Mon, 23 Oct 2006 20:29:13 +0200 (CEST)
Message-ID: <453D09F8.6070909@cisco.com>
Date: Mon, 23 Oct 2006 20:29:12 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: David Harrington 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <030301c6f451$85959960$b07557c0@china.huawei.com>
In-Reply-To: <030301c6f451$85959960$b07557c0@china.huawei.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0910208315=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0910208315==
Content-Type: multipart/alternative;
	boundary="------------000306080101000402020006"

This is a multi-part message in MIME format.
--------------000306080101000402020006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave,
> Hi,
>  
> The question that was originally proposed was "should the IPFIX MIB be 
> writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems a 
> simple extension to make some of the objects writable, rather than 
> requring a whole extra protocol be supported to configure ipfix 
> parameters.
>  
> Has anybody argued that every aspect of IPFIX should be configurable 
> using the MIB module? I haven't seen anybody make such an argument, 
> and I am not making such an argument. Deciding that none of the 
> objects CAN be used by an application to modify the configuration of 
> IPFIX may make it difficiult to configure ipfix functionality.
>  
> Some of the questions below deal with anomalies, such as SCTP going 
> down. The question is not about SNMP, it is about interoperable IPFIX 
> behavior and should be addressed regardless of the management protocol 
> being used to do configuration.
On that specific issue, you've got a point. My example of SCTP going 
down was a bad one as this is independent of the management protocol.

regards, Benoit.
> If a collector uses Netconf to configure the templates, and SCTP goes 
> down, what should the collector do? delete the templates and 
> reconfigure them from scratch? wait for the template retransmission? 
> something else? What if CLI is used? The fact that some of the config 
> is done using SNMP should not be the telling factor; the appropriate 
> behavior should be specified regardless of config protocol.
>  
> Even if template management were to be addressed, there are ways to 
> reduce the complexity of configuration.
>  
> The question that should be asked is "which aspects of ipfix should be 
> made manageable, and how?". Such a discussion should consider issues 
> of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and 
> so on. And thsi discussion should happen whether the MIB module is 
> made writable or not.
>  
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>     ------------------------------------------------------------------------
>     *From:* Benoit Claise [mailto:bclaise@cisco.com]
>     *Sent:* Friday, October 20, 2006 2:33 PM
>     *To:* Thomas Dietz
>     *Cc:* ipfix@ietf.org
>     *Subject:* Re: [IPFIX] Should the IPFIX MIB be writeable?
>
>     Dear all,
>
>     If the question is: "would you like to have a writable MIB",  the
>     answer will probably be: "sure, it's useful/nice-to-have!"
>     It's a logical answer when you offer the choice of a solution with
>     more features compared to a solution with less features.
>
>     While I don't want to restart a discussion on SNMPset ("SNMPSet:
>     can it be saved?
>     http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
>     let me ask the question differently: will this read-write MIB be
>     practical and useful?
>
>     Let me concentrate on the Exporter MIB, as the Collector MIB
>     should be read-only (what can we configure on the collector side?)
>     Even if the information related to the IPFIX exporting process
>     (such as where to export, which transport protocol, which port,
>     backup or not, template retransmission timeout, etc...) is somehow
>     pretty static in networks, this type of configuration via SNMP
>     might be useful.
>     However, I'm not sure about the configuration of everything that
>     relates to metering process as it's getting pretty complex.
>     For example, is it practical to specify via SNMP all the possible
>     the template definition from Flexible NetFlow?
>          Flexible NetFlow =
>     http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
>     This would require the ipfixTemplateTable to have the following
>     indexes:
>         the transport session source IP address
>         the transport session destination IP address
>         the transport session source port
>         the transport session destination port
>         the observation domain Id
>         the template Id
>         the information element position
>     A table with 7 indexes. Sure, it's possible but this starts to be
>     quite a complex MIB
>     Some more remarks that will add to the complexity:
>     - In ipfixTemplateTable, we still need to find a way via SNMP to
>     express whether a specific I.E. is a flow key or not
>     - We have the choice of template versus options template. So an
>     extra table for options template is required. In this table, as we
>     can have multiple scope information elements, we need a way to
>     express whether an I.E. is a scope or not (similar to flow key in
>     ipfixTemplateTable)
>     - This implies that Template Ids are assigned by the collector if
>     the collector creates new templates.
>     - The collector configures the template Ids.
>       Note: remember that the template Id are unique per observation
>     domain and per transport session.
>       So now, if the SCTP association goes down, what should the
>     collector do?
>         1. erase all the templates on the exporter, and reconfigure
>     them? This implies that if only the connection is down, not the
>     metering process, then this action basically stopped the metering
>     process
>         2. wait for the template retransmission? What if the metering
>     process went down and the template id allocation changed. Shall
>     the collector update his MIB?
>         3. something else?
>     - As Thomas mentioned: "We must define the row status and how it
>     must be set and what each setting means."
>
>     To summarize, my views are:
>     Even if this might be an interesting little challenge to write
>     this MIB, I'm questioning this practicality/complexity... and as a
>     consequence its chances to be implemented if everything is read-write
>     However, I agree with the configuration of the exporting process
>     information
>     Finally I agree that a way to configure the templates is needed,
>     I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
>     Potential solution:
>     Could we have specify the full exporter MIB as writable, but limit
>     the metering part to read-only in the "Units of Conformance"?
>     That way, the end customers will decide by pushing or not the
>     vendor: SNMP versus NETCONF versus CLI
>
>     Regards, Benoit.
>>     Dear Benoit, Kobayashi and others,
>>
>>     I want to summarize 2 points that arose in the current discussion of the
>>     IPFIX MIB and poll the list for comments how we should proceed with it.
>>
>>     It is a fundamental decision if we should allow the IPFIX devices to be
>>     configured via SNMP. For the collector there is not much to configure but
>>     for the exporter there are many things that could be set-up, changed and
>>     deleted.
>>
>>     Making the MIB writeable would have the consequence that we need to
>>     carefully review the status for each variable and table. We must define the
>>     row status and how it must be set and what each setting means. Furthermore
>>     we need to carefully elaborate the conformance section and need to discuss
>>     every writeable object in the security considerations. So it is a really big
>>     effort to make the MIB writeable so that it is secure to use it.
>>
>>     Nevertheless, if the majority on the list has the opinion that it is really
>>     useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>>     take that effort.
>>
>>     Please keep in mind that the decision we take here would also affect the
>>     PSAMP MIB accordingly.
>>
>>     Awaiting your comments,
>>
>>     Thomas
>>
>>       
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     IPFIX mailing list
>>     IPFIX@ietf.org
>>     https://www1.ietf.org/mailman/listinfo/ipfix
>>       
>


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




  
  


Dave,


  
  
  
Hi,

  
 

  
The question that was originally
proposed was "should the IPFIX MIB be writable?"

  
I believe there would be benefit
to making IPFIX manageable.

  
Since you have defined a MIB
module to perform management, it seems a simple extension to make some
of the objects writable, rather than requring a whole extra protocol be
supported to configure ipfix parameters. 

  
 

  
Has anybody argued that every
aspect of IPFIX should be configurable using the MIB module? I haven't
seen anybody make such an argument, and I am not making such an
argument. Deciding that none of the objects CAN be used by
an application to modify the configuration of IPFIX may make it
difficiult to configure ipfix functionality. 

  
 

  
Some of the questions below deal
with anomalies, such as SCTP going down. The question is not about
SNMP, it is about interoperable IPFIX behavior and should be addressed
regardless of the management protocol being used to do configuration.



On that specific issue, you've got a point. My example of SCTP going
down was a bad one as this is independent of the management protocol.



regards, Benoit.



  
If a collector uses Netconf to
configure the templates, and SCTP goes down, what should the collector
do? delete the templates and reconfigure them from scratch? wait for
the template retransmission? something else? What if CLI is used? The
fact that some of the config is done using SNMP should not be the
telling factor; the appropriate behavior should be specified regardless
of config protocol.

  
 

  

  
Even if template management were
to be addressed, there are ways to reduce the complexity of
configuration.

  
 

  

  
The question that should be
asked is "which aspects of ipfix should be made manageable, and how?".
Such a discussion should consider issues of persistence, fate-sharing,
static vs. dynamic aspects of ipfix, and so on. And thsi discussion
should happen whether the MIB module is made writable or not.

  
 

  
  

  

    

    
 From:
Benoit Claise [mailto:bclaise@cisco.com] 

    Sent: Friday, October 20, 2006 2:33 PM

    To: Thomas Dietz

    Cc: ipfix@ietf.org

    Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?

    

    

Dear all,

    

If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"

It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.

    

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful? 

    

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)

Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.

However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.

For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?

     Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml

This would require the ipfixTemplateTable to have the following
indexes: 

    the transport session source IP address

    the transport session destination IP address

    the transport session source port

    the transport session destination port

    the observation domain Id

    the template Id

    the information element position

A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB

Some more remarks that will add to the complexity:

- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not

- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)

- This implies that Template Ids are assigned by the collector if the
collector creates new templates.

- The collector configures the template Ids. 

  Note: remember that the template Id are unique per observation domain
and per transport session. 

  So now, if the SCTP association goes down, what should the collector
do?

    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process

    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?

    3. something else?

- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."

    

To summarize, my views are:

Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 

However, I agree with the configuration of the exporting process
information

Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

    

Potential solution:

Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?

That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

    

Regards, Benoit.

    

      
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

      

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

    

    

  








--------------000306080101000402020006--


--===============0910208315==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0910208315==--




From ipfix-bounces@ietf.org Mon Oct 23 14:30:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc4YO-0000ZD-7s; Mon, 23 Oct 2006 14:29:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4YM-0000Z4-RF
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:29:38 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gc4Y1-0000Q8-R4
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:29:38 -0400
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
	k9NITG801057; Mon, 23 Oct 2006 20:29:16 +0200 (CEST)
Received: from [10.61.65.207] (ams3-vpn-dhcp463.cisco.com [10.61.65.207])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9NITDP18410; Mon, 23 Oct 2006 20:29:13 +0200 (CEST)
Message-ID: <453D09F8.6070909@cisco.com>
Date: Mon, 23 Oct 2006 20:29:12 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: David Harrington 
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?
References: <030301c6f451$85959960$b07557c0@china.huawei.com>
In-Reply-To: <030301c6f451$85959960$b07557c0@china.huawei.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0910208315=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0910208315==
Content-Type: multipart/alternative;
	boundary="------------000306080101000402020006"

This is a multi-part message in MIME format.
--------------000306080101000402020006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave,
> Hi,
>  
> The question that was originally proposed was "should the IPFIX MIB be 
> writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems a 
> simple extension to make some of the objects writable, rather than 
> requring a whole extra protocol be supported to configure ipfix 
> parameters.
>  
> Has anybody argued that every aspect of IPFIX should be configurable 
> using the MIB module? I haven't seen anybody make such an argument, 
> and I am not making such an argument. Deciding that none of the 
> objects CAN be used by an application to modify the configuration of 
> IPFIX may make it difficiult to configure ipfix functionality.
>  
> Some of the questions below deal with anomalies, such as SCTP going 
> down. The question is not about SNMP, it is about interoperable IPFIX 
> behavior and should be addressed regardless of the management protocol 
> being used to do configuration.
On that specific issue, you've got a point. My example of SCTP going 
down was a bad one as this is independent of the management protocol.

regards, Benoit.
> If a collector uses Netconf to configure the templates, and SCTP goes 
> down, what should the collector do? delete the templates and 
> reconfigure them from scratch? wait for the template retransmission? 
> something else? What if CLI is used? The fact that some of the config 
> is done using SNMP should not be the telling factor; the appropriate 
> behavior should be specified regardless of config protocol.
>  
> Even if template management were to be addressed, there are ways to 
> reduce the complexity of configuration.
>  
> The question that should be asked is "which aspects of ipfix should be 
> made manageable, and how?". Such a discussion should consider issues 
> of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and 
> so on. And thsi discussion should happen whether the MIB module is 
> made writable or not.
>  
>
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>     ------------------------------------------------------------------------
>     *From:* Benoit Claise [mailto:bclaise@cisco.com]
>     *Sent:* Friday, October 20, 2006 2:33 PM
>     *To:* Thomas Dietz
>     *Cc:* ipfix@ietf.org
>     *Subject:* Re: [IPFIX] Should the IPFIX MIB be writeable?
>
>     Dear all,
>
>     If the question is: "would you like to have a writable MIB",  the
>     answer will probably be: "sure, it's useful/nice-to-have!"
>     It's a logical answer when you offer the choice of a solution with
>     more features compared to a solution with less features.
>
>     While I don't want to restart a discussion on SNMPset ("SNMPSet:
>     can it be saved?
>     http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
>     let me ask the question differently: will this read-write MIB be
>     practical and useful?
>
>     Let me concentrate on the Exporter MIB, as the Collector MIB
>     should be read-only (what can we configure on the collector side?)
>     Even if the information related to the IPFIX exporting process
>     (such as where to export, which transport protocol, which port,
>     backup or not, template retransmission timeout, etc...) is somehow
>     pretty static in networks, this type of configuration via SNMP
>     might be useful.
>     However, I'm not sure about the configuration of everything that
>     relates to metering process as it's getting pretty complex.
>     For example, is it practical to specify via SNMP all the possible
>     the template definition from Flexible NetFlow?
>          Flexible NetFlow =
>     http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
>     This would require the ipfixTemplateTable to have the following
>     indexes:
>         the transport session source IP address
>         the transport session destination IP address
>         the transport session source port
>         the transport session destination port
>         the observation domain Id
>         the template Id
>         the information element position
>     A table with 7 indexes. Sure, it's possible but this starts to be
>     quite a complex MIB
>     Some more remarks that will add to the complexity:
>     - In ipfixTemplateTable, we still need to find a way via SNMP to
>     express whether a specific I.E. is a flow key or not
>     - We have the choice of template versus options template. So an
>     extra table for options template is required. In this table, as we
>     can have multiple scope information elements, we need a way to
>     express whether an I.E. is a scope or not (similar to flow key in
>     ipfixTemplateTable)
>     - This implies that Template Ids are assigned by the collector if
>     the collector creates new templates.
>     - The collector configures the template Ids.
>       Note: remember that the template Id are unique per observation
>     domain and per transport session.
>       So now, if the SCTP association goes down, what should the
>     collector do?
>         1. erase all the templates on the exporter, and reconfigure
>     them? This implies that if only the connection is down, not the
>     metering process, then this action basically stopped the metering
>     process
>         2. wait for the template retransmission? What if the metering
>     process went down and the template id allocation changed. Shall
>     the collector update his MIB?
>         3. something else?
>     - As Thomas mentioned: "We must define the row status and how it
>     must be set and what each setting means."
>
>     To summarize, my views are:
>     Even if this might be an interesting little challenge to write
>     this MIB, I'm questioning this practicality/complexity... and as a
>     consequence its chances to be implemented if everything is read-write
>     However, I agree with the configuration of the exporting process
>     information
>     Finally I agree that a way to configure the templates is needed,
>     I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
>     Potential solution:
>     Could we have specify the full exporter MIB as writable, but limit
>     the metering part to read-only in the "Units of Conformance"?
>     That way, the end customers will decide by pushing or not the
>     vendor: SNMP versus NETCONF versus CLI
>
>     Regards, Benoit.
>>     Dear Benoit, Kobayashi and others,
>>
>>     I want to summarize 2 points that arose in the current discussion of the
>>     IPFIX MIB and poll the list for comments how we should proceed with it.
>>
>>     It is a fundamental decision if we should allow the IPFIX devices to be
>>     configured via SNMP. For the collector there is not much to configure but
>>     for the exporter there are many things that could be set-up, changed and
>>     deleted.
>>
>>     Making the MIB writeable would have the consequence that we need to
>>     carefully review the status for each variable and table. We must define the
>>     row status and how it must be set and what each setting means. Furthermore
>>     we need to carefully elaborate the conformance section and need to discuss
>>     every writeable object in the security considerations. So it is a really big
>>     effort to make the MIB writeable so that it is secure to use it.
>>
>>     Nevertheless, if the majority on the list has the opinion that it is really
>>     useful to have the MIB (especially the EXPORTER MIB) writeable than we would
>>     take that effort.
>>
>>     Please keep in mind that the decision we take here would also affect the
>>     PSAMP MIB accordingly.
>>
>>     Awaiting your comments,
>>
>>     Thomas
>>
>>       
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     IPFIX mailing list
>>     IPFIX@ietf.org
>>     https://www1.ietf.org/mailman/listinfo/ipfix
>>       
>


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




  
  


Dave,


  
  
  
Hi,

  
 

  
The question that was originally
proposed was "should the IPFIX MIB be writable?"

  
I believe there would be benefit
to making IPFIX manageable.

  
Since you have defined a MIB
module to perform management, it seems a simple extension to make some
of the objects writable, rather than requring a whole extra protocol be
supported to configure ipfix parameters. 

  
 

  
Has anybody argued that every
aspect of IPFIX should be configurable using the MIB module? I haven't
seen anybody make such an argument, and I am not making such an
argument. Deciding that none of the objects CAN be used by
an application to modify the configuration of IPFIX may make it
difficiult to configure ipfix functionality. 

  
 

  
Some of the questions below deal
with anomalies, such as SCTP going down. The question is not about
SNMP, it is about interoperable IPFIX behavior and should be addressed
regardless of the management protocol being used to do configuration.



On that specific issue, you've got a point. My example of SCTP going
down was a bad one as this is independent of the management protocol.



regards, Benoit.



  
If a collector uses Netconf to
configure the templates, and SCTP goes down, what should the collector
do? delete the templates and reconfigure them from scratch? wait for
the template retransmission? something else? What if CLI is used? The
fact that some of the config is done using SNMP should not be the
telling factor; the appropriate behavior should be specified regardless
of config protocol.

  
 

  

  
Even if template management were
to be addressed, there are ways to reduce the complexity of
configuration.

  
 

  

  
The question that should be
asked is "which aspects of ipfix should be made manageable, and how?".
Such a discussion should consider issues of persistence, fate-sharing,
static vs. dynamic aspects of ipfix, and so on. And thsi discussion
should happen whether the MIB module is made writable or not.

  
 

  
  

  

    

    
 From:
Benoit Claise [mailto:bclaise@cisco.com] 

    Sent: Friday, October 20, 2006 2:33 PM

    To: Thomas Dietz

    Cc: ipfix@ietf.org

    Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?

    

    

Dear all,

    

If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"

It's a logical answer when you offer the choice of a solution with more
features compared to a solution with less features.

    

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it
be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction), 
let me ask the question differently: will this read-write MIB be
practical and useful? 

    

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)

Even if the information related to the IPFIX exporting process (such as
where to export, which transport protocol, which port, backup or not,
template retransmission timeout, etc...) is somehow pretty static in
networks, this type of configuration via SNMP might be useful.

However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.

For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?

     Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml

This would require the ipfixTemplateTable to have the following
indexes: 

    the transport session source IP address

    the transport session destination IP address

    the transport session source port

    the transport session destination port

    the observation domain Id

    the template Id

    the information element position

A table with 7 indexes. Sure, it's possible but this starts to be quite
a complex MIB

Some more remarks that will add to the complexity:

- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not

- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)

- This implies that Template Ids are assigned by the collector if the
collector creates new templates.

- The collector configures the template Ids. 

  Note: remember that the template Id are unique per observation domain
and per transport session. 

  So now, if the SCTP association goes down, what should the collector
do?

    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process

    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?

    3. something else?

- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."

    

To summarize, my views are:

Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 

However, I agree with the configuration of the exporting process
information

Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

    

Potential solution:

Could we have specify the full exporter MIB as writable, but limit the
metering part to read-only in the "Units of Conformance"?

That way, the end customers will decide by pushing or not the vendor:
SNMP versus NETCONF versus CLI

    

Regards, Benoit.

    

      
Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  

      

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

    

    

  








--------------000306080101000402020006--


--===============0910208315==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============0910208315==--




From ipfix-bounces@ietf.org Mon Oct 23 14:32:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc4ah-0001Vw-UW; Mon, 23 Oct 2006 14:32:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4ah-0001Vr-9M
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:32:03 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gc4aX-0000hm-G3
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:32:03 -0400
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
	k9NIVqY01170; Mon, 23 Oct 2006 20:31:52 +0200 (CEST)
Received: from [10.61.65.207] (ams3-vpn-dhcp463.cisco.com [10.61.65.207])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9NIVpP20127; Mon, 23 Oct 2006 20:31:51 +0200 (CEST)
Message-ID: <453D0A96.9000105@cisco.com>
Date: Mon, 23 Oct 2006 20:31:50 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz 
References: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ipfix@ietf.org
Subject: [IPFIX] Re: Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Thomas,

Thanks for your work editing the draft.
Haven't we agreed that this draft should be a working group item? 
Independently of the current open issue on the MIB write-ability.

Regards, Benoit.
> Hi,
>
> please publish the following document as Internet Draft:
>
> ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-mib-01.txt
>
> Please announce the I-D ACTION also to the ipfix mailing list at
> ipfix@ietf.org
>
> Thank you.
>
> Thomas
>
>   


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



From ipfix-bounces@ietf.org Mon Oct 23 14:32:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc4ah-0001Vw-UW; Mon, 23 Oct 2006 14:32:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4ah-0001Vr-9M
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:32:03 -0400
Received: from weird-brew.cisco.com ([144.254.15.118]
	helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gc4aX-0000hm-G3
	for ipfix@ietf.org; Mon, 23 Oct 2006 14:32:03 -0400
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
	k9NIVqY01170; Mon, 23 Oct 2006 20:31:52 +0200 (CEST)
Received: from [10.61.65.207] (ams3-vpn-dhcp463.cisco.com [10.61.65.207])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	k9NIVpP20127; Mon, 23 Oct 2006 20:31:51 +0200 (CEST)
Message-ID: <453D0A96.9000105@cisco.com>
Date: Mon, 23 Oct 2006 20:31:50 +0200
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz 
References: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6963A4E66@mx1.office>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ipfix@ietf.org
Subject: [IPFIX] Re: Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Thomas,

Thanks for your work editing the draft.
Haven't we agreed that this draft should be a working group item? 
Independently of the current open issue on the MIB write-ability.

Regards, Benoit.
> Hi,
>
> please publish the following document as Internet Draft:
>
> ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-mib-01.txt
>
> Please announce the I-D ACTION also to the ipfix mailing list at
> ipfix@ietf.org
>
> Thank you.
>
> Thomas
>
>   


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



From ipfix-bounces@ietf.org Mon Oct 23 19:08:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc8sh-0004WF-IG; Mon, 23 Oct 2006 19:06:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8sg-0004Vq-89
	for ipfix@ietf.org; Mon, 23 Oct 2006 19:06:54 -0400
Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8sZ-0004RB-Vq
	for ipfix@ietf.org; Mon, 23 Oct 2006 19:06:54 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 4958B37DF0;
	Tue, 24 Oct 2006 12:06:38 +1300 (NZDT)
Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1])
	by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29459-21; Tue, 24 Oct 2006 12:06:37 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz
	[130.216.191.146])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 5240337B4C;
	Tue, 24 Oct 2006 11:16:18 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1])
	by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP
	id k9NMGIIM029160; Tue, 24 Oct 2006 11:16:18 +1300
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id
	k9NMGIWT029158; Tue, 24 Oct 2006 11:16:18 +1300
X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to
	nevil@auckland.ac.nz using -f
Received: from nevil-laptop.sfac.auckland.ac.nz
	(nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) by
	webmail.auckland.ac.nz (Horde MIME library) with HTTP; Tue, 24 Oct 2006
	11:16:17 +1300
Message-ID: <20061024111617.voo5ywi98ao4og08@webmail.auckland.ac.nz>
Date: Tue, 24 Oct 2006 11:16:17 +1300
From: Nevil Brownlee 
To: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
References: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
In-Reply-To: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Hi Yuzhi:

I think this points to a need for better understanding of TLS.

If you use SCTP, *without* the SCTP-PR extension, then you have all
streams running through a reliable connection, and you can use TLS to
protect the connection.  No problems there.

However, if you want to use SCTP-PR, then at least some of the streams
will be unreliable, that's why protocol-23 says you must use DTLS with SCTP.
The phrase "not compatible with the rationale behind the choice of SCTP
as an IPFIX transport protocol" reminds you that IPFIX data may be lost
during peaks of network activity.

To answer your question (below), it's inappropriate to use TLS with IPFIX
over SCTP.

Cheers, Nevil

> Due to the reasons below, can we conclude that TLS is improper for IPFIX
> while the transport protocol is SCTP?
> Maybe it need more WG discussion.
>
> Yuzhi
>
>
>> -----Original Message-----
>> From: Brian Trammell [mailto:bht@cert.org]
>> Sent: Friday, October 20, 2006 11:58 PM
>> To: Ma Yuzhi
>> Cc: ipfix@ietf.org
>> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>>
>> Yuzhi,
>>
>> Ah, yes... after reviewing RFC 3436 section 5, especially on
>> TLS session resumption, the language here confuses TLS
>> Sessions and Connections; it should read:
>>
>>     Though TLS bindings to SCTP are defined in [RFC3436], they
>>     require all communication to be over reliable,
>> bi-directional streams,
>>     and require one TLS Connection per stream.  This
>> arrangement is not
>>     compatible with the rationale behind the choice of SCTP
>> as an IPFIX
>>     transport protocol.
>>
>> Thanks,
>>
>> Brian
>>
>> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
>>
>> > Hi,
>> >
>> > Section 11.1 Applicability of TLS and DTLS
>> >    Though TLS bindings to SCTP are defined in [RFC3436], they
>> >    require all communication to be over reliable streams,
>> and require
>> >    one session per stream.  This arrangement is not compatible with
>> > the
>> >    rationale behind the choice of SCTP as an IPFIX
>> transport protocol.
>> >
>> > RFC3436 Section 5 Connections and Bi-directional Streams
>> >   TLS makes use of a bi-directional stream by establishing a
>> > connection
>> >    over it.  This means that the number of connections for an
>> >    association is limited by the number of bi-directional streams.
>> >
>> >
>> > Does "one session per stream" mean  "one TLS session per
>> SCTP stream"?
>> > If so, I think the description are unsuitable.
>> >
>> > Yuzhi
>> >
>> >> -----Original Message-----
>> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> >> Sent: Saturday, October 14, 2006 3:50 AM
>> >> To: i-d-announce@ietf.org
>> >> Cc: ipfix@ietf.org
>> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>> >>
>> >> 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 Protocol
>> >> for the Exchange of IP Traffic Flow Information
>> >> 	Author(s)	: B. Claise
>> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
>> >> 	Pages		: 63
>> >> 	Date		: 2006-10-13
>> >>
>> >> This document specifies the IPFIX protocol that serves for
>> >>    transmitting IP traffic flow information over the network.
>> >>  In order
>> >>    to transmit IP traffic flow information from an
>> exporting process
>> >> to
>> >>    an information collecting process, a common
>> representation of flow
>> >>    data and a standard means of communicating them is
>> required. This
>> >>    document describes how the IPFIX data and templates records are
>> >>    carried over a number of transport protocols from an IPFIX
>> >> exporting
>> >>    process to an IPFIX collecting process.
>> >>
>> >> A URL for this Internet-Draft is:
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
>> >>
>> >> To remove yourself from the I-D Announcement list, send a
>> message to
>> >> i-d-announce-request@ietf.org with the word unsubscribe in
>> the body
>> >> of the message.
>> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
>> >> announce
>> >> to change your subscription settings.
>> >>
>> >> Internet-Drafts are also available by anonymous FTP. Login
>> with the
>> >> username "anonymous" and a password of your e-mail address. After
>> >> logging in, type "cd internet-drafts" and then "get
>> >> draft-ietf-ipfix-protocol-23.txt".
>> >>
>> >> A list of Internet-Drafts directories can be found in
>> >> http://www.ietf.org/shadow.html or
>> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >>
>> >> Internet-Drafts can also be obtained by e-mail.
>> >>
>> >> Send a message to:
>> >> 	mailserv@ietf.org.
>> >> In the body type:
>> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
>> >>
>> >> NOTE:	The mail server at ietf.org can return the document in
>> >> 	MIME-encoded form by using the "mpack" utility.  To use this
>> >> 	feature, insert the command "ENCODING mime" before the "FILE"
>> >> 	command.  To decode the response(s), you will need "munpack" or
>> >> 	a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>> >> 	exhibit different behavior, especially when dealing with
>> >> 	"multipart" MIME messages (i.e. documents which have been split
>> >> 	up into multiple messages), so check your local documentation on
>> >> 	how to manipulate these messages.
>> >>
>> >> Below is the data which will enable a MIME compliant mail reader
>> >> implementation to automatically retrieve the ASCII version of the
>> >> Internet-Draft.
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > IPFIX mailing list
>> > IPFIX@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/ipfix
>>
>> Brian H. Trammell                            +1
>> 412 268
>> 9748
>> Technical Lead, Engineering       CERT Network Situational Awareness
>> Group
>> Software Engineering Institute, Carnegie Mellon University,
>> Pittsburgh, PA
>>
>>
>>
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>



-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz


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



From ipfix-bounces@ietf.org Mon Oct 23 19:08:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gc8sh-0004WF-IG; Mon, 23 Oct 2006 19:06:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8sg-0004Vq-89
	for ipfix@ietf.org; Mon, 23 Oct 2006 19:06:54 -0400
Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8sZ-0004RB-Vq
	for ipfix@ietf.org; Mon, 23 Oct 2006 19:06:54 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 4958B37DF0;
	Tue, 24 Oct 2006 12:06:38 +1300 (NZDT)
Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1])
	by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29459-21; Tue, 24 Oct 2006 12:06:37 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz
	[130.216.191.146])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 5240337B4C;
	Tue, 24 Oct 2006 11:16:18 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1])
	by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP
	id k9NMGIIM029160; Tue, 24 Oct 2006 11:16:18 +1300
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id
	k9NMGIWT029158; Tue, 24 Oct 2006 11:16:18 +1300
X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to
	nevil@auckland.ac.nz using -f
Received: from nevil-laptop.sfac.auckland.ac.nz
	(nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) by
	webmail.auckland.ac.nz (Horde MIME library) with HTTP; Tue, 24 Oct 2006
	11:16:17 +1300
Message-ID: <20061024111617.voo5ywi98ao4og08@webmail.auckland.ac.nz>
Date: Tue, 24 Oct 2006 11:16:17 +1300
From: Nevil Brownlee 
To: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
References: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
In-Reply-To: <03cd01c6f678$d7bcf070$410c6f0a@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Hi Yuzhi:

I think this points to a need for better understanding of TLS.

If you use SCTP, *without* the SCTP-PR extension, then you have all
streams running through a reliable connection, and you can use TLS to
protect the connection.  No problems there.

However, if you want to use SCTP-PR, then at least some of the streams
will be unreliable, that's why protocol-23 says you must use DTLS with SCTP.
The phrase "not compatible with the rationale behind the choice of SCTP
as an IPFIX transport protocol" reminds you that IPFIX data may be lost
during peaks of network activity.

To answer your question (below), it's inappropriate to use TLS with IPFIX
over SCTP.

Cheers, Nevil

> Due to the reasons below, can we conclude that TLS is improper for IPFIX
> while the transport protocol is SCTP?
> Maybe it need more WG discussion.
>
> Yuzhi
>
>
>> -----Original Message-----
>> From: Brian Trammell [mailto:bht@cert.org]
>> Sent: Friday, October 20, 2006 11:58 PM
>> To: Ma Yuzhi
>> Cc: ipfix@ietf.org
>> Subject: Re: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>>
>> Yuzhi,
>>
>> Ah, yes... after reviewing RFC 3436 section 5, especially on
>> TLS session resumption, the language here confuses TLS
>> Sessions and Connections; it should read:
>>
>>     Though TLS bindings to SCTP are defined in [RFC3436], they
>>     require all communication to be over reliable,
>> bi-directional streams,
>>     and require one TLS Connection per stream.  This
>> arrangement is not
>>     compatible with the rationale behind the choice of SCTP
>> as an IPFIX
>>     transport protocol.
>>
>> Thanks,
>>
>> Brian
>>
>> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
>>
>> > Hi,
>> >
>> > Section 11.1 Applicability of TLS and DTLS
>> >    Though TLS bindings to SCTP are defined in [RFC3436], they
>> >    require all communication to be over reliable streams,
>> and require
>> >    one session per stream.  This arrangement is not compatible with
>> > the
>> >    rationale behind the choice of SCTP as an IPFIX
>> transport protocol.
>> >
>> > RFC3436 Section 5 Connections and Bi-directional Streams
>> >   TLS makes use of a bi-directional stream by establishing a
>> > connection
>> >    over it.  This means that the number of connections for an
>> >    association is limited by the number of bi-directional streams.
>> >
>> >
>> > Does "one session per stream" mean  "one TLS session per
>> SCTP stream"?
>> > If so, I think the description are unsuitable.
>> >
>> > Yuzhi
>> >
>> >> -----Original Message-----
>> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> >> Sent: Saturday, October 14, 2006 3:50 AM
>> >> To: i-d-announce@ietf.org
>> >> Cc: ipfix@ietf.org
>> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
>> >>
>> >> 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 Protocol
>> >> for the Exchange of IP Traffic Flow Information
>> >> 	Author(s)	: B. Claise
>> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
>> >> 	Pages		: 63
>> >> 	Date		: 2006-10-13
>> >>
>> >> This document specifies the IPFIX protocol that serves for
>> >>    transmitting IP traffic flow information over the network.
>> >>  In order
>> >>    to transmit IP traffic flow information from an
>> exporting process
>> >> to
>> >>    an information collecting process, a common
>> representation of flow
>> >>    data and a standard means of communicating them is
>> required. This
>> >>    document describes how the IPFIX data and templates records are
>> >>    carried over a number of transport protocols from an IPFIX
>> >> exporting
>> >>    process to an IPFIX collecting process.
>> >>
>> >> A URL for this Internet-Draft is:
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
>> >>
>> >> To remove yourself from the I-D Announcement list, send a
>> message to
>> >> i-d-announce-request@ietf.org with the word unsubscribe in
>> the body
>> >> of the message.
>> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
>> >> announce
>> >> to change your subscription settings.
>> >>
>> >> Internet-Drafts are also available by anonymous FTP. Login
>> with the
>> >> username "anonymous" and a password of your e-mail address. After
>> >> logging in, type "cd internet-drafts" and then "get
>> >> draft-ietf-ipfix-protocol-23.txt".
>> >>
>> >> A list of Internet-Drafts directories can be found in
>> >> http://www.ietf.org/shadow.html or
>> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >>
>> >> Internet-Drafts can also be obtained by e-mail.
>> >>
>> >> Send a message to:
>> >> 	mailserv@ietf.org.
>> >> In the body type:
>> >> 	"FILE /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
>> >>
>> >> NOTE:	The mail server at ietf.org can return the document in
>> >> 	MIME-encoded form by using the "mpack" utility.  To use this
>> >> 	feature, insert the command "ENCODING mime" before the "FILE"
>> >> 	command.  To decode the response(s), you will need "munpack" or
>> >> 	a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>> >> 	exhibit different behavior, especially when dealing with
>> >> 	"multipart" MIME messages (i.e. documents which have been split
>> >> 	up into multiple messages), so check your local documentation on
>> >> 	how to manipulate these messages.
>> >>
>> >> Below is the data which will enable a MIME compliant mail reader
>> >> implementation to automatically retrieve the ASCII version of the
>> >> Internet-Draft.
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > IPFIX mailing list
>> > IPFIX@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/ipfix
>>
>> Brian H. Trammell                            +1
>> 412 268
>> 9748
>> Technical Lead, Engineering       CERT Network Situational Awareness
>> Group
>> Software Engineering Institute, Carnegie Mellon University,
>> Pittsburgh, PA
>>
>>
>>
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>



-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz


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



From ipfix-bounces@ietf.org Mon Oct 23 23:12:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GcCgz-0005W6-6F; Mon, 23 Oct 2006 23:11:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCgy-0005W1-2y
	for ipfix@ietf.org; Mon, 23 Oct 2006 23:11:04 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcCgu-0000P5-PW
	for ipfix@ietf.org; Mon, 23 Oct 2006 23:11:04 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7M00FWWEOD7J@szxga03-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:21:49 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7M00CI7EOC50@szxga03-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:21:49 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7M0072VERG4H@szxml04-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:23:44 +0800 (CST)
Date: Tue, 24 Oct 2006 11:10:05 +0800
From: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
In-reply-to: <20061024111617.voo5ywi98ao4og08@webmail.auckland.ac.nz>
To: 'Nevil Brownlee' 
Message-id: <028a01c6f719$e7a410d0$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: Acb29/HBhr/asxksTUOnXf9A9njwMgAFd9Gg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi, Nevil

Please find my inline response.

Thanks, Yuzhi

> -----Original Message-----
> From: Nevil Brownlee [mailto:nevil@auckland.ac.nz] 
> Sent: Tuesday, October 24, 2006 6:16 AM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> 
> Hi Yuzhi:
> 
> I think this points to a need for better understanding of TLS.
> 
> If you use SCTP, *without* the SCTP-PR extension, then you 
> have all streams running through a reliable connection, and 
> you can use TLS to protect the connection.  No problems there.
> 
In this scenario, It may not be inappropriate to use TLS with IPFIX over
SCTP.

> However, if you want to use SCTP-PR, then at least some of 
> the streams will be unreliable, that's why protocol-23 says 
> you must use DTLS with SCTP.
> The phrase "not compatible with the rationale behind the 
> choice of SCTP as an IPFIX transport protocol" reminds you 
> that IPFIX data may be lost during peaks of network activity.
> 
If IPFIX Template Set and Options Template Set can be sent on reliable
stream, I think it is acceptable for some application even though some IPFIX
data may be lost.
I agree on using DTLS with SCTP in protocol-23, but  may not  MUST use it. 


> To answer your question (below), it's inappropriate to use 
> TLS with IPFIX over SCTP.
> 
> Cheers, Nevil
> 
> > Due to the reasons below, can we conclude that TLS is improper for 
> > IPFIX while the transport protocol is SCTP?
> > Maybe it need more WG discussion.
> >
> > Yuzhi
> >
> >
> >> -----Original Message-----
> >> From: Brian Trammell [mailto:bht@cert.org]
> >> Sent: Friday, October 20, 2006 11:58 PM
> >> To: Ma Yuzhi
> >> Cc: ipfix@ietf.org
> >> Subject: Re: [IPFIX] RE: I-D 
> ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> Yuzhi,
> >>
> >> Ah, yes... after reviewing RFC 3436 section 5, especially on TLS 
> >> session resumption, the language here confuses TLS Sessions and 
> >> Connections; it should read:
> >>
> >>     Though TLS bindings to SCTP are defined in [RFC3436], they
> >>     require all communication to be over reliable, bi-directional 
> >> streams,
> >>     and require one TLS Connection per stream.  This 
> arrangement is 
> >> not
> >>     compatible with the rationale behind the choice of SCTP as an 
> >> IPFIX
> >>     transport protocol.
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
> >>
> >> > Hi,
> >> >
> >> > Section 11.1 Applicability of TLS and DTLS
> >> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >> >    require all communication to be over reliable streams,
> >> and require
> >> >    one session per stream.  This arrangement is not 
> compatible with 
> >> > the
> >> >    rationale behind the choice of SCTP as an IPFIX
> >> transport protocol.
> >> >
> >> > RFC3436 Section 5 Connections and Bi-directional Streams
> >> >   TLS makes use of a bi-directional stream by establishing a 
> >> > connection
> >> >    over it.  This means that the number of connections for an
> >> >    association is limited by the number of 
> bi-directional streams.
> >> >
> >> >
> >> > Does "one session per stream" mean  "one TLS session per
> >> SCTP stream"?
> >> > If so, I think the description are unsuitable.
> >> >
> >> > Yuzhi
> >> >
> >> >> -----Original Message-----
> >> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> >> To: i-d-announce@ietf.org
> >> >> Cc: ipfix@ietf.org
> >> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >> >>
> >> >> 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 Protocol
> >> >> for the Exchange of IP Traffic Flow Information
> >> >> 	Author(s)	: B. Claise
> >> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> >> 	Pages		: 63
> >> >> 	Date		: 2006-10-13
> >> >>
> >> >> This document specifies the IPFIX protocol that serves for
> >> >>    transmitting IP traffic flow information over the network.
> >> >>  In order
> >> >>    to transmit IP traffic flow information from an
> >> exporting process
> >> >> to
> >> >>    an information collecting process, a common
> >> representation of flow
> >> >>    data and a standard means of communicating them is
> >> required. This
> >> >>    document describes how the IPFIX data and templates 
> records are
> >> >>    carried over a number of transport protocols from an IPFIX 
> >> >> exporting
> >> >>    process to an IPFIX collecting process.
> >> >>
> >> >> A URL for this Internet-Draft is:
> >> >>
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >> >>
> >> >> To remove yourself from the I-D Announcement list, send a
> >> message to
> >> >> i-d-announce-request@ietf.org with the word unsubscribe in
> >> the body
> >> >> of the message.
> >> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> >> announce
> >> >> to change your subscription settings.
> >> >>
> >> >> Internet-Drafts are also available by anonymous FTP. Login
> >> with the
> >> >> username "anonymous" and a password of your e-mail 
> address. After 
> >> >> logging in, type "cd internet-drafts" and then "get 
> >> >> draft-ietf-ipfix-protocol-23.txt".
> >> >>
> >> >> A list of Internet-Drafts directories can be found in 
> >> >> http://www.ietf.org/shadow.html or 
> >> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >> >>
> >> >> Internet-Drafts can also be obtained by e-mail.
> >> >>
> >> >> Send a message to:
> >> >> 	mailserv@ietf.org.
> >> >> In the body type:
> >> >> 	"FILE 
> /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> >>
> >> >> NOTE:	The mail server at ietf.org can return the document in
> >> >> 	MIME-encoded form by using the "mpack" utility. 
>  To use this
> >> >> 	feature, insert the command "ENCODING mime" 
> before the "FILE"
> >> >> 	command.  To decode the response(s), you will 
> need "munpack" or
> >> >> 	a MIME-compliant mail reader.  Different MIME-compliant
> >> mail readers
> >> >> 	exhibit different behavior, especially when dealing with
> >> >> 	"multipart" MIME messages (i.e. documents which 
> have been split
> >> >> 	up into multiple messages), so check your local 
> documentation on
> >> >> 	how to manipulate these messages.
> >> >>
> >> >> Below is the data which will enable a MIME compliant 
> mail reader 
> >> >> implementation to automatically retrieve the ASCII 
> version of the 
> >> >> Internet-Draft.
> >> >>
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > IPFIX mailing list
> >> > IPFIX@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/ipfix
> >>
> >> Brian H. Trammell                            +1
> >> 412 268
> >> 9748
> >> Technical Lead, Engineering       CERT Network Situational 
> Awareness
> >> Group
> >> Software Engineering Institute, Carnegie Mellon University, 
> >> Pittsburgh, PA
> >>
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
> >
> 
> 
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                 Computer Science Department | ITSS
>    Phone: +64 9 373 7599 x88941           The University of Auckland
>    FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand
> 
> --------------------------------------------------------------
> ---------
> This mail sent through University of Auckland 
> http://www.auckland.ac.nz
> 
> 



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



From ipfix-bounces@ietf.org Mon Oct 23 23:12:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GcCgz-0005W6-6F; Mon, 23 Oct 2006 23:11:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCgy-0005W1-2y
	for ipfix@ietf.org; Mon, 23 Oct 2006 23:11:04 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcCgu-0000P5-PW
	for ipfix@ietf.org; Mon, 23 Oct 2006 23:11:04 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7M00FWWEOD7J@szxga03-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:21:49 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7M00CI7EOC50@szxga03-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:21:49 +0800 (CST)
Received: from m03573B ([10.111.12.65])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7M0072VERG4H@szxml04-in.huawei.com> for
	ipfix@ietf.org; Tue, 24 Oct 2006 11:23:44 +0800 (CST)
Date: Tue, 24 Oct 2006 11:10:05 +0800
From: Ma Yuzhi 
Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
In-reply-to: <20061024111617.voo5ywi98ao4og08@webmail.auckland.ac.nz>
To: 'Nevil Brownlee' 
Message-id: <028a01c6f719$e7a410d0$410c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: Acb29/HBhr/asxksTUOnXf9A9njwMgAFd9Gg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi, Nevil

Please find my inline response.

Thanks, Yuzhi

> -----Original Message-----
> From: Nevil Brownlee [mailto:nevil@auckland.ac.nz] 
> Sent: Tuesday, October 24, 2006 6:16 AM
> To: Ma Yuzhi
> Cc: ipfix@ietf.org
> Subject: RE: [IPFIX] RE: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> 
> 
> Hi Yuzhi:
> 
> I think this points to a need for better understanding of TLS.
> 
> If you use SCTP, *without* the SCTP-PR extension, then you 
> have all streams running through a reliable connection, and 
> you can use TLS to protect the connection.  No problems there.
> 
In this scenario, It may not be inappropriate to use TLS with IPFIX over
SCTP.

> However, if you want to use SCTP-PR, then at least some of 
> the streams will be unreliable, that's why protocol-23 says 
> you must use DTLS with SCTP.
> The phrase "not compatible with the rationale behind the 
> choice of SCTP as an IPFIX transport protocol" reminds you 
> that IPFIX data may be lost during peaks of network activity.
> 
If IPFIX Template Set and Options Template Set can be sent on reliable
stream, I think it is acceptable for some application even though some IPFIX
data may be lost.
I agree on using DTLS with SCTP in protocol-23, but  may not  MUST use it. 


> To answer your question (below), it's inappropriate to use 
> TLS with IPFIX over SCTP.
> 
> Cheers, Nevil
> 
> > Due to the reasons below, can we conclude that TLS is improper for 
> > IPFIX while the transport protocol is SCTP?
> > Maybe it need more WG discussion.
> >
> > Yuzhi
> >
> >
> >> -----Original Message-----
> >> From: Brian Trammell [mailto:bht@cert.org]
> >> Sent: Friday, October 20, 2006 11:58 PM
> >> To: Ma Yuzhi
> >> Cc: ipfix@ietf.org
> >> Subject: Re: [IPFIX] RE: I-D 
> ACTION:draft-ietf-ipfix-protocol-23.txt
> >>
> >> Yuzhi,
> >>
> >> Ah, yes... after reviewing RFC 3436 section 5, especially on TLS 
> >> session resumption, the language here confuses TLS Sessions and 
> >> Connections; it should read:
> >>
> >>     Though TLS bindings to SCTP are defined in [RFC3436], they
> >>     require all communication to be over reliable, bi-directional 
> >> streams,
> >>     and require one TLS Connection per stream.  This 
> arrangement is 
> >> not
> >>     compatible with the rationale behind the choice of SCTP as an 
> >> IPFIX
> >>     transport protocol.
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> On Oct 20, 2006, at 3:00 AM, Ma Yuzhi wrote:
> >>
> >> > Hi,
> >> >
> >> > Section 11.1 Applicability of TLS and DTLS
> >> >    Though TLS bindings to SCTP are defined in [RFC3436], they
> >> >    require all communication to be over reliable streams,
> >> and require
> >> >    one session per stream.  This arrangement is not 
> compatible with 
> >> > the
> >> >    rationale behind the choice of SCTP as an IPFIX
> >> transport protocol.
> >> >
> >> > RFC3436 Section 5 Connections and Bi-directional Streams
> >> >   TLS makes use of a bi-directional stream by establishing a 
> >> > connection
> >> >    over it.  This means that the number of connections for an
> >> >    association is limited by the number of 
> bi-directional streams.
> >> >
> >> >
> >> > Does "one session per stream" mean  "one TLS session per
> >> SCTP stream"?
> >> > If so, I think the description are unsuitable.
> >> >
> >> > Yuzhi
> >> >
> >> >> -----Original Message-----
> >> >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >> >> Sent: Saturday, October 14, 2006 3:50 AM
> >> >> To: i-d-announce@ietf.org
> >> >> Cc: ipfix@ietf.org
> >> >> Subject: I-D ACTION:draft-ietf-ipfix-protocol-23.txt
> >> >>
> >> >> 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 Protocol
> >> >> for the Exchange of IP Traffic Flow Information
> >> >> 	Author(s)	: B. Claise
> >> >> 	Filename	: draft-ietf-ipfix-protocol-23.txt
> >> >> 	Pages		: 63
> >> >> 	Date		: 2006-10-13
> >> >>
> >> >> This document specifies the IPFIX protocol that serves for
> >> >>    transmitting IP traffic flow information over the network.
> >> >>  In order
> >> >>    to transmit IP traffic flow information from an
> >> exporting process
> >> >> to
> >> >>    an information collecting process, a common
> >> representation of flow
> >> >>    data and a standard means of communicating them is
> >> required. This
> >> >>    document describes how the IPFIX data and templates 
> records are
> >> >>    carried over a number of transport protocols from an IPFIX 
> >> >> exporting
> >> >>    process to an IPFIX collecting process.
> >> >>
> >> >> A URL for this Internet-Draft is:
> >> >>
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-23.txt
> >> >>
> >> >> To remove yourself from the I-D Announcement list, send a
> >> message to
> >> >> i-d-announce-request@ietf.org with the word unsubscribe in
> >> the body
> >> >> of the message.
> >> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> >> >> announce
> >> >> to change your subscription settings.
> >> >>
> >> >> Internet-Drafts are also available by anonymous FTP. Login
> >> with the
> >> >> username "anonymous" and a password of your e-mail 
> address. After 
> >> >> logging in, type "cd internet-drafts" and then "get 
> >> >> draft-ietf-ipfix-protocol-23.txt".
> >> >>
> >> >> A list of Internet-Drafts directories can be found in 
> >> >> http://www.ietf.org/shadow.html or 
> >> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >> >>
> >> >> Internet-Drafts can also be obtained by e-mail.
> >> >>
> >> >> Send a message to:
> >> >> 	mailserv@ietf.org.
> >> >> In the body type:
> >> >> 	"FILE 
> /internet-drafts/draft-ietf-ipfix-protocol-23.txt".
> >> >>
> >> >> NOTE:	The mail server at ietf.org can return the document in
> >> >> 	MIME-encoded form by using the "mpack" utility. 
>  To use this
> >> >> 	feature, insert the command "ENCODING mime" 
> before the "FILE"
> >> >> 	command.  To decode the response(s), you will 
> need "munpack" or
> >> >> 	a MIME-compliant mail reader.  Different MIME-compliant
> >> mail readers
> >> >> 	exhibit different behavior, especially when dealing with
> >> >> 	"multipart" MIME messages (i.e. documents which 
> have been split
> >> >> 	up into multiple messages), so check your local 
> documentation on
> >> >> 	how to manipulate these messages.
> >> >>
> >> >> Below is the data which will enable a MIME compliant 
> mail reader 
> >> >> implementation to automatically retrieve the ASCII 
> version of the 
> >> >> Internet-Draft.
> >> >>
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > IPFIX mailing list
> >> > IPFIX@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/ipfix
> >>
> >> Brian H. Trammell                            +1
> >> 412 268
> >> 9748
> >> Technical Lead, Engineering       CERT Network Situational 
> Awareness
> >> Group
> >> Software Engineering Institute, Carnegie Mellon University, 
> >> Pittsburgh, PA
> >>
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > IPFIX@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipfix
> >
> 
> 
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                 Computer Science Department | ITSS
>    Phone: +64 9 373 7599 x88941           The University of Auckland
>    FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand
> 
> --------------------------------------------------------------
> ---------
> This mail sent through University of Auckland 
> http://www.auckland.ac.nz
> 
> 



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



From ipfix-bounces@ietf.org Tue Oct 24 03:51:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GcH2s-0003dh-P4; Tue, 24 Oct 2006 03:49:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GcH2r-0003cD-24
	for ipfix@ietf.org; Tue, 24 Oct 2006 03:49:57 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcH2p-0003Sh-Ig
	for ipfix@ietf.org; Tue, 24 Oct 2006 03:49:57 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id C4DE42007D5E;
	Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 02947-02; Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id A65A32000292;
	Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 24 Oct 2006 09:49:54 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4F30@mx1.office>
In-Reply-To: <453D0A96.9000105@cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Please post draft-dietz-ipfix-mib-01.txt
Thread-Index: Acb20Y6OBqs6/zFvSx2NTnrqpmDaxAAbzKfw
From: "Thomas Dietz" 
To: "Benoit Claise" 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: ipfix@ietf.org
Subject: [IPFIX] RE: Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1113289862=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1113289862==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0013_01C6F751.C1EC2C50"

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C6F751.C1EC2C50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Benoit,

You are right, but I talked to J=FCrgen and we wanted to have an updated
version for the IETF. The deadline for -00 drafts was over so we decided =
to
update the individual draft and imediately after the IETF submit a new
version as working group draft.

Best Regards,

Thomas

--=20
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
=20

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]=20
> Sent: Monday, October 23, 2006 8:32 PM
> To: Thomas Dietz
> Cc: kobayashi atsushi; ipfix@ietf.org
> Subject: Re: Please post draft-dietz-ipfix-mib-01.txt
>=20
> Thomas,
>=20
> Thanks for your work editing the draft.
> Haven't we agreed that this draft should be a working group item?=20
> Independently of the current open issue on the MIB write-ability.
>=20
> Regards, Benoit.
> > Hi,
> >
> > please publish the following document as Internet Draft:
> >
> >=20
> ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-
> mib-01.txt
> >
> > Please announce the I-D ACTION also to the ipfix mailing list at
> > ipfix@ietf.org
> >
> > Thank you.
> >
> > Thomas
> >
> >  =20
>=20
>=20

------=_NextPart_000_0013_01C6F751.C1EC2C50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDI0MDc0
OTU0WjAjBgkqhkiG9w0BCQQxFgQUS6ropI7tP36QRLqVaTZ6C/SxRwswZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBADSlb/M4LzFJ3RX4J1Q362n0
5VhLHw9U/2O8nO7EvE+cM1iIvYjy6ITQzhtX91V5P2xQClIhijowMxs6oFbk/KnA7G6HwF3X8mrT
ZdZNIPThfDdHU+5Z/7WbRvOU3BuIS80KSncAMlGJmouOtPlHX4mcwhPu/+DUQHQU0RiLZMRKNOl4
r1ZUFQfSZS69tF2dC793L5dXMGAtF5qj1bwVP5szTjw5Rs58U9Jks4zwl63P5oFZ3Ul0iA47r6/Y
oTXYVafp//pi1COudxOmJdZuwuxQlagIr1hEZFI5OIBd4meufT+g/mm4vWsmsz16djPdOG+tKJcB
nbBGu6pyKLbKDLgAAAAAAAA=

------=_NextPart_000_0013_01C6F751.C1EC2C50--


--===============1113289862==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1113289862==--




From ipfix-bounces@ietf.org Tue Oct 24 03:51:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GcH2s-0003dh-P4; Tue, 24 Oct 2006 03:49:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GcH2r-0003cD-24
	for ipfix@ietf.org; Tue, 24 Oct 2006 03:49:57 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcH2p-0003Sh-Ig
	for ipfix@ietf.org; Tue, 24 Oct 2006 03:49:57 -0400
Received: from localhost (localhost.office [127.0.0.1])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id C4DE42007D5E;
	Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1])
	by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 02947-02; Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id A65A32000292;
	Tue, 24 Oct 2006 09:50:25 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 24 Oct 2006 09:49:54 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6963A4F30@mx1.office>
In-Reply-To: <453D0A96.9000105@cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Please post draft-dietz-ipfix-mib-01.txt
Thread-Index: Acb20Y6OBqs6/zFvSx2NTnrqpmDaxAAbzKfw
From: "Thomas Dietz" 
To: "Benoit Claise" 
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: ipfix@ietf.org
Subject: [IPFIX] RE: Please post draft-dietz-ipfix-mib-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1113289862=="
Errors-To: ipfix-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1113289862==
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0013_01C6F751.C1EC2C50"

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C6F751.C1EC2C50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Benoit,

You are right, but I talked to J=FCrgen and we wanted to have an updated
version for the IETF. The deadline for -00 drafts was over so we decided =
to
update the individual draft and imediately after the IETF submit a new
version as working group draft.

Best Regards,

Thomas

--=20
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
=20

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]=20
> Sent: Monday, October 23, 2006 8:32 PM
> To: Thomas Dietz
> Cc: kobayashi atsushi; ipfix@ietf.org
> Subject: Re: Please post draft-dietz-ipfix-mib-01.txt
>=20
> Thomas,
>=20
> Thanks for your work editing the draft.
> Haven't we agreed that this draft should be a working group item?=20
> Independently of the current open issue on the MIB write-ability.
>=20
> Regards, Benoit.
> > Hi,
> >
> > please publish the following document as Internet Draft:
> >
> >=20
> ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-dietz-ipfix-
> mib-01.txt
> >
> > Please announce the I-D ACTION also to the ipfix mailing list at
> > ipfix@ietf.org
> >
> > Thank you.
> >
> > Thomas
> >
> >  =20
>=20
>=20

------=_NextPart_000_0013_01C6F751.C1EC2C50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw
ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy
NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp
ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b
fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn
OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB
OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw
vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3
MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4
vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/
jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDI0MDc0
OTU0WjAjBgkqhkiG9w0BCQQxFgQUS6ropI7tP36QRLqVaTZ6C/SxRwswZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBADSlb/M4LzFJ3RX4J1Q362n0
5VhLHw9U/2O8nO7EvE+cM1iIvYjy6ITQzhtX91V5P2xQClIhijowMxs6oFbk/KnA7G6HwF3X8mrT
ZdZNIPThfDdHU+5Z/7WbRvOU3BuIS80KSncAMlGJmouOtPlHX4mcwhPu/+DUQHQU0RiLZMRKNOl4
r1ZUFQfSZS69tF2dC793L5dXMGAtF5qj1bwVP5szTjw5Rs58U9Jks4zwl63P5oFZ3Ul0iA47r6/Y
oTXYVafp//pi1COudxOmJdZuwuxQlagIr1hEZFI5OIBd4meufT+g/mm4vWsmsz16djPdOG+tKJcB
nbBGu6pyKLbKDLgAAAAAAAA=

------=_NextPart_000_0013_01C6F751.C1EC2C50--


--===============1113289862==
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://www1.ietf.org/mailman/listinfo/ipfix

--===============1113289862==--




From ipfix-bounces@ietf.org Wed Oct 25 03:09:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GccrE-0001MQ-Lq; Wed, 25 Oct 2006 03:07:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GccrD-0001MD-Dm
	for ipfix@ietf.org; Wed, 25 Oct 2006 03:07:23 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GccrB-000141-W3
	for ipfix@ietf.org; Wed, 25 Oct 2006 03:07:23 -0400
Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 505C91BAC4D
	for ; Wed, 25 Oct 2006 09:07:21 +0200 (CEST)
Date: Wed, 25 Oct 2006 09:07:17 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Message-ID: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Subject: [IPFIX] draft agenda for San Diego
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Below find a draft agenda for our meeting in San Diego.

Comments are welcome.

Thanks,

    Juergen

=====================================
IP Flow Information Export WG (ipfix)
IETF 67, San Diego
Thursday November 9 at 1300-1500
=====================================

Chairs:
Nevil Brownlee  
Juergen Quittek 

Agenda:

 1) Agenda review WG Status                              ( 5 min)

 2) Documents from the old charter (Juergen)             (20 min)
    - draft-ietf-ipfix-architecture-12.txt
    - draft-ietf-ipfix-protocol-23.txt
    - draft-ietf-ipfix-info-14.txt
    - draft-ietf-ipfix-as-10.txt

 3) Implementation Guidelines (Elisa Boschi)             (15 min)
    - draft-ietf-ipfix-implementation-guidelines-01.txt

 4) IPFIX Testing (Carten Schmoll)                       (10 min)
    - draft-ietf-ipfix-testing-00.txt

 5) Reducing Redundancy (Elisa Boschi)                   (15 min)
    - draft-ietf-ipfix-reducing-redundancy-00.txt

 6) IPFIX MIB (Thomas Dietz)                             (20 min)
    - draft-dietz-ipfix-mib-01.txt

 7) Bidirectional Flow Export (Brian Trammell)           (10 min)
    - draft-ietf-ipfix-biflow-00.txt

 4) New drafts                                           (20 min)
    - Order of Information Elements (Hitoshi Irino)
      draft-irino-ipfix-ie-order-00.txt
    - IPFIX Mediator (Atsushi Kobayashi)
      draft-kobayashi-ipfix-mediator-00.txt

 5) wrap up, milestone review                            ( 5 min)


Presentation slides will be available at
 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
 (search for IPFIX in the Operations and Management Area)

Participation via jabber is offered at ipfix@jabber.ietf.org


FURTHER RELATED DRAFTS:

An IPFIX-Based File Format
http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt

IPFIX Configuration Data Model
http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt

IPFIX Aggregation
http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-03.txt



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



From ipfix-bounces@ietf.org Wed Oct 25 03:09:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GccrE-0001MQ-Lq; Wed, 25 Oct 2006 03:07:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GccrD-0001MD-Dm
	for ipfix@ietf.org; Wed, 25 Oct 2006 03:07:23 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GccrB-000141-W3
	for ipfix@ietf.org; Wed, 25 Oct 2006 03:07:23 -0400
Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 505C91BAC4D
	for ; Wed, 25 Oct 2006 09:07:21 +0200 (CEST)
Date: Wed, 25 Oct 2006 09:07:17 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Message-ID: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Subject: [IPFIX] draft agenda for San Diego
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Below find a draft agenda for our meeting in San Diego.

Comments are welcome.

Thanks,

    Juergen

=====================================
IP Flow Information Export WG (ipfix)
IETF 67, San Diego
Thursday November 9 at 1300-1500
=====================================

Chairs:
Nevil Brownlee  
Juergen Quittek 

Agenda:

 1) Agenda review WG Status                              ( 5 min)

 2) Documents from the old charter (Juergen)             (20 min)
    - draft-ietf-ipfix-architecture-12.txt
    - draft-ietf-ipfix-protocol-23.txt
    - draft-ietf-ipfix-info-14.txt
    - draft-ietf-ipfix-as-10.txt

 3) Implementation Guidelines (Elisa Boschi)             (15 min)
    - draft-ietf-ipfix-implementation-guidelines-01.txt

 4) IPFIX Testing (Carten Schmoll)                       (10 min)
    - draft-ietf-ipfix-testing-00.txt

 5) Reducing Redundancy (Elisa Boschi)                   (15 min)
    - draft-ietf-ipfix-reducing-redundancy-00.txt

 6) IPFIX MIB (Thomas Dietz)                             (20 min)
    - draft-dietz-ipfix-mib-01.txt

 7) Bidirectional Flow Export (Brian Trammell)           (10 min)
    - draft-ietf-ipfix-biflow-00.txt

 4) New drafts                                           (20 min)
    - Order of Information Elements (Hitoshi Irino)
      draft-irino-ipfix-ie-order-00.txt
    - IPFIX Mediator (Atsushi Kobayashi)
      draft-kobayashi-ipfix-mediator-00.txt

 5) wrap up, milestone review                            ( 5 min)


Presentation slides will be available at
 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
 (search for IPFIX in the Operations and Management Area)

Participation via jabber is offered at ipfix@jabber.ietf.org


FURTHER RELATED DRAFTS:

An IPFIX-Based File Format
http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt

IPFIX Configuration Data Model
http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt

IPFIX Aggregation
http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-03.txt



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



From ipfix-bounces@ietf.org Wed Oct 25 11:57:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcl6Q-000763-U6; Wed, 25 Oct 2006 11:55:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcl6P-00075y-FW
	for ipfix@ietf.org; Wed, 25 Oct 2006 11:55:37 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcl6K-0004rN-Uh
	for ipfix@ietf.org; Wed, 25 Oct 2006 11:55:37 -0400
Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id C9DE81BAC4D
	for ; Wed, 25 Oct 2006 17:55:29 +0200 (CEST)
Date: Wed, 25 Oct 2006 17:55:26 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Subject: Re: [IPFIX] draft agenda for San Diego
Message-ID: <5BEF334D5E5D24F12009A344@[10.1.1.104]>
In-Reply-To: 
References: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

After receiving feedback, I updated the draft agenda.

Please find the current version at



Thanks,

    Juergen


--On 25.10.2006 9:07 Uhr +0200 Juergen Quittek wrote:

> Dear all,
>
> Below find a draft agenda for our meeting in San Diego.
>
> Comments are welcome.
>
> Thanks,
>
>     Juergen
>
> =====================================
> IP Flow Information Export WG (ipfix)
> IETF 67, San Diego
> Thursday November 9 at 1300-1500
> =====================================
>
> Chairs:
> Nevil Brownlee  
> Juergen Quittek 
>
> Agenda:
>
>  1) Agenda review WG Status                              ( 5 min)
>
>  2) Documents from the old charter (Juergen)             (20 min)
>     - draft-ietf-ipfix-architecture-12.txt
>     - draft-ietf-ipfix-protocol-23.txt
>     - draft-ietf-ipfix-info-14.txt
>     - draft-ietf-ipfix-as-10.txt
>
>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>     - draft-ietf-ipfix-implementation-guidelines-01.txt
>
>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>     - draft-ietf-ipfix-testing-00.txt
>
>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>     - draft-ietf-ipfix-reducing-redundancy-00.txt
>
>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>     - draft-dietz-ipfix-mib-01.txt
>
>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>     - draft-ietf-ipfix-biflow-00.txt
>
>  4) New drafts                                           (20 min)
>     - Order of Information Elements (Hitoshi Irino)
>       draft-irino-ipfix-ie-order-00.txt
>     - IPFIX Mediator (Atsushi Kobayashi)
>       draft-kobayashi-ipfix-mediator-00.txt
>
>  5) wrap up, milestone review                            ( 5 min)
>
>
> Presentation slides will be available at
>  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
>  (search for IPFIX in the Operations and Management Area)
>
> Participation via jabber is offered at ipfix@jabber.ietf.org
>
>
> FURTHER RELATED DRAFTS:
>
> An IPFIX-Based File Format
> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
>
> IPFIX Configuration Data Model
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt
>
> IPFIX Aggregation
> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-03.txt
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Wed Oct 25 11:57:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcl6Q-000763-U6; Wed, 25 Oct 2006 11:55:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcl6P-00075y-FW
	for ipfix@ietf.org; Wed, 25 Oct 2006 11:55:37 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcl6K-0004rN-Uh
	for ipfix@ietf.org; Wed, 25 Oct 2006 11:55:37 -0400
Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id C9DE81BAC4D
	for ; Wed, 25 Oct 2006 17:55:29 +0200 (CEST)
Date: Wed, 25 Oct 2006 17:55:26 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Subject: Re: [IPFIX] draft agenda for San Diego
Message-ID: <5BEF334D5E5D24F12009A344@[10.1.1.104]>
In-Reply-To: 
References: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

After receiving feedback, I updated the draft agenda.

Please find the current version at



Thanks,

    Juergen


--On 25.10.2006 9:07 Uhr +0200 Juergen Quittek wrote:

> Dear all,
>
> Below find a draft agenda for our meeting in San Diego.
>
> Comments are welcome.
>
> Thanks,
>
>     Juergen
>
> =====================================
> IP Flow Information Export WG (ipfix)
> IETF 67, San Diego
> Thursday November 9 at 1300-1500
> =====================================
>
> Chairs:
> Nevil Brownlee  
> Juergen Quittek 
>
> Agenda:
>
>  1) Agenda review WG Status                              ( 5 min)
>
>  2) Documents from the old charter (Juergen)             (20 min)
>     - draft-ietf-ipfix-architecture-12.txt
>     - draft-ietf-ipfix-protocol-23.txt
>     - draft-ietf-ipfix-info-14.txt
>     - draft-ietf-ipfix-as-10.txt
>
>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>     - draft-ietf-ipfix-implementation-guidelines-01.txt
>
>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>     - draft-ietf-ipfix-testing-00.txt
>
>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>     - draft-ietf-ipfix-reducing-redundancy-00.txt
>
>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>     - draft-dietz-ipfix-mib-01.txt
>
>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>     - draft-ietf-ipfix-biflow-00.txt
>
>  4) New drafts                                           (20 min)
>     - Order of Information Elements (Hitoshi Irino)
>       draft-irino-ipfix-ie-order-00.txt
>     - IPFIX Mediator (Atsushi Kobayashi)
>       draft-kobayashi-ipfix-mediator-00.txt
>
>  5) wrap up, milestone review                            ( 5 min)
>
>
> Presentation slides will be available at
>  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
>  (search for IPFIX in the Operations and Management Area)
>
> Participation via jabber is offered at ipfix@jabber.ietf.org
>
>
> FURTHER RELATED DRAFTS:
>
> An IPFIX-Based File Format
> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
>
> IPFIX Configuration Data Model
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt
>
> IPFIX Aggregation
> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-03.txt
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix



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



From ipfix-bounces@ietf.org Wed Oct 25 12:58:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcm4J-0008Jr-FD; Wed, 25 Oct 2006 12:57:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm4I-0008Jm-QY
	for ipfix@ietf.org; Wed, 25 Oct 2006 12:57:30 -0400
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcm4E-0001OT-Hb
	for ipfix@ietf.org; Wed, 25 Oct 2006 12:57:30 -0400
Received: from harrington73653 (unknown[83.71.141.73])
	by comcast.net (sccrmhc13) with SMTP
	id <2006102516572501300h6b1de>; Wed, 25 Oct 2006 16:57:26 +0000
From: "David Harrington" 
To: "'Juergen Quittek'" 
Subject: RE: [IPFIX] draft agenda for San Diego
Date: Wed, 25 Oct 2006 17:54:55 +0100
Message-ID: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: Acb4BIHtjDsoXrBbTW2FOXUCbdPXCQAQkqCQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Juergen,

Will you be discussing a secure transport solution?

dbh 

> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@netlab.nec.de] 
> Sent: Wednesday, October 25, 2006 8:07 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] draft agenda for San Diego
> 
> Dear all,
> 
> Below find a draft agenda for our meeting in San Diego.
> 
> Comments are welcome.
> 
> Thanks,
> 
>     Juergen
> 
> =====================================
> IP Flow Information Export WG (ipfix)
> IETF 67, San Diego
> Thursday November 9 at 1300-1500
> =====================================
> 
> Chairs:
> Nevil Brownlee  
> Juergen Quittek 
> 
> Agenda:
> 
>  1) Agenda review WG Status                              ( 5 min)
> 
>  2) Documents from the old charter (Juergen)             (20 min)
>     - draft-ietf-ipfix-architecture-12.txt
>     - draft-ietf-ipfix-protocol-23.txt
>     - draft-ietf-ipfix-info-14.txt
>     - draft-ietf-ipfix-as-10.txt
> 
>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>     - draft-ietf-ipfix-implementation-guidelines-01.txt
> 
>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>     - draft-ietf-ipfix-testing-00.txt
> 
>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>     - draft-ietf-ipfix-reducing-redundancy-00.txt
> 
>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>     - draft-dietz-ipfix-mib-01.txt
> 
>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>     - draft-ietf-ipfix-biflow-00.txt
> 
>  4) New drafts                                           (20 min)
>     - Order of Information Elements (Hitoshi Irino)
>       draft-irino-ipfix-ie-order-00.txt
>     - IPFIX Mediator (Atsushi Kobayashi)
>       draft-kobayashi-ipfix-mediator-00.txt
> 
>  5) wrap up, milestone review                            ( 5 min)
> 
> 
> Presentation slides will be available at
>  
> https://datatracker.ietf.org/public/meeting_materials.cgi?meet
> ing_num=67
>  (search for IPFIX in the Operations and Management Area)
> 
> Participation via jabber is offered at ipfix@jabber.ietf.org
> 
> 
> FURTHER RELATED DRAFTS:
> 
> An IPFIX-Based File Format
> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
> 
> IPFIX Configuration Data Model
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
> ation-00.txt
> 
> IPFIX Aggregation
> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggre
> gation-03.txt
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
> 



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



From ipfix-bounces@ietf.org Wed Oct 25 12:58:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcm4J-0008Jr-FD; Wed, 25 Oct 2006 12:57:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm4I-0008Jm-QY
	for ipfix@ietf.org; Wed, 25 Oct 2006 12:57:30 -0400
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcm4E-0001OT-Hb
	for ipfix@ietf.org; Wed, 25 Oct 2006 12:57:30 -0400
Received: from harrington73653 (unknown[83.71.141.73])
	by comcast.net (sccrmhc13) with SMTP
	id <2006102516572501300h6b1de>; Wed, 25 Oct 2006 16:57:26 +0000
From: "David Harrington" 
To: "'Juergen Quittek'" 
Subject: RE: [IPFIX] draft agenda for San Diego
Date: Wed, 25 Oct 2006 17:54:55 +0100
Message-ID: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: Acb4BIHtjDsoXrBbTW2FOXUCbdPXCQAQkqCQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi Juergen,

Will you be discussing a secure transport solution?

dbh 

> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@netlab.nec.de] 
> Sent: Wednesday, October 25, 2006 8:07 AM
> To: ipfix@ietf.org
> Subject: [IPFIX] draft agenda for San Diego
> 
> Dear all,
> 
> Below find a draft agenda for our meeting in San Diego.
> 
> Comments are welcome.
> 
> Thanks,
> 
>     Juergen
> 
> =====================================
> IP Flow Information Export WG (ipfix)
> IETF 67, San Diego
> Thursday November 9 at 1300-1500
> =====================================
> 
> Chairs:
> Nevil Brownlee  
> Juergen Quittek 
> 
> Agenda:
> 
>  1) Agenda review WG Status                              ( 5 min)
> 
>  2) Documents from the old charter (Juergen)             (20 min)
>     - draft-ietf-ipfix-architecture-12.txt
>     - draft-ietf-ipfix-protocol-23.txt
>     - draft-ietf-ipfix-info-14.txt
>     - draft-ietf-ipfix-as-10.txt
> 
>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>     - draft-ietf-ipfix-implementation-guidelines-01.txt
> 
>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>     - draft-ietf-ipfix-testing-00.txt
> 
>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>     - draft-ietf-ipfix-reducing-redundancy-00.txt
> 
>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>     - draft-dietz-ipfix-mib-01.txt
> 
>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>     - draft-ietf-ipfix-biflow-00.txt
> 
>  4) New drafts                                           (20 min)
>     - Order of Information Elements (Hitoshi Irino)
>       draft-irino-ipfix-ie-order-00.txt
>     - IPFIX Mediator (Atsushi Kobayashi)
>       draft-kobayashi-ipfix-mediator-00.txt
> 
>  5) wrap up, milestone review                            ( 5 min)
> 
> 
> Presentation slides will be available at
>  
> https://datatracker.ietf.org/public/meeting_materials.cgi?meet
> ing_num=67
>  (search for IPFIX in the Operations and Management Area)
> 
> Participation via jabber is offered at ipfix@jabber.ietf.org
> 
> 
> FURTHER RELATED DRAFTS:
> 
> An IPFIX-Based File Format
> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
> 
> IPFIX Configuration Data Model
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
> ation-00.txt
> 
> IPFIX Aggregation
> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggre
> gation-03.txt
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
> 



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



From ipfix-bounces@ietf.org Wed Oct 25 15:09:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gco6j-00030m-8b; Wed, 25 Oct 2006 15:08:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco6i-00030h-GD
	for ipfix@ietf.org; Wed, 25 Oct 2006 15:08:08 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco6g-0000dM-0F
	for ipfix@ietf.org; Wed, 25 Oct 2006 15:08:08 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 24D021BAC4D;
	Wed, 25 Oct 2006 21:08:03 +0200 (CEST)
Date: Wed, 25 Oct 2006 21:07:53 +0200
From: Juergen Quittek 
To: David Harrington 
Subject: RE: [IPFIX] draft agenda for San Diego
Message-ID: 
In-Reply-To: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
References: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi David,

After IETF last call we had long discussions with the
transport and security ADs how to achieve a non-TCP
congestion-aware secure solution.  At some times this
seemed to be impossible, but finally security AD Sam
Hartman made a suggestions that meets transport
constraints as well as security constraints.
It is described in version -23 of the protocol draft
that Benoit submitted two weeks ago and that is now
subject of IESG last call.

So, the answer is no.  But we will summarize this story
again at the beginning of the session in the overview
of drafts belonging to our old charter.

Thanks,

    Juergen


--On 25.10.2006 17:54 Uhr +0100 David Harrington wrote:

> Hi Juergen,
>
> Will you be discussing a secure transport solution?
>
> dbh
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@netlab.nec.de]
>> Sent: Wednesday, October 25, 2006 8:07 AM
>> To: ipfix@ietf.org
>> Subject: [IPFIX] draft agenda for San Diego
>>
>> Dear all,
>>
>> Below find a draft agenda for our meeting in San Diego.
>>
>> Comments are welcome.
>>
>> Thanks,
>>
>>     Juergen
>>
>> =====================================
>> IP Flow Information Export WG (ipfix)
>> IETF 67, San Diego
>> Thursday November 9 at 1300-1500
>> =====================================
>>
>> Chairs:
>> Nevil Brownlee  
>> Juergen Quittek 
>>
>> Agenda:
>>
>>  1) Agenda review WG Status                              ( 5 min)
>>
>>  2) Documents from the old charter (Juergen)             (20 min)
>>     - draft-ietf-ipfix-architecture-12.txt
>>     - draft-ietf-ipfix-protocol-23.txt
>>     - draft-ietf-ipfix-info-14.txt
>>     - draft-ietf-ipfix-as-10.txt
>>
>>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>>     - draft-ietf-ipfix-implementation-guidelines-01.txt
>>
>>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>>     - draft-ietf-ipfix-testing-00.txt
>>
>>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>>     - draft-ietf-ipfix-reducing-redundancy-00.txt
>>
>>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>>     - draft-dietz-ipfix-mib-01.txt
>>
>>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>>     - draft-ietf-ipfix-biflow-00.txt
>>
>>  4) New drafts                                           (20 min)
>>     - Order of Information Elements (Hitoshi Irino)
>>       draft-irino-ipfix-ie-order-00.txt
>>     - IPFIX Mediator (Atsushi Kobayashi)
>>       draft-kobayashi-ipfix-mediator-00.txt
>>
>>  5) wrap up, milestone review                            ( 5 min)
>>
>>
>> Presentation slides will be available at
>>
>> https://datatracker.ietf.org/public/meeting_materials.cgi?meet
>> ing_num=67
>>  (search for IPFIX in the Operations and Management Area)
>>
>> Participation via jabber is offered at ipfix@jabber.ietf.org
>>
>>
>> FURTHER RELATED DRAFTS:
>>
>> An IPFIX-Based File Format
>> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
>>
>> IPFIX Configuration Data Model
>> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
>> ation-00.txt
>>
>> IPFIX Aggregation
>> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggre
>> gation-03.txt
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>
>
>



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



From ipfix-bounces@ietf.org Wed Oct 25 15:09:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gco6j-00030m-8b; Wed, 25 Oct 2006 15:08:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco6i-00030h-GD
	for ipfix@ietf.org; Wed, 25 Oct 2006 15:08:08 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco6g-0000dM-0F
	for ipfix@ietf.org; Wed, 25 Oct 2006 15:08:08 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 24D021BAC4D;
	Wed, 25 Oct 2006 21:08:03 +0200 (CEST)
Date: Wed, 25 Oct 2006 21:07:53 +0200
From: Juergen Quittek 
To: David Harrington 
Subject: RE: [IPFIX] draft agenda for San Diego
Message-ID: 
In-Reply-To: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
References: <014601c6f856$4fe34c50$22021eac@china.huawei.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hi David,

After IETF last call we had long discussions with the
transport and security ADs how to achieve a non-TCP
congestion-aware secure solution.  At some times this
seemed to be impossible, but finally security AD Sam
Hartman made a suggestions that meets transport
constraints as well as security constraints.
It is described in version -23 of the protocol draft
that Benoit submitted two weeks ago and that is now
subject of IESG last call.

So, the answer is no.  But we will summarize this story
again at the beginning of the session in the overview
of drafts belonging to our old charter.

Thanks,

    Juergen


--On 25.10.2006 17:54 Uhr +0100 David Harrington wrote:

> Hi Juergen,
>
> Will you be discussing a secure transport solution?
>
> dbh
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@netlab.nec.de]
>> Sent: Wednesday, October 25, 2006 8:07 AM
>> To: ipfix@ietf.org
>> Subject: [IPFIX] draft agenda for San Diego
>>
>> Dear all,
>>
>> Below find a draft agenda for our meeting in San Diego.
>>
>> Comments are welcome.
>>
>> Thanks,
>>
>>     Juergen
>>
>> =====================================
>> IP Flow Information Export WG (ipfix)
>> IETF 67, San Diego
>> Thursday November 9 at 1300-1500
>> =====================================
>>
>> Chairs:
>> Nevil Brownlee  
>> Juergen Quittek 
>>
>> Agenda:
>>
>>  1) Agenda review WG Status                              ( 5 min)
>>
>>  2) Documents from the old charter (Juergen)             (20 min)
>>     - draft-ietf-ipfix-architecture-12.txt
>>     - draft-ietf-ipfix-protocol-23.txt
>>     - draft-ietf-ipfix-info-14.txt
>>     - draft-ietf-ipfix-as-10.txt
>>
>>  3) Implementation Guidelines (Elisa Boschi)             (15 min)
>>     - draft-ietf-ipfix-implementation-guidelines-01.txt
>>
>>  4) IPFIX Testing (Carten Schmoll)                       (10 min)
>>     - draft-ietf-ipfix-testing-00.txt
>>
>>  5) Reducing Redundancy (Elisa Boschi)                   (15 min)
>>     - draft-ietf-ipfix-reducing-redundancy-00.txt
>>
>>  6) IPFIX MIB (Thomas Dietz)                             (20 min)
>>     - draft-dietz-ipfix-mib-01.txt
>>
>>  7) Bidirectional Flow Export (Brian Trammell)           (10 min)
>>     - draft-ietf-ipfix-biflow-00.txt
>>
>>  4) New drafts                                           (20 min)
>>     - Order of Information Elements (Hitoshi Irino)
>>       draft-irino-ipfix-ie-order-00.txt
>>     - IPFIX Mediator (Atsushi Kobayashi)
>>       draft-kobayashi-ipfix-mediator-00.txt
>>
>>  5) wrap up, milestone review                            ( 5 min)
>>
>>
>> Presentation slides will be available at
>>
>> https://datatracker.ietf.org/public/meeting_materials.cgi?meet
>> ing_num=67
>>  (search for IPFIX in the Operations and Management Area)
>>
>> Participation via jabber is offered at ipfix@jabber.ietf.org
>>
>>
>> FURTHER RELATED DRAFTS:
>>
>> An IPFIX-Based File Format
>> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-02.txt
>>
>> IPFIX Configuration Data Model
>> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
>> ation-00.txt
>>
>> IPFIX Aggregation
>> http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggre
>> gation-03.txt
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>
>
>



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



From ghasdfsdvfsadf@hotmail.com Thu Oct 26 02:19:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcyap-0003f2-Ef
	for ipfix-archive@megatron.ietf.org; Thu, 26 Oct 2006 02:19:55 -0400
Received: from [210.48.151.229] (helo=pc09)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Gcyan-0005tu-HE
	for ipfix-archive@megatron.ietf.org; Thu, 26 Oct 2006 02:19:55 -0400
To: 
From: =?iso-2022-jp?B?GyRCOzMyPCEhOWFKZhsoQg==?=
Subject: =?iso-2022-jp?B?GyRCR1I3PCEhISEbKEJpcGZpeC1hcmNoaXZlGyRCTU0bKEI=?=
MIME-Version: 1.0
Reply-To: 
Date: Thu, 26 Oct 2006 10:15:03 +0900
Content-Type:text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6


$B!!(B  $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
                                                                
$B!!(B  $BL4$OC/$7$b$*;}$A$G$7$g$&$,(B                                   
$B!!(B                                                              $B!!(B
$B!!(B  $B!!(B    $B$=$NL4$ru$G$9!#$5$i$KL4$re$GEj;q$r$7$F$/$l$k$H8@$&?M$,8=$l(B

$B!!$?$i5.J}$O$I$&$5$l$^$9$+!)??$C@h$Ko$KJz$-B3$1$F$$$k?M$XBg$$$K$=(B

$B!!$NJ}!9$XOC$7$F$_$F2<$5$$!#I,$:?F?H$K$J$C$FJ9$$$F$/$l$^$9$7!"=u$1$H(B

$B!!$J$j6(NO
Date: Thu, 26 Oct 2006 02:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-reducing-redundancy-01.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: Reducing redundancy in IPFIX and PSAMP reports
	Author(s)	: E. Boschi, et al.
	Filename	: draft-ietf-ipfix-reducing-redundancy-01.txt
	Pages		: 35
	Date		: 2006-10-25
	
This document describes a bandwidth saving method for exporting flow 
   or packet information using the IP Flow Information Export (IPFIX) 
   protocol.  As the PSAMP protocol is based on IPFIX, these 
   considerations are valid for PSAMP exports as well. 
    
   This method works by separating information common to several flow 
   records from information specific to an individual flow record.  
   Common flow information is exported only once in a data record 
   defined by an option template, while the rest of the specific flow 
   information is associated with the common information via a unique 
   identifier.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-reducing-redundancy-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-25223144.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-reducing-redundancy-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-25223144.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 02:51:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcz4t-0001HD-1Y; Thu, 26 Oct 2006 02:50:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gcz4U-0000oY-12; Thu, 26 Oct 2006 02:50:34 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gcz4T-0002NU-Vb; Thu, 26 Oct 2006 02:50:34 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Gcz4T-0008Ji-5w; Thu, 26 Oct 2006 02:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D3ECD175D0;
	Thu, 26 Oct 2006 06:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Gcz3y-000233-Bq; Thu, 26 Oct 2006 02:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 26 Oct 2006 02:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-reducing-redundancy-01.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: Reducing redundancy in IPFIX and PSAMP reports
	Author(s)	: E. Boschi, et al.
	Filename	: draft-ietf-ipfix-reducing-redundancy-01.txt
	Pages		: 35
	Date		: 2006-10-25
	
This document describes a bandwidth saving method for exporting flow 
   or packet information using the IP Flow Information Export (IPFIX) 
   protocol.  As the PSAMP protocol is based on IPFIX, these 
   considerations are valid for PSAMP exports as well. 
    
   This method works by separating information common to several flow 
   records from information specific to an individual flow record.  
   Common flow information is exported only once in a data record 
   defined by an option template, while the rest of the specific flow 
   information is associated with the common information via a unique 
   identifier.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-reducing-redundancy-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-25223144.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-reducing-redundancy-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-reducing-redundancy-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-25223144.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 11:20:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gd70k-00051D-6w; Thu, 26 Oct 2006 11:19:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd70W-0004oh-MW
	for ipfix@ietf.org; Thu, 26 Oct 2006 11:19:00 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6my-0002aL-HB
	for ipfix@ietf.org; Thu, 26 Oct 2006 11:05:05 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9QF4s9g010233 for ; Thu, 26 Oct 2006 11:04:54 -0400
Received: from [128.237.249.220] (vpn-10-25-4-23.remote.cert.org [10.25.4.23])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9QF4sWb023119
	for ; Thu, 26 Oct 2006 11:04:54 -0400
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <3A4FD555-3F8A-41C3-9279-96E06633CE18@cert.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: ipfix@ietf.org
From: Brian Trammell 
Date: Thu, 26 Oct 2006 11:04:19 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Subject: [IPFIX] Fwd: I-D ACTION:draft-trammell-ipfix-file-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Greetings, all,

A new revision of the file draft presented at IETF 65 in Dallas and  
IETF 66 in Montreal is now available. This revision of the draft  
continues the development of a file format based on IPFIX as we  
outlined in our presentation in Montreal: we have expanded on the  
requirements identified in collaboration with operational users of a  
variety of large-scale flow storage systems, and started the process  
of addressing those requirements using the IPFIX Message format  
without changes to the protocol in keeping with the restrictions of  
the present charter.

This revision of the draft does not yet present a complete  
specification of the file format; it is intended to continue the  
discussion on the community's need for a standard flow storage format  
and the requirements we've identified.

Regards,

Brian

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: An IPFIX-Based File Format
> 	Author(s)	: B. Trammell, et al.
> 	Filename	: draft-trammell-ipfix-file-02.txt
> 	Pages		: 24
> 	Date		: 2006-10-22
> 	
> This document describes a file format for the storage of flow data
>    based upon the IPFIX message format.  It proposes a set of
>    requirements for flat-file, binary flow data file formats,  
> evaluates
>    flow storage systems presently in use for their conformance to  
> these
>    requirements, then applies the IPFIX message format to these
>    requirements to build a new file format.  This IPFIX-based 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-trammell-ipfix-file-02.txt
>

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



From ipfix-bounces@ietf.org Thu Oct 26 11:20:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gd70k-00051D-6w; Thu, 26 Oct 2006 11:19:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd70W-0004oh-MW
	for ipfix@ietf.org; Thu, 26 Oct 2006 11:19:00 -0400
Received: from beniaminus.red.cert.org ([192.88.209.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6my-0002aL-HB
	for ipfix@ietf.org; Thu, 26 Oct 2006 11:05:05 -0400
Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])
	by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id
	k9QF4s9g010233 for ; Thu, 26 Oct 2006 11:04:54 -0400
Received: from [128.237.249.220] (vpn-10-25-4-23.remote.cert.org [10.25.4.23])
	by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with
	ESMTP id k9QF4sWb023119
	for ; Thu, 26 Oct 2006 11:04:54 -0400
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <3A4FD555-3F8A-41C3-9279-96E06633CE18@cert.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: ipfix@ietf.org
From: Brian Trammell 
Date: Thu, 26 Oct 2006 11:04:19 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Subject: [IPFIX] Fwd: I-D ACTION:draft-trammell-ipfix-file-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Greetings, all,

A new revision of the file draft presented at IETF 65 in Dallas and  
IETF 66 in Montreal is now available. This revision of the draft  
continues the development of a file format based on IPFIX as we  
outlined in our presentation in Montreal: we have expanded on the  
requirements identified in collaboration with operational users of a  
variety of large-scale flow storage systems, and started the process  
of addressing those requirements using the IPFIX Message format  
without changes to the protocol in keeping with the restrictions of  
the present charter.

This revision of the draft does not yet present a complete  
specification of the file format; it is intended to continue the  
discussion on the community's need for a standard flow storage format  
and the requirements we've identified.

Regards,

Brian

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: An IPFIX-Based File Format
> 	Author(s)	: B. Trammell, et al.
> 	Filename	: draft-trammell-ipfix-file-02.txt
> 	Pages		: 24
> 	Date		: 2006-10-22
> 	
> This document describes a file format for the storage of flow data
>    based upon the IPFIX message format.  It proposes a set of
>    requirements for flat-file, binary flow data file formats,  
> evaluates
>    flow storage systems presently in use for their conformance to  
> these
>    requirements, then applies the IPFIX message format to these
>    requirements to build a new file format.  This IPFIX-based 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-trammell-ipfix-file-02.txt
>

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



From ipfix-bounces@ietf.org Thu Oct 26 16:00:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBNe-0002Vm-S2; Thu, 26 Oct 2006 15:59:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBMt-00021x-7I; Thu, 26 Oct 2006 15:58:23 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GdBFt-0007Ji-1m; Thu, 26 Oct 2006 15:51:09 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GdBFs-0005xe-HU; Thu, 26 Oct 2006 15:51:08 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 460052AD37;
	Thu, 26 Oct 2006 19:50:08 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GdBEu-0005KH-0N; Thu, 26 Oct 2006 15:50:08 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 26 Oct 2006 15:50:08 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-implementation-guidelines-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: IPFIX Implementation Guidelines
	Author(s)	: E. Boschi, et al.
	Filename	: draft-ietf-ipfix-implementation-guidelines-01.txt
	Pages		: 33
	Date		: 2006-10-26
	
The IP Flow Information eXport (IPFIX) protocol defines how IP Flow 
   information can be exported from routers, measurement probes or 
   other devices. This document provides guidelines for the 
   implementation and use of the IPFIX protocol. Several sets of 
   guidelines address template management, transport-specific issues, 
   implementation of exporting and collecting processes and IPFIX 
   implementation on middleboxes (such as firewalls, network address 
   translators, tunnel endpoints, packet classifiers, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-implementation-guidelines-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-26114444.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-implementation-guidelines-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-26114444.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 16:00:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBNe-0002Vm-S2; Thu, 26 Oct 2006 15:59:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBMt-00021x-7I; Thu, 26 Oct 2006 15:58:23 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GdBFt-0007Ji-1m; Thu, 26 Oct 2006 15:51:09 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GdBFs-0005xe-HU; Thu, 26 Oct 2006 15:51:08 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 460052AD37;
	Thu, 26 Oct 2006 19:50:08 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GdBEu-0005KH-0N; Thu, 26 Oct 2006 15:50:08 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 26 Oct 2006 15:50:08 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-implementation-guidelines-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: IPFIX Implementation Guidelines
	Author(s)	: E. Boschi, et al.
	Filename	: draft-ietf-ipfix-implementation-guidelines-01.txt
	Pages		: 33
	Date		: 2006-10-26
	
The IP Flow Information eXport (IPFIX) protocol defines how IP Flow 
   information can be exported from routers, measurement probes or 
   other devices. This document provides guidelines for the 
   implementation and use of the IPFIX protocol. Several sets of 
   guidelines address template management, transport-specific issues, 
   implementation of exporting and collecting processes and IPFIX 
   implementation on middleboxes (such as firewalls, network address 
   translators, tunnel endpoints, packet classifiers, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-implementation-guidelines-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-26114444.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-implementation-guidelines-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-implementation-guidelines-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-26114444.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 16:43:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdC4d-0005wV-9X; Thu, 26 Oct 2006 16:43:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBMu-0001ym-Uh; Thu, 26 Oct 2006 15:58:24 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GdBEt-0007Dj-JR; Thu, 26 Oct 2006 15:50:07 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8BC6F328BA;
	Thu, 26 Oct 2006 19:50:07 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GdBEt-0005Iz-E8; Thu, 26 Oct 2006 15:50:07 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 26 Oct 2006 15:50:07 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-info-14.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: Information Model for IP Flow Information Export
	Author(s)	: J. Quittek, et al.
	Filename	: draft-ietf-ipfix-info-14.txt
	Pages		: 167
	Date		: 2006-10-26
	
This memo defines an information model for the IP Flow Information
   eXport (IPFIX) protocol.  It is used by the IPFIX protocol for
   encoding measured traffic information and information related to the
   traffic Observation Point, the traffic Metering Process and the
   Exporting Process.  Although developed for the IPFIX protocol, the
   model is defined in an open way that easily allows using it in other
   protocols, interfaces, and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-14.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-info-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-info-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-26100935.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-info-14.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-info-14.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-26100935.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 16:43:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdC4d-0005wV-9X; Thu, 26 Oct 2006 16:43:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdBMu-0001ym-Uh; Thu, 26 Oct 2006 15:58:24 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GdBEt-0007Dj-JR; Thu, 26 Oct 2006 15:50:07 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8BC6F328BA;
	Thu, 26 Oct 2006 19:50:07 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GdBEt-0005Iz-E8; Thu, 26 Oct 2006 15:50:07 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Thu, 26 Oct 2006 15:50:07 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-info-14.txt 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
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		: Information Model for IP Flow Information Export
	Author(s)	: J. Quittek, et al.
	Filename	: draft-ietf-ipfix-info-14.txt
	Pages		: 167
	Date		: 2006-10-26
	
This memo defines an information model for the IP Flow Information
   eXport (IPFIX) protocol.  It is used by the IPFIX protocol for
   encoding measured traffic information and information related to the
   traffic Observation Point, the traffic Metering Process and the
   Exporting Process.  Although developed for the IPFIX protocol, the
   model is defined in an open way that easily allows using it in other
   protocols, interfaces, and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-14.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipfix-info-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-info-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-10-26100935.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-info-14.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-ipfix-info-14.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-10-26100935.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/ipfix

--NextPart--




From ipfix-bounces@ietf.org Thu Oct 26 17:15:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdCYe-00062Q-7n; Thu, 26 Oct 2006 17:14:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCYc-00061E-Qz
	for ipfix@ietf.org; Thu, 26 Oct 2006 17:14:34 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCYC-0007Zg-8d
	for ipfix@ietf.org; Thu, 26 Oct 2006 17:14:34 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 2A2E81BAC4D
	for ; Thu, 26 Oct 2006 23:14:04 +0200 (CEST)
Date: Thu, 26 Oct 2006 23:14:01 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-info-14.txt 
Message-ID: <0A341B86C7903076ABA861E1@[192.168.1.129]>
In-Reply-To: 
References: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Here is the list of changes from version -13
(excluding minor editorial edits)
  - new IE #224 ipTotalLength
  - renamed min/maximumPacketLength to min/maximumIpTotalLength
    and changed their type from unsigned16 to unsigned64
  - changed type of ipPayloadLength from unsigned64 to unsigned32
  - changed type of tcpHeaderLength from unsigned16 to unsigned8
  - changed type of mplsTopLabelTTL from unsigned32 to unsigned8

Juergen

--On 26.10.2006 15:50 Uhr -0400 Internet-Drafts@ietf.org wrote:

> 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		: Information Model for IP Flow Information Export
> 	Author(s)	: J. Quittek, et al.
> 	Filename	: draft-ietf-ipfix-info-14.txt
> 	Pages		: 167
> 	Date		: 2006-10-26
> 	
> This memo defines an information model for the IP Flow Information
>    eXport (IPFIX) protocol.  It is used by the IPFIX protocol for
>    encoding measured traffic information and information related to the
>    traffic Observation Point, the traffic Metering Process and the
>    Exporting Process.  Although developed for the IPFIX protocol, the
>    model is defined in an open way that easily allows using it in other
>    protocols, interfaces, and applications.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-14.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-ipfix-info-14.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipfix-info-14.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



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



From ipfix-bounces@ietf.org Thu Oct 26 17:15:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdCYe-00062Q-7n; Thu, 26 Oct 2006 17:14:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCYc-00061E-Qz
	for ipfix@ietf.org; Thu, 26 Oct 2006 17:14:34 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCYC-0007Zg-8d
	for ipfix@ietf.org; Thu, 26 Oct 2006 17:14:34 -0400
Received: from [192.168.1.129] (unknown [91.89.53.224])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 2A2E81BAC4D
	for ; Thu, 26 Oct 2006 23:14:04 +0200 (CEST)
Date: Thu, 26 Oct 2006 23:14:01 +0200
From: Juergen Quittek 
To: ipfix@ietf.org
Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-info-14.txt 
Message-ID: <0A341B86C7903076ABA861E1@[192.168.1.129]>
In-Reply-To: 
References: 
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear all,

Here is the list of changes from version -13
(excluding minor editorial edits)
  - new IE #224 ipTotalLength
  - renamed min/maximumPacketLength to min/maximumIpTotalLength
    and changed their type from unsigned16 to unsigned64
  - changed type of ipPayloadLength from unsigned64 to unsigned32
  - changed type of tcpHeaderLength from unsigned16 to unsigned8
  - changed type of mplsTopLabelTTL from unsigned32 to unsigned8

Juergen

--On 26.10.2006 15:50 Uhr -0400 Internet-Drafts@ietf.org wrote:

> 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		: Information Model for IP Flow Information Export
> 	Author(s)	: J. Quittek, et al.
> 	Filename	: draft-ietf-ipfix-info-14.txt
> 	Pages		: 167
> 	Date		: 2006-10-26
> 	
> This memo defines an information model for the IP Flow Information
>    eXport (IPFIX) protocol.  It is used by the IPFIX protocol for
>    encoding measured traffic information and information related to the
>    traffic Observation Point, the traffic Metering Process and the
>    Exporting Process.  Although developed for the IPFIX protocol, the
>    model is defined in an open way that easily allows using it in other
>    protocols, interfaces, and applications.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-14.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-ipfix-info-14.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipfix-info-14.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



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



From ipfix-bounces@ietf.org Fri Oct 27 00:53:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdJhP-0002g4-TA; Fri, 27 Oct 2006 00:52:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GdJhO-0002cm-FT
	for ipfix@ietf.org; Fri, 27 Oct 2006 00:52:06 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdJhJ-0006Tx-9D
	for ipfix@ietf.org; Fri, 27 Oct 2006 00:52:06 -0400
Received: from [127.0.0.1] (mail.nttv6.net [192.68.245.115])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9R4pcLG012733
	for ; Fri, 27 Oct 2006 13:51:39 +0900 (JST)
	(envelope-from akoba@nttv6.net)
Date: Fri, 27 Oct 2006 13:51:40 +0900
From: kobayashi atsushi 
To: ipfix@ietf.org
Message-Id: <20061027131249.833B.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: [IPFIX] IPFIX Mediators draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear all,

I have submitted IPFIX Mediators draft reviced version(-01).

Title		: IPFIX Mediators
Author(s)	: A. Kobayashi, et al.
Filename	: draft-kobayashi-ipfix-mediator-01.txt

IPFIX Mediators is general word that include in IPFIX concentrators and
IPFIX proxies. The goal of this draft is to clarify the function of
IPFIX Mediators.

Especially, we want to solve the issue of cascade connection of IPFIX
Mediators. For example, in following condition, we need to think more how
to inform the Collector about Router's information through two Mediators.
If the Collector get "exporterIPv4Address" element from Meidator#2, the
Collector cannot recognize this element indicates Mediator#1 or Router.

       Session#a            Session#b            Session#c
Router --------> Mediator#1 --------> Mediator#2 -------->Collector
IP:1.1.1.1       IP:2.2.2.2           IP:3.3.3.3
Port:10          Port:20              Port:30
ODID:10

This draft proposes the Route Option Template to solve this issue.

Comment is welcome!

Thanks,
Atsushi KOBAYASHI

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From ipfix-bounces@ietf.org Fri Oct 27 00:53:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdJhP-0002g4-TA; Fri, 27 Oct 2006 00:52:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GdJhO-0002cm-FT
	for ipfix@ietf.org; Fri, 27 Oct 2006 00:52:06 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdJhJ-0006Tx-9D
	for ipfix@ietf.org; Fri, 27 Oct 2006 00:52:06 -0400
Received: from [127.0.0.1] (mail.nttv6.net [192.68.245.115])
	by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id k9R4pcLG012733
	for ; Fri, 27 Oct 2006 13:51:39 +0900 (JST)
	(envelope-from akoba@nttv6.net)
Date: Fri, 27 Oct 2006 13:51:40 +0900
From: kobayashi atsushi 
To: ipfix@ietf.org
Message-Id: <20061027131249.833B.AKOBA@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.25.02 [ja]
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: [IPFIX] IPFIX Mediators draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org


Dear all,

I have submitted IPFIX Mediators draft reviced version(-01).

Title		: IPFIX Mediators
Author(s)	: A. Kobayashi, et al.
Filename	: draft-kobayashi-ipfix-mediator-01.txt

IPFIX Mediators is general word that include in IPFIX concentrators and
IPFIX proxies. The goal of this draft is to clarify the function of
IPFIX Mediators.

Especially, we want to solve the issue of cascade connection of IPFIX
Mediators. For example, in following condition, we need to think more how
to inform the Collector about Router's information through two Mediators.
If the Collector get "exporterIPv4Address" element from Meidator#2, the
Collector cannot recognize this element indicates Mediator#1 or Router.

       Session#a            Session#b            Session#c
Router --------> Mediator#1 --------> Mediator#2 -------->Collector
IP:1.1.1.1       IP:2.2.2.2           IP:3.3.3.3
Port:10          Port:20              Port:30
ODID:10

This draft proposes the Route Option Template to solve this issue.

Comment is welcome!

Thanks,
Atsushi KOBAYASHI

--- 
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://www1.ietf.org/mailman/listinfo/ipfix



From bun_bun_itumohima2006@yahoo.co.jp Fri Oct 27 02:55:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdLdD-0000HU-Pb
	for ipfix-archive@megatron.ietf.org; Fri, 27 Oct 2006 02:55:56 -0400
Received: from [58.61.153.99] (helo=pc42)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1GdLdB-0004jQ-Mb
	for ipfix-archive@megatron.ietf.org; Fri, 27 Oct 2006 02:55:55 -0400
To: 
From: =?iso-2022-jp?B?GyRCQDZIfhsoQg==?=
Subject: =?iso-2022-jp?B?GyRCJSglbT13NjU7VSRAJEMkPyRfJD8kJCRoGyhC?=
MIME-Version: 1.0
Reply-To: 
Date: Fri, 27 Oct 2006 11:58:23 +0900
Content-Type:text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

$B!!!!(B
$B:rF|8@$C$F$?$"$N?M!"%(%m=w65;U$3$3$K$$$?$h!#(B
$B!!!!(B
$B$d$C$HC5$7$?!*(B
   
 http://make-your-dream.net/love/
$B!!!!(B
$B$H$K$+$/!"0lEYOC$7$F$_$F!*(B
$B!!!!(B
$B40A4L5NA$G!":#$J$iF@E@$b@9$j$@$/$5$s$@$C$F!*(B
$B!!(B
$B$3$N%a!<%k$O!"3'$KAw$C$F$J$$$+$i"v(B
$B!!!!(B
$B5.J}$@$1$K8+$F$[$7$/$F!#!#!#!#(B
$B!!!!(B
$B$H$K$+$/!"8+$F$_$F$/$@$5$$$M!#(B
$B!!!!(B
http://make-your-dream.net/love/






From bun_bun_itumohima2006@yahoo.co.jp Sat Oct 28 11:21:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gdq0F-0004Cs-3C
	for ipfix-archive@megatron.ietf.org; Sat, 28 Oct 2006 11:21:43 -0400
Received: from [58.61.153.90] (helo=pc27)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Gdq0D-00044s-Da
	for ipfix-archive@megatron.ietf.org; Sat, 28 Oct 2006 11:21:43 -0400
To: 
From: =?iso-2022-jp?B?GyRCQUdFKCRKPVAycSQkJHI1YSRhJGtKfSRYIXkbKEI=?=
Subject: =?iso-2022-jp?B?GyRCQUdFKCRKPVAycSQkJHI1YSRhJGtKfSRYIXkbKEI=?=
MIME-Version: 1.0
Reply-To: 
Date: Sat, 28 Oct 2006 19:35:43 +0900
Content-Type:text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

$B9-9p<}1W$N$_$G1?1D$7$F$$$^$9$N$G!"CK=w$H$bA4%5!<%S%940A4L5NA$G$4MxMQ$$$?(B
$B$@$1$^$9!#(B
$B!V2q$($kF|8!:w!W!V2K$JF|8!:w!W!"=w@-$K?M5$$N!V0lH/1?L?8!:w!W$J$I!"L\E*JL(B
$B$K$*Aj
To: 
Subject: Home-based positions for you. 
Date: Sun, 29 Nov 2006 13:44:31 0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Importance: Normal
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

‘None of your mistering,’ replied the ruffian; ‘you always mean mischief when you come that. You know my name: out with it! I shan’t disgrace it when the time comes.’‘Why, you’re just the very person for it,’ reasoned Mr. Sikes: ‘nobody about here knows anything of you.’‘And I’m afraid, you see, added the Jew, speaking as if he had not noticed the interruption; and regarding the other closely as he did so,—‘I’m afraid that, if the game was up with us, it might be up with a good many more, and that it would come out rather worse for you than it would for me, my dear.’Mr. Fagin looked so very much in earnest, that Charley Bates, who deemed it prudent in all cases to be on the safe side, and who conceived it by no means improbable that it might be his turn to be throttled second, dropped upon his knees, and raised a loud, well–sustained, and continuous roar—something between a mad bull and a speaking trumpet.The Jew stepped back in this emergency, with more agility than could have been anticipated in a man of his apparent decrepitude; and, seizing up the pot, prepared to hurl it at his assailant’s head. But Charley Bates, at this moment, calling his attention by a perfectly terrific howl, he suddenly altered its destination, and flung it full at that young gentleman.‘Why, what the blazes is in the wind now!’ growled a deep voice. ‘Who pitched that ‘ere at me? It’s well it’s the beer, and not the pot, as hit me, or I’d have settled somebody. I might have know’d, as nobody but an infernal, rich, plundering, thundering old Jew could afford to throw away any drink but water—and not that, unless he done the River Company every quarter. Wot’s it all about, Fagin? D—me, if my neck–handkercher an’t lined with beer! Come in, you sneaking warmint; wot are you stopping outside for, as if you was ashamed of your master! Come in!’The man who growled out these words, was a stoutly–built fellow of about five–and–thirty, in a black velveteen coat, very soiled drab breeches, lace–up half boots, and grey cotton stockings which inclosed a bulky pair of legs, with large swelling calves;—the kind of legs, which in such costume, always look in an unfinished and incomplete state without a set of fetters to garnish them. He had a brown hat on his head, and a dirty belcher handkerchief round his neck: with the long frayed ends of which he smeared the beer from his face as he spoke. He disclosed, when he had done so, a broad heavy countenance with a beard of three days’ growth, and two scowling eyes; one of which displayed various parti–coloured symptoms of having been recently damaged by a blow. ‘Come in, d’ye hear?’ growled this engaging ruffian. A white shaggy dog, with his face scratched and torn in twenty different places, skulked into the room.‘Why didn’t you come in afore?’ said the man. ‘You’re getting too proud to own me afore company, are you? Lie down!’
---------------------------------------------------------------------

Dear, Ipfix
American trading company is looking for accurate  employees. 

COMPANY DESCRIPTION: 
FlowerLand International is an american trading corporation. 
We specialize in all kinds of flowers, decorative plants and greenery that can be used for home or office/business.  

CAREER DESCRIPTION:   
This is an entry level opportunity in the field of financial services.  

EMPLOYMENT TYPE: 
Part-time employment. 

REQUIREMENTS FOR EMPLOYEES:  

- Basic knowledge of credit principles, financial services and operations. 
- employee must be honest, intelligent and dedicated. 
- Ability to work on multiple projects simultaneously along with meeting deadlines. 
- Ability to work independently or in a team environment. 
- Having no problem with the authorities.  
- Having a functional bank account. Company account is an advantage.  
- Having a mobile phone.  
- Having a deep desire to achieve financial success.  

SALARY:  

$30 000-$60 000/yr 

ADVANTAGES: 


- No sign up fees. 
- No investment needed. 
- Covered expenses. 
- Illness\disability friendly team.  
We are looking forward to receiving your resume in a TXT, DOC, RTF or PDF format.

Please send us your resume to tforesteo@yahoo.com ========================================================

‘Yes, she will, Fagin,’ said Sikes.‘Why, you’re just the very person for it,’ reasoned Mr. Sikes: ‘nobody about here knows anything of you.’This was said in jest; but if the speaker could have seen the evil leer with which the Jew bit his pale lip as he turned round to the cupboard, he might have thought the caution not wholly unnecessary, or the wish (at all events) to improve upon the distiller’s ingenuity not very far from the old gentleman’s merry heart.



From akstcflabarmnsdgs@flabar.org Sun Oct 29 14:35:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeGRk-00028M-Hq; Sun, 29 Oct 2006 14:35:52 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GeGRk-0004Uj-GT; Sun, 29 Oct 2006 14:35:52 -0500
Received: from 163.209.broadband3.iol.cz ([85.70.209.163] helo=duron-1300)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GeGRg-0002uS-9K; Sun, 29 Oct 2006 14:35:51 -0500
Received: from 199.44.15.99 (HELO mailgw1.flabar.org)
     by lists.ietf.org with esmtp (STMX6NFG Y0PK6R)
     id A57355-P9TSSR-QV
     for ipcdn-archive@lists.ietf.org; Sun, 29 Nov 2006 19:35:46 -0060
From: "Cindy Whalen" 
To: 
Subject: pain spot Non-uralian
Date: Sun, 29 Nov 2006 19:35:46 -0060
Message-ID: <01c6fb91$6dff10a0$6c822ecf@akstcflabarmnsdgs>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Importance: Normal
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

approbation in terms warm enough to satisfy her feelings, though she talked to bingley of nothing elseelizabeth found the interest of the subject increase, and listened with all her heart; but the



From egbeedbccaa@caramori.com.br Sun Oct 29 18:15:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeJrw-0006rR-Gw
	for ipfix-archive@lists.ietf.org; Sun, 29 Oct 2006 18:15:08 -0500
Received: from x4b02.x.pppool.de ([89.59.75.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GeJrt-0002hL-Tn; Sun, 29 Oct 2006 18:15:08 -0500
From: "Gabrielle Vaughan" 
To: 
Subject:  High wages. 
Date: Sun, 29 Nov 2006 23:14:24 -0060
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3338.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

great and small, in those days, issuing notes practically withoutcared nothing for books. He was a clean, stalky, shapely boy, withwide forehead; short, bristly, dark-brown hair. He had an incisive,and he was worried, as he might well be, by the perfect storm of wildcatmoney which was floating about and which was constantly coming to his

----------------------------------------------------------------------------------------------------

FlowerLand International is looking for talented    
employee.  
  
The corporation:  
  
FlowerLand International is an American trading corporation.  
We specialize in all kinds of plants and decorative greenery that can be used for home    
or office. We are not a MLM corporation nor any similarity.  
You are never required to buy nor invest anything to work with Flowerland International.   
  
CAREER POSITION:  
  
This is an entry level opportunity in the field of banking services.  
  
MAIN ADVANTAGES:  
  
- Really High Wages.  
- Ability to work at home.  
- Flexible shedule.  
- No sign up fees, no investment is required.  
- All expenses such as phone calls, webtraffic, etc will be fully covered by our   
company.  
- Illness\Disability friendly team.  
  
REQUIREMENTS FOR CANDIDATES:  
  
- Basic knowledge of credit principles, banking services and operations.  
- Ability to work on multiple projects simultaneously along with meeting deadlines.  
- Ability to work independently or in a team environment.  
- Having no problem with the Authorities.   
- Having a mobile phone.   
- Having a deep desire to achieve financial success.   
  
DEGREE:  
  
No degree required.  
  
HOW TO Join:  
Please send your CV to our personnel manager.  
It must be sent in a TXT, DOC, RTF or PDF format.   

Please write to the following email: tforesteo@yahoo.com  

=================================================




From ipfix-bounces@ietf.org Mon Oct 30 03:51:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeSq1-00089l-1B; Mon, 30 Oct 2006 03:49:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSpj-00082P-KG
	for ipfix@ietf.org; Mon, 30 Oct 2006 03:49:28 -0500
Received: from tama55.ecl.ntt.co.jp ([129.60.39.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeSph-0002Qz-Nq
	for ipfix@ietf.org; Mon, 30 Oct 2006 03:49:27 -0500
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp
	[129.60.39.114])
	by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8nDCe012998;
	Mon, 30 Oct 2006 17:49:13 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 094CE20AE2A;
	Mon, 30 Oct 2006 17:49:13 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B518C20AE28;
	Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8nCMn015020; 
	Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9U8nCHH004247; Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9U8nBHM004242; Mon, 30 Oct 2006 17:49:11 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8n13a017192;
	Mon, 30 Oct 2006 17:49:11 +0900 (JST)
Message-ID: <4545BC7C.60308@lab.ntt.co.jp>
Date: Mon, 30 Oct 2006 17:49:00 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] Question about data types of some IEs
References: <4532D411.9090006@lab.ntt.co.jp>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Juregen,

Juergen Quittek wrote:
> Dear Irino-san,
> 
> Thanks for carefully checking the data types used in the
> info model.  Please find replies to your comments inline.
> For three IEs I followed your suggestion and replaced the
> data type for the next version of the draft.

Thank you.
I confirmed these changes in IPFIX-INFO-14

>> 4.
>>    5.7.12.  mplsVpnRouteDistinguisher
>>    Abstract Data Type: octetArray
>>
>> According to section 4.2 in rfc4364,
>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher
>> followed by a 4-byte IPv4 address.
>>
>> Is unsigned64 sufficient for this IE?
>>
>> According to page 7 of rfc4382,
>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
>> SYNTAX  OCTET STRING(SIZE (0..256))
>>
>> I think that Abstract Data Type of this IE should be "string",
>> if this IE is in conformity to rfc4382.
> 
> RFC 4364 defines the size of a route distinguisher as 64 bits
> (8 octets) which exactly matches the current data type in the
> info model.

I am confused by this sentence. Current abstract data type is defined as
octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is
better to change unsigned64. Otherwise, I supposed to use 8 octets
octetArray, a description of this IE should specify that a size of this
IE is 8 octets.

> However, you are right that the MIB module in RFC 4382 chooses
> the SMI type for a route distinguisher to be an octet string
> with up to 256 octets.  I do not understand why the in the MIB
> module in RFC 4382 does not use a shorter array.

I have same question.
When RD is described by string, I guess that the maximum string length 
of RD is 23 characters.
-----
0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters
maximum value of 2ByteASN is 65536,
maximum value of 4Byte is 4294967296
1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters
maximum value of 4ByteIPv4Address is 255.255.255.255,
maximum value of 2Byte is 65536
2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters
maximum value of 4ByteASN is 4294967296,
maximum value of 2Byte is 65536
-----


> 
> I sent this question to the editors of RFC 4382.
> Let's hope they can help us.  Or can somebody on the list
> answer this question?
>> 5.
>> Can Exporter implementation be chosen which use fixed or variable
>> length for IEs that have octetArray or string data type?
>> Is it correct?  Should Information model draft define which use
>> fixed or variable for these IEs?
> 
> I think exporters should be free to choose between fixed or
> variable length encoding of a particular IE.  I do not see a
> good reason to restrict the use.  But I am open to discuss it
> if you bring up a good reason.

I reconsidered my opinion, I agree that exporters should be free to
choose between fixed or variable length encoding of a particular IE.
On the other hand, I am afraid that collectors increase load by decoding
variable length IEs. Indeed, "The IPFIX Template mechanism is optimized
for fixed length Information Elements" is written in IPFIX-PROTO.
When a exporter treats a IE whose data type is octetArray but the data
size is steady, exporter will use fixed length encoding (for example
above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8
octets, the size is fixed (if this IE is in conformity to rfc4364)).

I think that the use should not be restricted, but I think definition of
IE should provide information about which prefer fixed or variable, and
provide minimum / maximum size length octetArray and string type IEs to
prevent confusion for implementation. (Similarly, I think definition of
IE should provide information whether the IE may be apply reduced size
encoding for integer and float type IEs.)


-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549







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



From ipfix-bounces@ietf.org Mon Oct 30 03:51:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeSq1-00089l-1B; Mon, 30 Oct 2006 03:49:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSpj-00082P-KG
	for ipfix@ietf.org; Mon, 30 Oct 2006 03:49:28 -0500
Received: from tama55.ecl.ntt.co.jp ([129.60.39.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeSph-0002Qz-Nq
	for ipfix@ietf.org; Mon, 30 Oct 2006 03:49:27 -0500
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp
	[129.60.39.114])
	by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8nDCe012998;
	Mon, 30 Oct 2006 17:49:13 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 094CE20AE2A;
	Mon, 30 Oct 2006 17:49:13 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B518C20AE28;
	Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8nCMn015020; 
	Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9U8nCHH004247; Mon, 30 Oct 2006 17:49:12 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9U8nBHM004242; Mon, 30 Oct 2006 17:49:11 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9U8n13a017192;
	Mon, 30 Oct 2006 17:49:11 +0900 (JST)
Message-ID: <4545BC7C.60308@lab.ntt.co.jp>
Date: Mon, 30 Oct 2006 17:49:00 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Juergen Quittek 
Subject: Re: [IPFIX] Question about data types of some IEs
References: <4532D411.9090006@lab.ntt.co.jp>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Juregen,

Juergen Quittek wrote:
> Dear Irino-san,
> 
> Thanks for carefully checking the data types used in the
> info model.  Please find replies to your comments inline.
> For three IEs I followed your suggestion and replaced the
> data type for the next version of the draft.

Thank you.
I confirmed these changes in IPFIX-INFO-14

>> 4.
>>    5.7.12.  mplsVpnRouteDistinguisher
>>    Abstract Data Type: octetArray
>>
>> According to section 4.2 in rfc4364,
>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher
>> followed by a 4-byte IPv4 address.
>>
>> Is unsigned64 sufficient for this IE?
>>
>> According to page 7 of rfc4382,
>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION
>> SYNTAX  OCTET STRING(SIZE (0..256))
>>
>> I think that Abstract Data Type of this IE should be "string",
>> if this IE is in conformity to rfc4382.
> 
> RFC 4364 defines the size of a route distinguisher as 64 bits
> (8 octets) which exactly matches the current data type in the
> info model.

I am confused by this sentence. Current abstract data type is defined as
octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is
better to change unsigned64. Otherwise, I supposed to use 8 octets
octetArray, a description of this IE should specify that a size of this
IE is 8 octets.

> However, you are right that the MIB module in RFC 4382 chooses
> the SMI type for a route distinguisher to be an octet string
> with up to 256 octets.  I do not understand why the in the MIB
> module in RFC 4382 does not use a shorter array.

I have same question.
When RD is described by string, I guess that the maximum string length 
of RD is 23 characters.
-----
0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters
maximum value of 2ByteASN is 65536,
maximum value of 4Byte is 4294967296
1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters
maximum value of 4ByteIPv4Address is 255.255.255.255,
maximum value of 2Byte is 65536
2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters
maximum value of 4ByteASN is 4294967296,
maximum value of 2Byte is 65536
-----


> 
> I sent this question to the editors of RFC 4382.
> Let's hope they can help us.  Or can somebody on the list
> answer this question?
>> 5.
>> Can Exporter implementation be chosen which use fixed or variable
>> length for IEs that have octetArray or string data type?
>> Is it correct?  Should Information model draft define which use
>> fixed or variable for these IEs?
> 
> I think exporters should be free to choose between fixed or
> variable length encoding of a particular IE.  I do not see a
> good reason to restrict the use.  But I am open to discuss it
> if you bring up a good reason.

I reconsidered my opinion, I agree that exporters should be free to
choose between fixed or variable length encoding of a particular IE.
On the other hand, I am afraid that collectors increase load by decoding
variable length IEs. Indeed, "The IPFIX Template mechanism is optimized
for fixed length Information Elements" is written in IPFIX-PROTO.
When a exporter treats a IE whose data type is octetArray but the data
size is steady, exporter will use fixed length encoding (for example
above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8
octets, the size is fixed (if this IE is in conformity to rfc4364)).

I think that the use should not be restricted, but I think definition of
IE should provide information about which prefer fixed or variable, and
provide minimum / maximum size length octetArray and string type IEs to
prevent confusion for implementation. (Similarly, I think definition of
IE should provide information whether the IE may be apply reduced size
encoding for integer and float type IEs.)


-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549







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



From ipfix-bounces@ietf.org Mon Oct 30 06:34:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h0-3Y; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN3-0003LF-9c
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:01 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVIz-0004es-Sn
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:27:52 -0500
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:27:50 +0100
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.20060308/8.12.11) with ESMTP id
	k9UBRniD007187; Mon, 30 Oct 2006 12:27:49 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UBRlmd004292; 
	Mon, 30 Oct 2006 12:27:47 +0100 (MET)
Received: from [10.61.66.44] (ams3-vpn-dhcp556.cisco.com [10.61.66.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20606;
	Mon, 30 Oct 2006 11:27:46 GMT
Message-ID: <4545E1A6.9000703@cisco.com>
Date: Mon, 30 Oct 2006 11:27:34 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] Question about data types of some IEs
References: <4532D411.9090006@lab.ntt.co.jp>	
	<4545BC7C.60308@lab.ntt.co.jp>
In-Reply-To: <4545BC7C.60308@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2019; t=1162207669; x=1163071669;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20Question=20about=20data=20types=20of=20some=20IEs;
	X=v=3Dcisco.com=3B=20h=3Dj169ACtpTeeIoaTbMAHIiqwCn6s=3D;
	b=VrKAWFjnC8WE5XGmmmi9FEKVS4ES3fGPkUy6ZaPwgugQZ8l8MdzGUrAVu4ABtCS/aFIdya++
	Om2xTVxVqwIj9SA1Y03qZyZ2UhDlZRl7LVxgP2ppmWMJQ9jcPtyHpxMt;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> I am afraid that collectors increase load by decoding variable length
> IEs.

Then collectors should be designed to decode this as efficiently as
possible.


> I think definition of IE should provide information about which 
> prefer fixed or variable, and provide minimum / maximum size length 
> octetArray and string type IEs to prevent confusion for 
> implementation.

Choice of fixed / variable length IEs depends on the values coming from
the monitoring process and whether the exporting process can encode them
more efficiently as a multitude of seperate templates, or as one
template using variable sizes IEs.

Probably fixed size IEs are prefered over needlessly using variable 
size, but variable size is preferred over needlessly creating a large 
number of templates.

Regarding IE size, currently, there is only one string type IE:
wlanSSID, which includes a size indication in its description:

    Description:
       The Service Set IDentifier From ipfix-bounces@ietf.org Mon Oct 30 06:34:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h0-3Y; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN3-0003LF-9c
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:01 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVIz-0004es-Sn
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:27:52 -0500
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:27:50 +0100
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.20060308/8.12.11) with ESMTP id
	k9UBRniD007187; Mon, 30 Oct 2006 12:27:49 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UBRlmd004292; 
	Mon, 30 Oct 2006 12:27:47 +0100 (MET)
Received: from [10.61.66.44] (ams3-vpn-dhcp556.cisco.com [10.61.66.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20606;
	Mon, 30 Oct 2006 11:27:46 GMT
Message-ID: <4545E1A6.9000703@cisco.com>
Date: Mon, 30 Oct 2006 11:27:34 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] Question about data types of some IEs
References: <4532D411.9090006@lab.ntt.co.jp>	
	<4545BC7C.60308@lab.ntt.co.jp>
In-Reply-To: <4545BC7C.60308@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2019; t=1162207669; x=1163071669;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20Question=20about=20data=20types=20of=20some=20IEs;
	X=v=3Dcisco.com=3B=20h=3Dj169ACtpTeeIoaTbMAHIiqwCn6s=3D;
	b=VrKAWFjnC8WE5XGmmmi9FEKVS4ES3fGPkUy6ZaPwgugQZ8l8MdzGUrAVu4ABtCS/aFIdya++
	Om2xTVxVqwIj9SA1Y03qZyZ2UhDlZRl7LVxgP2ppmWMJQ9jcPtyHpxMt;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> I am afraid that collectors increase load by decoding variable length
> IEs.

Then collectors should be designed to decode this as efficiently as
possible.


> I think definition of IE should provide information about which 
> prefer fixed or variable, and provide minimum / maximum size length 
> octetArray and string type IEs to prevent confusion for 
> implementation.

Choice of fixed / variable length IEs depends on the values coming from
the monitoring process and whether the exporting process can encode them
more efficiently as a multitude of seperate templates, or as one
template using variable sizes IEs.

Probably fixed size IEs are prefered over needlessly using variable 
size, but variable size is preferred over needlessly creating a large 
number of templates.

Regarding IE size, currently, there is only one string type IE:
wlanSSID, which includes a size indication in its description:

    Description:
       The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
       network used.  According to IEEE.802-11.1999 the SSID is encoded
       into a string of up to 32 characters.

There are two array type IEs: paddingOctets, which needs no size, and
mplsVpnRouteDistinguisher, which is discussed in your mail.

I would be happy for mplsVpnRouteDistinguisher either to be changed to
unsigned64, or to remain as an array but include this text in its
description:

     According to section 4.2 in rfc4364, a VPN-IPv4 address
     consists of an 8-byte Route Distinguisher followed by a
     4-byte IPv4 address.

BTW, it doesn't discuss IPv6...


> (Similarly, I think definition of IE should provide information 
> whether the IE may be apply reduced size encoding for integer and 
> float type IEs.)

I disagree: this information should not be provided per IE, but only as
a general guideline - which you will already find in section 6.2 of
IPFIX-PROTO.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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

From ipfix-bounces@ietf.org Mon Oct 30 06:34:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h6-A6; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN4-0003Lk-D6
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:02 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVI2-0004a5-FY
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:26:52 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQhcP016748; 
	Mon, 30 Oct 2006 20:26:43 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQgP4000484; Mon, 30 Oct 2006 20:26:42 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQflt015511; 
	Mon, 30 Oct 2006 20:26:41 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQeJb000965; 
	Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQeSN014700; Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQd9C014697; Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQdVQ012624;
	Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Message-ID: <4545E16D.1030809@lab.ntt.co.jp>
Date: Mon, 30 Oct 2006 20:26:37 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: ipfix@ietf.org
X-BeenThere: ipfix(SSID) identifying an 802.11 (Wi-Fi)
       network used.  According to IEEE.802-11.1999 the SSID is encoded
       into a string of up to 32 characters.

There are two array type IEs: paddingOctets, which needs no size, and
mplsVpnRouteDistinguisher, which is discussed in your mail.

I would be happy for mplsVpnRouteDistinguisher either to be changed to
unsigned64, or to remain as an array but include this text in its
description:

     According to section 4.2 in rfc4364, a VPN-IPv4 address
     consists of an 8-byte Route Distinguisher followed by a
     4-byte IPv4 address.

BTW, it doesn't discuss IPv6...


> (Similarly, I think definition of IE should provide information 
> whether the IE may be apply reduced size encoding for integer and 
> float type IEs.)

I disagree: this information should not be provided per IE, but only as
a general guideline - which you will already find in section 6.2 of
IPFIX-PROTO.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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

From ipfix-bounces@ietf.org Mon Oct 30 06:34:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h6-A6; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN4-0003Lk-D6
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:02 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVI2-0004a5-FY
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:26:52 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQhcP016748; 
	Mon, 30 Oct 2006 20:26:43 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQgP4000484; Mon, 30 Oct 2006 20:26:42 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQflt015511; 
	Mon, 30 Oct 2006 20:26:41 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQeJb000965; 
	Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQeSN014700; Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQd9C014697; Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQdVQ012624;
	Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Message-ID: <4545E16D.1030809@lab.ntt.co.jp>
Date: Mon, 30 Oct 2006 20:26:37 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Juregen, Paul

Brian Trammell wrote:
> I can see it being useful, as a sideband method for measuring the health 
> of the measurement infrastructure itself ("hey, why'd the router reboot 
> yesterday?")... Of course, this is a system management problem and on 
> its own is out of scope for IPFIX, I think, but it could explain e.g. 
> outages in the data (no data for a while followed by an updated init 
> time => router outage as opposed to network outage).
> 
>>> (of course, now we need conflict resolution rules  should both 
>>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present 
>>> and valid...)
>>
>> Since your sysuptimes might be referenced to an updated 
>> sysUpBaseTimeMilliseconds, that's what you must use and not 
>> systemInitTimeMilliseconds.
> 
> indeed; just pointing out that we'll need to note this in the 
> Description of both IEs.

Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
---
   sysUpBaseTimeMilliseconds

    Description:
       The absolute timestamp of the base time for flowStartSysUpTime 
and flowEndSysUpTime. The initial value is equal to 
systemInitTimeMilliseconds, and the value is updated every 49 days to 
prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

    Abstract Data Type: dateTimeMilliseconds
    ElementId:
    Status: current
    Units: milliseconds
---
I am not good at English, please correct above description, if it has 
problem.

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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





@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Juregen, Paul

Brian Trammell wrote:
> I can see it being useful, as a sideband method for measuring the health 
> of the measurement infrastructure itself ("hey, why'd the router reboot 
> yesterday?")... Of course, this is a system management problem and on 
> its own is out of scope for IPFIX, I think, but it could explain e.g. 
> outages in the data (no data for a while followed by an updated init 
> time => router outage as opposed to network outage).
> 
>>> (of course, now we need conflict resolution rules  should both 
>>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present 
>>> and valid...)
>>
>> Since your sysuptimes might be referenced to an updated 
>> sysUpBaseTimeMilliseconds, that's what you must use and not 
>> systemInitTimeMilliseconds.
> 
> indeed; just pointing out that we'll need to note this in the 
> Description of both IEs.

Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
---
   sysUpBaseTimeMilliseconds

    Description:
       The absolute timestamp of the base time for flowStartSysUpTime 
and flowEndSysUpTime. The initial value is equal to 
systemInitTimeMilliseconds, and the value is updated every 49 days to 
prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

    Abstract Data Type: dateTimeMilliseconds
    ElementId:
    Status: current
    Units: milliseconds
---
I am not good at English, please correct above description, if it has 
problem.

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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





From ipfix-bounces@ietf.org Mon Oct 30 06:34:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h6-A6; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN4-0003Lk-D6
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:02 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVI2-0004a5-FY
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:26:52 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQhcP016748; 
	Mon, 30 Oct 2006 20:26:43 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQgP4000484; Mon, 30 Oct 2006 20:26:42 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQflt015511; 
	Mon, 30 Oct 2006 20:26:41 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQeJb000965; 
	Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQeSN014700; Mon, 30 Oct 2006 20:26:40 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9UBQd9C014697; Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9UBQdVQ012624;
	Mon, 30 Oct 2006 20:26:39 +0900 (JST)
Message-ID: <4545E16D.1030809@lab.ntt.co.jp>
Date: Mon, 30 Oct 2006 20:26:37 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Brian Trammell 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear Juregen, Paul

Brian Trammell wrote:
> I can see it being useful, as a sideband method for measuring the health 
> of the measurement infrastructure itself ("hey, why'd the router reboot 
> yesterday?")... Of course, this is a system management problem and on 
> its own is out of scope for IPFIX, I think, but it could explain e.g. 
> outages in the data (no data for a while followed by an updated init 
> time => router outage as opposed to network outage).
> 
>>> (of course, now we need conflict resolution rules  should both 
>>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present 
>>> and valid...)
>>
>> Since your sysuptimes might be referenced to an updated 
>> sysUpBaseTimeMilliseconds, that's what you must use and not 
>> systemInitTimeMilliseconds.
> 
> indeed; just pointing out that we'll need to note this in the 
> Description of both IEs.

Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
---
   sysUpBaseTimeMilliseconds

    Description:
       The absolute timestamp of the base time for flowStartSysUpTime 
and flowEndSysUpTime. The initial value is equal to 
systemInitTimeMilliseconds, and the value is updated every 49 days to 
prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

    Abstract Data Type: dateTimeMilliseconds
    ElementId:
    Status: current
    Units: milliseconds
---
I am not good at English, please correct above description, if it has 
problem.

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549


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



From ipfix-bounces@ietf.org Mon Oct 30 06:34:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVO5-0003h0-3Y; Mon, 30 Oct 2006 06:33:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVN3-0003LF-9c
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:32:01 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVIz-0004es-Sn
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:27:52 -0500
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:27:50 +0100
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.20060308/8.12.11) with ESMTP id
	k9UBRniD007187; Mon, 30 Oct 2006 12:27:49 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UBRlmd004292; 
	Mon, 30 Oct 2006 12:27:47 +0100 (MET)
Received: from [10.61.66.44] (ams3-vpn-dhcp556.cisco.com [10.61.66.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20606;
	Mon, 30 Oct 2006 11:27:46 GMT
Message-ID: <4545E1A6.9000703@cisco.com>
Date: Mon, 30 Oct 2006 11:27:34 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] Question about data types of some IEs
References: <4532D411.9090006@lab.ntt.co.jp>	
	<4545BC7C.60308@lab.ntt.co.jp>
In-Reply-To: <4545BC7C.60308@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2019; t=1162207669; x=1163071669;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20Question=20about=20data=20types=20of=20some=20IEs;
	X=v=3Dcisco.com=3B=20h=3Dj169ACtpTeeIoaTbMAHIiqwCn6s=3D;
	b=VrKAWFjnC8WE5XGmmmi9FEKVS4ES3fGPkUy6ZaPwgugQZ8l8MdzGUrAVu4ABtCS/aFIdya++
	Om2xTVxVqwIj9SA1Y03qZyZ2UhDlZRl7LVxgP2ppmWMJQ9jcPtyHpxMt;
Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> I am afraid that collectors increase load by decoding variable length
> IEs.

Then collectors should be designed to decode this as efficiently as
possible.


> I think definition of IE should provide information about which 
> prefer fixed or variable, and provide minimum / maximum size length 
> octetArray and string type IEs to prevent confusion for 
> implementation.

Choice of fixed / variable length IEs depends on the values coming from
the monitoring process and whether the exporting process can encode them
more efficiently as a multitude of seperate templates, or as one
template using variable sizes IEs.

Probably fixed size IEs are prefered over needlessly using variable 
size, but variable size is preferred over needlessly creating a large 
number of templates.

Regarding IE size, currently, there is only one string type IE:
wlanSSID, which includes a size indication in its description:

    Description:
       The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
       network used.  According to IEEE.802-11.1999 the SSID is encoded
       into a string of up to 32 characters.

There are two array type IEs: paddingOctets, which needs no size, and
mplsVpnRouteDistinguisher, which is discussed in your mail.

I would be happy for mplsVpnRouteDistinguisher either to be changed to
unsigned64, or to remain as an array but include this text in its
description:

     According to section 4.2 in rfc4364, a VPN-IPv4 address
     consists of an 8-byte Route Distinguisher followed by a
     4-byte IPv4 address.

BTW, it doesn't discuss IPv6...


> (Similarly, I think definition of IE should provide information 
> whether the IE may be apply reduced size encoding for integer and 
> float type IEs.)

I disagree: this information should not be provided per IE, but only as
a general guideline - which you will already find in section 6.2 of
IPFIX-PROTO.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Mon Oct 30 07:01:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVoJ-0005we-VM; Mon, 30 Oct 2006 07:00:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVmZ-000548-9m
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:58:23 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVeU-0007wz-Um
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:50:04 -0500
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:50:03 +0100
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.20060308/8.12.11) with ESMTP id
	k9UBo2dk007384; Mon, 30 Oct 2006 12:50:02 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UBo1md013626; 
	Mon, 30 Oct 2006 12:50:01 +0100 (MET)
Received: from [10.61.66.44] (ams3-vpn-dhcp556.cisco.com [10.61.66.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA22376;
	Mon, 30 Oct 2006 11:50:00 GMT
Message-ID: <4545E6DC.8090807@cisco.com>
Date: Mon, 30 Oct 2006 11:49:48 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
	<4545E16D.1030809@lab.ntt.co.jp>
In-Reply-To: <4545E16D.1030809@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1873; t=1162209002; x=1163073002;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=q9V78ZcHdXrH/Zz25IZEv+1xKKGtH9v5kHo2/xaU7t6SrppDoIn1RzWJpO61x6Kj1ve7/c+2
	lKnJDr4w6qgzc3o1GSr6Jvuyz0bA7B+2igkP6Ux5uL6ykXo7ZXvv+fML;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
> ---
>   sysUpBaseTimeMilliseconds
> 
>    Description:
>       The absolute timestamp of the base time for flowStartSysUpTime and 
> flowEndSysUpTime. The initial value is equal to 
> systemInitTimeMilliseconds, and the value is updated every 49 days to 
> prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

I'd entirely remove the second sentence, since that is up to the 
implimentation. eg, it could start with a different value (eg, in the 
past, to export historical data). Or it could be updated every week, 
day, hour or minute.

We should say that where it's present it's to be used in preference to 
the systemInitTimeMilliseconds, where "present" means there's a value 
for this IE in the flow, or in an option that's in scope.

But you want to export the sysUpBaseTimeMilliseconds value in an option 
because you certainly you don't want to have to export the value in 
every flow, right?

That raises an interesting question concerning the change of value. If 
you're exporting some flows based on a certain value of 
sysUpBaseTimeMilliseconds, and you export an option containing an 
updated value, you must ensure that all the old flows have reached and 
been processed by the collector before the updated 
sysUpBaseTimeMilliseconds, and that the updated 
sysUpBaseTimeMilliseconds reaches the collector and is processed before 
any of the new flows. Else you risk interpreting some of the flows with 
the wrong value of sysUpBaseTimeMilliseconds.

Unless we can show how that can be done, it'd be necessary to export 
systemInitTimeMilliseconds in every flow which, as previously discussed 
at some length, is incredibly inefficient and should not be done.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From ipfix-bounces@ietf.org Mon Oct 30 07:01:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeVoJ-0005we-VM; Mon, 30 Oct 2006 07:00:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVmZ-000548-9m
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:58:23 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVeU-0007wz-Um
	for ipfix@ietf.org; Mon, 30 Oct 2006 06:50:04 -0500
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:50:03 +0100
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.20060308/8.12.11) with ESMTP id
	k9UBo2dk007384; Mon, 30 Oct 2006 12:50:02 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UBo1md013626; 
	Mon, 30 Oct 2006 12:50:01 +0100 (MET)
Received: from [10.61.66.44] (ams3-vpn-dhcp556.cisco.com [10.61.66.44])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA22376;
	Mon, 30 Oct 2006 11:50:00 GMT
Message-ID: <4545E6DC.8090807@cisco.com>
Date: Mon, 30 Oct 2006 11:49:48 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-gb, en-us
MIME-Version: 1.0
To: Hitoshi Irino 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
	<4545E16D.1030809@lab.ntt.co.jp>
In-Reply-To: <4545E16D.1030809@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1873; t=1162209002; x=1163073002;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:Paul=20Aitken=20
	|Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; 
	X=v=3Dcisco.com=3B=20h=3DHY1DEhngmBCaivVSQskIyZZ2YQs=3D;
	b=q9V78ZcHdXrH/Zz25IZEv+1xKKGtH9v5kHo2/xaU7t6SrppDoIn1RzWJpO61x6Kj1ve7/c+2
	lKnJDr4w6qgzc3o1GSr6Jvuyz0bA7B+2igkP6Ux5uL6ykXo7ZXvv+fML;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Hitoshi-san,

> Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
> ---
>   sysUpBaseTimeMilliseconds
> 
>    Description:
>       The absolute timestamp of the base time for flowStartSysUpTime and 
> flowEndSysUpTime. The initial value is equal to 
> systemInitTimeMilliseconds, and the value is updated every 49 days to 
> prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

I'd entirely remove the second sentence, since that is up to the 
implimentation. eg, it could start with a different value (eg, in the 
past, to export historical data). Or it could be updated every week, 
day, hour or minute.

We should say that where it's present it's to be used in preference to 
the systemInitTimeMilliseconds, where "present" means there's a value 
for this IE in the flow, or in an option that's in scope.

But you want to export the sysUpBaseTimeMilliseconds value in an option 
because you certainly you don't want to have to export the value in 
every flow, right?

That raises an interesting question concerning the change of value. If 
you're exporting some flows based on a certain value of 
sysUpBaseTimeMilliseconds, and you export an option containing an 
updated value, you must ensure that all the old flows have reached and 
been processed by the collector before the updated 
sysUpBaseTimeMilliseconds, and that the updated 
sysUpBaseTimeMilliseconds reaches the collector and is processed before 
any of the new flows. Else you risk interpreting some of the flows with 
the wrong value of sysUpBaseTimeMilliseconds.

Unless we can show how that can be done, it'd be necessary to export 
systemInitTimeMilliseconds in every flow which, as previously discussed 
at some length, is incredibly inefficient and should not be done.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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



From befdb@careerireland.com Mon Oct 30 17:25:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GefZ6-0003kq-Lm
	for ipfix-archive@lists.ietf.org; Mon, 30 Oct 2006 17:25:08 -0500
Received: from p54a54fbc.dip.t-dialin.net ([84.165.79.188])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GefZ1-0003Xw-5Z
	for ipfix-archive@lists.ietf.org; Mon, 30 Oct 2006 17:25:08 -0500
Date: Sat, 1 Jan 2000 01:24:43 -0060
From: "Twila Vance" 
X-Mailer: The Bat! (v3.0) UNREG / 77YIB4V52SDZ8OWANJ
Reply-To: "Twila Vance" 
X-Priority: 3 (Normal)
Message-ID: <2308013534.20000101012443@careerireland.com>
To: ipfix-archive@lists.ietf.org
Subject: necessary Watch out for this one
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.9 (++)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

curious about stocks and bonds and he learned that some stocks and bondsand trustworthy individual.In this progress of his father young Cowperwood definitely shared. Hewindows. There were trees in the street--plenty of them. The roadand trustworthy individual.In this progress of his father young Cowperwood definitely shared. Hewindows. There were trees in the street--plenty of them. The roadknew a number of the more prosperous merchants who dealt with his bank,banking-houses, he had come to be familiar with and favorably known in

Please read this letter attentively. Tailor AquaPonics is going to explode! It will grow up to 70%


Company: TAILOR AQUAPONICS
Stock symbol: TQWW.PK
Current price: 0.07$
Expected price: 0.26$


Check this inside review. It will be published on MARKETWIRE on the 1st of November 2006

Recent news: TQWW.PK is going to conquer the US market. TAILOR AQUAPONICS coming to America!!! 

Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based company with operations in Australia recently decided to translate its track record of success to the American market. TQWW.PK President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more people in that triangle than in the whole Australia. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." 


After the publishig of that review TQWW.PK will grow constantly for 3-4 weeks. Take it now cause it is still cheap and you can enter almost for free. 

About Tailor AquaPonics Worldwide:

Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a company that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' best quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake.


P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE".  We will be mailing TQWW.PK for the next 3 weeks and the price will icrease. It is your unique chance to double or triple your money next week. 






watch with great interest the deft exchange of bills at the brokerage



From ipfix-bounces@ietf.org Tue Oct 31 03:55:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GepMD-0004Cc-CS; Tue, 31 Oct 2006 03:52:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GepMB-00044Z-U1
	for ipfix@ietf.org; Tue, 31 Oct 2006 03:52:27 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GepDU-0007dF-MK
	for ipfix@ietf.org; Tue, 31 Oct 2006 03:43:30 -0500
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp
	[129.60.39.114])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hIYT006912;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6D17C20AE2C;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 270AB20AE28;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hHY9027378; 
	Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9V8hHad022172; Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9V8hHNN022169; Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hGS7025542;
	Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Message-ID: <45470CA2.9090406@lab.ntt.co.jp>
Date: Tue, 31 Oct 2006 17:43:14 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
	<4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com>
In-Reply-To: <4545E6DC.8090807@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear paul,

Thank you for reply,

Paul Aitken wrote:
> Hitoshi-san,
> 
>> Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
>> ---
>>   sysUpBaseTimeMilliseconds
>>
>>    Description:
>>       The absolute timestamp of the base time for flowStartSysUpTime 
>> and flowEndSysUpTime. The initial value is equal to 
>> systemInitTimeMilliseconds, and the value is updated every 49 days to 
>> prevent overflow of flowStartSysUpTime and flowEndSysUpTime.
> 
> I'd entirely remove the second sentence, since that is up to the 
> implimentation. eg, it could start with a different value (eg, in the 
> past, to export historical data). Or it could be updated every week, 
> day, hour or minute.

I do not have a sufficient reason to restrict "initial value" and "every
49 days" for update.
I want to keep description about initial value not for restricted, but 
just information.

Regarding update,
I want to keep the part of sentence "to prevent overflow of
flowStartSysUpTime and flowEndSysUpTime".
So, I want to change
"The value is updated every certain interval. The certain interval is
less than 49 days, 17 hour, 2 minutes, and 47 seconds to prevent
overflow of flowStartSysUpTime and flowEndSysUpTime."

> We should say that where it's present it's to be used in preference to 
> the systemInitTimeMilliseconds, where "present" means there's a value 
> for this IE in the flow, or in an option that's in scope.
> 
> But you want to export the sysUpBaseTimeMilliseconds value in an option 
> because you certainly you don't want to have to export the value in 
> every flow, right?

I want to export in option.

> That raises an interesting question concerning the change of value. If 
> you're exporting some flows based on a certain value of 
> sysUpBaseTimeMilliseconds, and you export an option containing an 
> updated value, you must ensure that all the old flows have reached and 
> been processed by the collector before the updated 
> sysUpBaseTimeMilliseconds, and that the updated 
> sysUpBaseTimeMilliseconds reaches the collector and is processed before 
> any of the new flows. Else you risk interpreting some of the flows with 
> the wrong value of sysUpBaseTimeMilliseconds.
> 
> Unless we can show how that can be done, it'd be necessary to export 
> systemInitTimeMilliseconds in every flow which, as previously discussed 
> at some length, is incredibly inefficient and should not be done.

I have not considered about this problem.
I think that if the option template which includes
sysUpBaseTimeMilliseconds can notify the sequence number of header of
corresponding data record which contains flowStartSysUpTime and
flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to
collector (but suitable IE does not exist in nowadays IPFIX-INFO), this
problem can be solved.

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549





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



From ipfix-bounces@ietf.org Tue Oct 31 03:55:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GepMD-0004Cc-CS; Tue, 31 Oct 2006 03:52:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GepMB-00044Z-U1
	for ipfix@ietf.org; Tue, 31 Oct 2006 03:52:27 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GepDU-0007dF-MK
	for ipfix@ietf.org; Tue, 31 Oct 2006 03:43:30 -0500
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp
	[129.60.39.114])
	by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hIYT006912;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6D17C20AE2C;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 270AB20AE28;
	Tue, 31 Oct 2006 17:43:18 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hHY9027378; 
	Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9V8hHad022172; Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	k9V8hHNN022169; Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.96])
	by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k9V8hGS7025542;
	Tue, 31 Oct 2006 17:43:17 +0900 (JST)
Message-ID: <45470CA2.9090406@lab.ntt.co.jp>
Date: Tue, 31 Oct 2006 17:43:14 +0900
From: Hitoshi Irino 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Paul Aitken 
Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow
References: <45235E1D.5000100@lab.ntt.co.jp>	<107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org>	<4524812B.2010900@lab.ntt.co.jp>	<4524FD68.8010008@cisco.com>	<45251A10.9060300@sfc.wide.ad.jp>	<3698BB5BA217DA9BAB358D82@[61.213.6.135]>	<45324C91.5090507@cisco.com>	<73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]>	<45327BD3.6090901@cisco.com>
	<940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org>
	<4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com>
	<4534C8C8.1080209@lab.ntt.co.jp>
	<13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org>
	<4534FCEF.2020807@cisco.com>
	
	<4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com>
In-Reply-To: <4545E6DC.8090807@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ipfix@ietf.org
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: ipfix-bounces@ietf.org

Dear paul,

Thank you for reply,

Paul Aitken wrote:
> Hitoshi-san,
> 
>> Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
>> ---
>>   sysUpBaseTimeMilliseconds
>>
>>    Description:
>>       The absolute timestamp of the base time for flowStartSysUpTime 
>> and flowEndSysUpTime. The initial value is equal to 
>> systemInitTimeMilliseconds, and the value is updated every 49 days to 
>> prevent overflow of flowStartSysUpTime and flowEndSysUpTime.
> 
> I'd entirely remove the second sentence, since that is up to the 
> implimentation. eg, it could start with a different value (eg, in the 
> past, to export historical data). Or it could be updated every week, 
> day, hour or minute.

I do not have a sufficient reason to restrict "initial value" and "every
49 days" for update.
I want to keep description about initial value not for restricted, but 
just information.

Regarding update,
I want to keep the part of sentence "to prevent overflow of
flowStartSysUpTime and flowEndSysUpTime".
So, I want to change
"The value is updated every certain interval. The certain interval is
less than 49 days, 17 hour, 2 minutes, and 47 seconds to prevent
overflow of flowStartSysUpTime and flowEndSysUpTime."

> We should say that where it's present it's to be used in preference to 
> the systemInitTimeMilliseconds, where "present" means there's a value 
> for this IE in the flow, or in an option that's in scope.
> 
> But you want to export the sysUpBaseTimeMilliseconds value in an option 
> because you certainly you don't want to have to export the value in 
> every flow, right?

I want to export in option.

> That raises an interesting question concerning the change of value. If 
> you're exporting some flows based on a certain value of 
> sysUpBaseTimeMilliseconds, and you export an option containing an 
> updated value, you must ensure that all the old flows have reached and 
> been processed by the collector before the updated 
> sysUpBaseTimeMilliseconds, and that the updated 
> sysUpBaseTimeMilliseconds reaches the collector and is processed before 
> any of the new flows. Else you risk interpreting some of the flows with 
> the wrong value of sysUpBaseTimeMilliseconds.
> 
> Unless we can show how that can be done, it'd be necessary to export 
> systemInitTimeMilliseconds in every flow which, as previously discussed 
> at some length, is incredibly inefficient and should not be done.

I have not considered about this problem.
I think that if the option template which includes
sysUpBaseTimeMilliseconds can notify the sequence number of header of
corresponding data record which contains flowStartSysUpTime and
flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to
collector (but suitable IE does not exist in nowadays IPFIX-INFO), this
problem can be solved.

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549





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



From akstcdynastymnsdgs@dynasty.net Tue Oct 31 19:02:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gf3Yb-0001yB-CZ; Tue, 31 Oct 2006 19:02:13 -0500
Received: from adsl196-198-223-206-196.adsl196-7.iam.net.ma ([196.206.223.198] helo=elkholti-iin86q)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gf3YT-0003bF-KP; Tue, 31 Oct 2006 19:02:13 -0500
Received: from 208.252.179.200 (HELO relay.cisp.com)
     by lists.ietf.org with esmtp (4QIUYTEX4NJA W2L1)
     id GC4R36-O92YDR-ER
     for ipcdn-archive@lists.ietf.org; Wed, 1 Dec 2006 00:02:07 0000
Date:	Wed, 1 Dec 2006 00:02:07 0000
From:	"Arlene Hubbard" 
X-Mailer: The Bat! (v1.46d) Business
X-Priority: 3 (Normal)
Message-ID: <795383472.60082596194730@thebat.net>
To: ipcdn-archive@lists.ietf.org
Subject: My dear
MIME-Version: 1.0
Content-Type: text/plain;
  charset=iso-8859-2
Content-Transfer-Encoding: 7bit
X-Spam: Not detected
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Red Reef Labs For New Manufacturing and Distribution Contract Iwn China!

Compzany red Reef Laboratowries Inc.
STOCK: RREF
Price: $0.55
Recommendation: STR ONG B UY 

RREF has just agrneed to the terms of a new manufacturing and distribution 
contract for BioClear(tm)FF. With all the nfews on RREF and it expansions 
as well as new applicatons for its prodjucts we expect to see more of this 
type of contract going in place and expandng the market for this innzovative 
companby.

RREF is pricded to buy and holding a steady price. We believe with news like 
this and up coming announcemenrts of more contracts and the soon to be 
established lab facilities in Louisoiana and the upcoming satellite labs that this 
stwocks pricee will bring great returns for its inzvestors.

Get on RREF Wednesday, November 1, 2006

I hope it was a helper.I'll email you later this week.

Arlene Hubbard.

"an easy distance, do you call it? it is nearly fifty miles."
before they  did. as the day of his arrival drew near:"the engagement between them is of a peculiar kind. from their infancy, they have been
"oh dear!-yes-certainly. i am sure lizzy will be very happy-i am sure she can have no objection.