From ipfix-bounces@ietf.org Mon Mar 3 11:35:52 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481923A699C; Mon, 3 Mar 2008 11:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nJuFQJwEsXh; Mon, 3 Mar 2008 11:35:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7213A6B04; Mon, 3 Mar 2008 11:35:45 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ED028C1EB for ; Mon, 3 Mar 2008 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3IAkC9AW5NP for ; Mon, 3 Mar 2008 11:35:38 -0800 (PST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 14FD528C19E for ; Mon, 3 Mar 2008 11:35:20 -0800 (PST) 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 m23JYiqX008605 for ; Mon, 3 Mar 2008 14:34:56 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m23JWvql008495 for ; Mon, 3 Mar 2008 14:32:57 -0500 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 m23JWvCo008493; Mon, 03 Mar 2008 14:32:57 -0500 (EST) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-32.remote.cert.org [10.25.4.32]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m23JWvZo017348; Mon, 3 Mar 2008 14:32:57 -0500 Message-Id: <1A90BBBF-6385-4CDE-ABE4-75085DF921CF@cert.org> From: Brian Trammell To: Benoit Claise In-Reply-To: <47BECB37.2070109@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 3 Mar 2008 14:32:57 -0500 References: <47B5A546.5090704@cisco.com> <47B99735.6050200@informatik.uni-tuebingen.de> <47BB0D79.7030703@cisco.com> <963EE26A-62CE-4CA8-BFF9-79412A33C176@cert.org> <47BECB37.2070109@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be used? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Cool... I've seen the posting for the new revision, and will be reading it before I arrive in Philadelphia... (I'm back from holidays, now...) - Brian On Feb 22, 2008, at 8:16 AM, Benoit Claise wrote: > Thanks Brian, > > Let me quickly update the draft based on Gerhard's and your feedback. > > Regards, Benoit. >> Benoit, Gerhard, and all, >> >> Replies inline; the most important one appears at the end, after >> Solution 1. Summary: we shouldn't change the protocol to redefine >> template scopes; it doesn't just break specific things but creates >> a new protocol; and, we should address dependent information >> sequencing at some point. >> >> On Feb 19, 2008, at 12:10 PM, Benoit Claise wrote: >> >>> Gerhard, >>> >>> You had a series of very good comments, which proves that we're >>> thinking along the same lines. >>> For the everybody's sake, let me take a step back and explain the >>> problems we try to solve by sending template per-SCTP stream. >>> This should answer some questions below, such as "What do you mean >>> by reducing the risk of losing Data Records?" >>> >>> Problem 1: >>> - when a template ID is used by multiple streams, and a template >>> withdrawal message is sent on one of the those streams, then the >>> other streams must allow enough time for the template withdrawal >>> message to reach the collector before they can reuse the template >>> ID, which is something they cannot know. >>> More importantly, the template withdrawal message cannot be sent >>> on the first stream until it knows that all the other streams have >>> transmitted their corresponding data records - which is also >>> impossible to know. >>> >>> It's true that RFC5101 specifies: >>> The Template Withdrawal Message MUST NOT be sent until sufficient >>> time has elapsed to allow the Collecting Process to receive and >>> process the last Data Record using this Template information. >>> This >>> time MUST be configurable. A suitable default value is 5 seconds >>> after the last Data Record has been sent. >>> But it's not always possible to guarantee that 5 seconds is >>> enough. So we might lose data records. >> >> Indeed. Template withdrawals (like UDP) are dangerous, and in an >> ideal situation should not be used at all. They won't work reliably >> in the general-case, flexible multistream environment. But >> sometimes you'll get yourself into a situation where you need to >> withdraw templates, for whatever reason. So we give guidelines, as >> above, to minimize the damage should an exporter choose to use this >> feature. >> >> (Aside: if data record loss avoidance is a prime requirement, use >> TCP or single-stream reliable SCTP.) >> >> (Aside, aside: Can someone provide 1. the count of templates you're >> expecting to use within a single transport session and 2. example >> expected use cases for template withdrawals? In theory all this is >> broken, I agree, but I still can't really see situations where all >> these various template withdrawal problems will arise in the Real >> World (tm).) >> >>> More generic problem: >>> Problems 1 and 2 are different problems, but with the same cause: >>> the problems come from data records from the same template ID sent >>> across different streams. Typically, the PSAMP option template >>> record for sampling. >> >> More generically still, the problems come from dependencies between >> IPFIX messages sent without sequencing guarantees. See comment on >> Solution 3 below. >> >>> This is a current limitation/problem with IPFIX >>> We evaluated whether we can propose some improvements part of this >>> per-SCTP draft, even if the per-SCTP draft goal was to export one >>> template per stream to be able to deduce the data loss for each >>> template record. >>> >>> There are a couple of solutions, with the solution 1 being the >>> preferred one. Hence the reverse order. >>> >>> Solution 3: >>> As explained by Gehrard, look at the export time in the template >>> records, data records, and template withdrawal message. >>> - This implies a more complex collecting process implementation as >>> the old and new template records must kept to compare the time >>> Note: potentially more than two template records must be kept if >>> the definition of the template ID changes frequently >>> - This implies that we loose the real-time decode, as the >>> collecting process must wait for a certain time, just in case a >>> delayed template withdrawal message and a new template record is >>> received. For this reason only, I think this solution is poor >>> - What if data record and template withdraw message were in the >>> same IPFIX message? Probably it'd depend on the order within the >>> message. >> >> The CP should be looking at export time when evaluating information >> dependencies (scoped options, templates), anyway. This is >> completely ignored by the protocol (though in retrospect perhaps it >> should have been), but there are really only two temporal scoping >> policies that make sense: >> >> 1. If dependencies cannot be withdrawn, then it can be held to be >> valid for the entirety of its enclosing outer scope (the transport >> session). In this case, ordering within the session is completely >> unimportant. This is pretty much, by default, how 5101 treats >> things, and I think how we think about these things on the list. >> >> 2. If dependencies may we withdrawn _AND REDEFINED_ (which is the >> point of template withdrawals, after all), then the ordering of >> these operations is critically important. Since ordering is >> important _across_ streams, we can't use the sequence number. The >> only sync signal we have that works across all streams is the >> export time. >> >> Actually building out a consistent set of rules for handling >> dependent information could, I think, be done without changing the >> wire protocol or the EP at all; it could basically be a set of CP >> guidelines. Though I haven't thought all the way through the >> problem to be able to say that with much confidence, yet. IIRC >> Andrew and I discussed something along these lines in the form of a >> "scope user's guide" way back in San Diego, but haven't had a >> chance to do anything with it since then. >> >>> Solution 2 >>> We could propose a series of specifications that would reduce the >>> likelihood that problem 1 or 2 would happen >>> - transmission order is maintained within a stream >>> - redefinition of the Template ID is not encouraged >>> - template withdrawal message SHOULD be sent in the last used >>> stream that carried the template ID to be removed >>> - etc.. >>> The drawback of this solution is that, even if the likelihood is >>> reduced, there is no guarantee that the problem 1 and 2 will not >>> happen. >>> When I posted the initial email from this thread, I was still >>> thinking along this solution 2 >> >> Something along the lines of this solution is, I think, as good as >> we can do, in view of the issues with solution 1; see below. >> >> An EP using the per-stream technique will not lose data records due >> to template withdrawals or template synchronization issues. This is >> an advantage of using per-stream. But per-stream is an option; a >> technique applicable to certain use cases that has specific >> advantages in those cases. It uses each template only on a single >> stream, and each stream has only a single template, but that is >> simply the EP's prerogative, not a property of the protocol. >> >> An EP not using template withdrawals at all will not lose data >> records due to template withdrawals, trivially. >> >> An EP choosing to use template withdrawals and cross-stream >> template definitions may generate a message stream it is difficult >> but not impossible for the CP to process without record loss. 5101 >> provides guidelines and warnings to this effect already. >> >> (Again, data loss avoidance is _one_ requirement -- one policy -- >> that the mechanisms of the IPFIX protocol can be used to implement. >> It is not always of the utmost importance; otherwise we wouldn't >> support UDP and PR-SCTP.) >> >>> Solution 1 >>> The template IDs are scoped per stream, next to the the Transport >>> Session and Observation Domain that generated the Template ID. >>> Next to that, the transmission order per stream is maintained >>> In this case, problem 1 and problem 2 will never happen >>> The drawbacks are that >>> - more template ID and records would be usedFrom ipfix-bounces@ietf.org Mon Mar 3 11:35:52 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481923A699C; Mon, 3 Mar 2008 11:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nJuFQJwEsXh; Mon, 3 Mar 2008 11:35:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7213A6B04; Mon, 3 Mar 2008 11:35:45 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ED028C1EB for ; Mon, 3 Mar 2008 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3IAkC9AW5NP for ; Mon, 3 Mar 2008 11:35:38 -0800 (PST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 14FD528C19E for ; Mon, 3 Mar 2008 11:35:20 -0800 (PST) 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 m23JYiqX008605 for ; Mon, 3 Mar 2008 14:34:56 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m23JWvql008495 for ; Mon, 3 Mar 2008 14:32:57 -0500 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 m23JWvCo008493; Mon, 03 Mar 2008 14:32:57 -0500 (EST) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-32.remote.cert.org [10.25.4.32]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m23JWvZo017348; Mon, 3 Mar 2008 14:32:57 -0500 Message-Id: <1A90BBBF-6385-4CDE-ABE4-75085DF921CF@cert.org> From: Brian Trammell To: Benoit Claise In-Reply-To: <47BECB37.2070109@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 3 Mar 2008 14:32:57 -0500 References: <47B5A546.5090704@cisco.com> <47B99735.6050200@informatik.uni-tuebingen.de> <47BB0D79.7030703@cisco.com> <963EE26A-62CE-4CA8-BFF9-79412A33C176@cert.org> <47BECB37.2070109@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be used? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Cool... I've seen the posting for the new revision, and will be reading it before I arrive in Philadelphia... (I'm back from holidays, now...) - Brian On Feb 22, 2008, at 8:16 AM, Benoit Claise wrote: > Thanks Brian, > > Let me quickly update the draft based on Gerhard's and your feedback. > > Regards, Benoit. >> Benoit, Gerhard, and all, >> >> Replies inline; the most important one appears at the end, after >> Solution 1. Summar. For example, the >>> sampling option template record would require >>> one template ID per stream and the export the "same" data >>> record values per stream >>> - "reducing redundancy" draft would not work across stream. Is >>> this a big issue, I don't know! >> >> Indeed, this would cause options template records used for other >> than MP/EP metadata export (as in RFC5103, ipfix-exporting-type, >> ipfix-reducing-redundancy) not to work across streams. >> >> I agree with Gerhard (in his reply to this message): we shouldn't >> change the protocol. And this proposal does define a new protocol. >> RFC 5103 EPs would be incapable of interoperating with CPs that >> failed to interpret cross-stream templates. 5103 CPs would be >> incapable of interoperating with EPs that caused template collision. >> >> I would also repeat strenuously my warnings from the last time we >> visited this proposal (around the Chicago meeting last year) not to >> introduce restrictions or changes into the protocol that apply only >> to certain use cases and policies implementable with the greater >> protocol. >> >>> Note that there is a simple solution to address those two >>> drawbacks: never send a template withdrawal message, and make >>> those template IDs permanent as long as the SCTP association is >>> up. Nothing is changed on the collector side specifications, as it >>> doesn't have to know that the template IDs are permanent >>> >>> Now, the real question in this solution 1 is: what to do if we >>> can't increase anymore the number of streams in the SCTP >>> association? >>> We export all the newly created template IDs and the associated >>> data records on the stream 0 (as currently specified in the per- >>> SCTP stream) >>> Overloading the stream 0 is not an issue as the SCTP design is >>> such that there is one pool of buffer and all streams will share >>> it, i.e. "if you send 100k in one stream.. or 100k spread over >>> all streams.. it makes no difference" dixit Randy Stewart. >>> Note: stream 0 is mentioned for historical but could very well be >>> another one. I'm not even sure we even need to specify a certain >>> stream >>> Note that on that stream 0, we can't deduce the loss per template. >> >> Hmm. per-stream should also provide guidelines that it works best >> in cases where you have enough streams to handle all your templates. >> >> Cheers, >> >> Brian > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix y: we shouldn't change the protocol to redefine >> template scopes; it doesn't just break specific things but creates >> a new protocol; and, we should address dependent information >> sequencing at some point. >> >> On Feb 19, 2008, at 12:10 PM, Benoit Claise wrote: >> >>> Gerhard, >>> >>> You had a series of very good comments, which proves that we're >>> thinking along the same lines. >>> For the everybody's sake, let me take a step back and explain the >>> problems we try to solve by sending template per-SCTP stream. >>> This should answer some questions below, such as "What do you mean >>> by reducing the risk of losing Data Records?" >>> >>> Problem 1: >>> - when a template ID is used by multiple streams, and a template >>> withdrawal message is sent on one of the those streams, then the >>> other streams must allow enough time for the template withdrawal >>> message to reach the collector before they can reuse the template >>> ID, which is something they cannot know. >>> More importantly, the template withdrawal message cannot be sent >>> on the first stream until it knows that all the other streams have >>> transmitted their corresponding data records - which is also >>> impossible to know. >>> >>> It's true that RFC5101 specifies: >>> The Template Withdrawal Message MUST NOT be sent until sufficient >>> time has elapsed to allow the Collecting Process to receive and >>> process the last Data Record using this Template information. >>> This >>> time MUST be configurable. A suitable default value is 5 seconds >>> after the last Data Record has been sent. >>> But it's not always possible to guarantee that 5 seconds is >>> enough. So we might lose data records. >> >> Indeed. Template withdrawals (like UDP) are dangerous, and in an >> ideal situation should not be used at all. They won't work reliably >> in the general-case, flexible multistream environment. But >> sometimes you'll get yourself into a situation where you need to >> withdraw templates, for whatever reason. So we give guidelines, as >> above, to minimize the damage should an exporter choose to use this >> feature. >> >> (Aside: if data record loss avoidance is a prime requirement, use >> TCP or single-stream reliable SCTP.) >> >> (Aside, aside: Can someone provide 1. the count of templates you're >> expecting to use within a single transport session and 2. example >> expected use cases for template withdrawals? In theory all this is >> broken, I agree, but I still can't really see situations where all >> these various template withdrawal problems will arise in the Real >> World (tm).) >> >>> More generic problem: >>> Problems 1 and 2 are different problems, but with the same cause: >>> the problems come from data records from the same template ID sent >>> across different streams. Typically, the PSAMP option template >>> record for sampling. >> >> More generically still, the problems come from dependencies between >> IPFIX messages sent without sequencing guarantees. See comment on >> Solution 3 below. >> >>> This is a current limitation/problem with IPFIX >>> We evaluated whether we can propose some improvements part of this >>> per-SCTP draft, even if the per-SCTP draft goal was to export one >>> template per stream to be able to deduce the data loss for each >>> template record. >>> >>> There are a couple of solutions, with the solution 1 being the >>> preferred one. Hence the reverse order. >>> >>> Solution 3: >>> As explained by Gehrard, look at the export time in the template >>> records, data records, and template withdrawal message. >>> - This implies a more complex collecting process implementation as >>> the old and new template records must kept to compare the time >>> Note: potentially more than two template records must be kept if >>> the definition of the template ID changes frequently >>> - This implies that we loose the real-time decode, as the >>> collecting process must wait for a certain time, just in case a >>> delayed template withdrawal message and a new template record is >>> received. For this reason only, I think this solution is poor >>> - What if data record and template withdraw message were in the >>> same IPFIX message? Probably it'd depend on the order within the >>> message. >> >> The CP should be looking at export time when evaluating information >> dependencies (scoped options, templates), anyway. This is >> completely ignored by the protocol (though in retrospect perhaps it >> should have been), but there are really only two temporal scoping >> policies that make sense: >> >> 1. If dependencies cannot be withdrawn, then it can be held to be >> valid for the entirety of its enclosing outer scope (the transport >> session). In this case, ordering within the session is completely >> unimportant. This is pretty much, by default, how 5101 treats >> things, and I think how we think about these things on the list. >> >> 2. If dependencies may we withdrawn _AND REDEFINED_ (which is the >> point of template withdrawals, after all), then the ordering of >> these operations is critically important. Since ordering is >> important _across_ streams, we can't use the sequence number. The >> only sync signal we have that works across all streams is the >> export time. >> >> Actually building out a consistent set of rules for handling >> dependent information could, I think, be done without changing the >> wire protocol or the EP at all; it could basically be a set of CP >> guidelines. Though I haven't thought all the way through the >> problem to be able to say that with much confidence, yet. IIRC >> Andrew and I discussed something along these lines in the form of a >> "scope user's guide" way back in San Diego, but haven't had a >> chance to do anything with it since then. >> >>> Solution 2 >>> We could propose a series of specifications that would reduce the >>> likelihood that problem 1 or 2 would happen >>> - transmission order is maintained within a stream >>> - redefinition of the Template ID is not encouraged >>> - template withdrawal message SHOULD be sent in the last used >>> stream that carried the template ID to be removed >>> - etc.. >>> The drawback of this solution is that, even if the likelihood is >>> reduced, there is no guarantee that the problem 1 and 2 will not >>> happen. >>> When I posted the initial email from this thread, I was still >>> thinking along this solution 2 >> >> Something along the lines of this solution is, I think, as good as >> we can do, in view of the issues with solution 1; see below. >> >> An EP using the per-stream technique will not lose data records due >> to template withdrawals or template synchronization issues. This is >> an advantage of using per-stream. But per-stream is an option; a >> technique applicable to certain use cases that has specific >> advantages in those cases. It uses each template only on a single >> stream, and each stream has only a single template, but that is >> simply the EP's prerogative, not a property of the protocol. >> >> An EP not using template withdrawals at all will not lose data >> records due to template withdrawals, trivially. >> >> An EP choosing to use template withdrawals and cross-stream >> template definitions may generate a message stream it is difficult >> but not impossible for the CP to process without record loss. 5101 >> provides guidelines and warnings to this effect already. >> >> (Again, data loss avoidance is _one_ requirement -- one policy -- >> that the mechanisms of the IPFIX protocol can be used to implement. >> It is not always of the utmost importance; otherwise we wouldn't >> support UDP and PR-SCTP.) >> >>> Solution 1 >>> The template IDs are scoped per stream, next to the the Transport >>> Session and Observation Domain that generated the Template ID. >>> Next to that, the transmission order per stream is maintained >>> In this case, problem 1 and problem 2 will never happen >>> The drawbacks are that >>> - more template ID and records would be used. For example, the >>> sampling option template record would require >>> one template ID per stream and the export the "same" data >>> record values per stream >>> - "reducing redundancy" draft would not work across stream. Is >>> this a big issue, I don't know! >> >> Indeed, this would cause options template records used for other >> than MP/EP metadata export (as in RFC5103, ipfix-exporting-type, >> ipfix-reducing-redundancy) not to work across streams. >> >> I agree with Gerhard (in his reply to this message): we shouldn't >> change the protocol. And this proposal does define a new protocol. >> RFC 5103 EPs would be incapable of interoperating with CPs that >> failed to interpret cross-stream templates. 5103 CPs would be >> incapable of interoperating with EPs that caused template collision. >> >> I would also repeat strenuously my warnings from the last time we >> visited this proposal (around the Chicago meeting last year) not to >> introduce restrictions or changes into the protocol that apply only >> to certain use cases and policies implementable with the greater >> protocol. >> >>> Note that there is a simple solution to address those two >>> drawbacks: never send a template withdrawal message, and make >>> those template IDs permanent as long as the SCTP association is >>> up. Nothing is changed on the collector side specifications, as it >>> doesn't have to know that the template IDs are permanent >>> >>> Now, the real question in this solution 1 is: what to do if we >>> can't increase anymore the number of streams in the SCTP >>> association? >>> We export all the newly created template IDs and the associated >>> data records on the stream 0 (as currently specified in the per- >>> SCTP stream) >>> Overloading the stream 0 is not an issue as the SCTP design is >>> such that there is one pool of buffer and all streams will share >>> it, i.e. "if you send 100k in one stream.. or 100k spread over >>> all streams.. it makes no difference" dixit Randy Stewart. >>> Note: stream 0 is mentioned for historical but could very well be >>> another one. I'm not even sure we even need to specify a certain >>> stream >>> Note that on that stream 0, we can't deduce the loss per template. >> >> Hmm. per-stream should also provide guidelines that it works best >> in cases where you have enough streams to handle all your templates. >> >> Cheers, >> >> Brian > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 3 11:56:47 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785733A6C1B; Mon, 3 Mar 2008 11:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAZKq5JeQOeA; Mon, 3 Mar 2008 11:56:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021673A6ABB; Mon, 3 Mar 2008 11:56:42 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7F53A6ABB for ; Mon, 3 Mar 2008 11:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y24RTfAh5+S2 for ; Mon, 3 Mar 2008 11:56:40 -0800 (PST) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 5C2E03A6BA4 for ; Mon, 3 Mar 2008 11:56:40 -0800 (PST) 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 m23JuPop018251 for ; Mon, 3 Mar 2008 14:56:25 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m23Ju2Di018224 for ; Mon, 3 Mar 2008 14:56:02 -0500 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 m23Ju2Nm018222; Mon, 03 Mar 2008 14:56:02 -0500 (EST) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-32.remote.cert.org [10.25.4.32]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m23Ju2J7022111; Mon, 3 Mar 2008 14:56:02 -0500 Message-Id: <975E1450-791E-43F1-B68E-2D391433C7B9@cert.org> From: Brian Trammell To: Paul Aitken In-Reply-To: <47BE17CF.1060703@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 3 Mar 2008 14:56:01 -0500 References: <47B5A546.5090704@cisco.com> <47B99735.6050200@informatik.uni-tuebingen.de> <47BB0D79.7030703@cisco.com> <963EE26A-62CE-4CA8-BFF9-79412A33C176@cert.org> <47BE17CF.1060703@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Per-SCTP stream draft: New Template ID SHOULD/MUST be used? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Feb 21, 2008, at 7:31 PM, Paul Aitken wrote: > Brian, > >> The CP should be looking at export time when evaluating information >> dependencies (scoped options, templates), anyway. This is >> completely ignored by the protocol > > If you do that, then you'd have to store all the received data records > undecoded for a certain amount of time - even if you have a valid > template to decode them - against the slight possibility of a TWM and > new template definition with an earlier timestamp being received from > another stream. > > Which means you lose the ability to decode data in real time. > Yes, but note that you lose the ability to decode data in real time if and only if zero information loss in an environment in which withdrawals and dynamic template allocation are in use with multiple arbitrary streams is an inviolable requirement. >> IIRC Andrew and I discussed something along these lines in the form >> of a "scope user's guide" way back in San Diego > > If templates contained a valid-from and a valid-to timestamp, with a > guarantee they'd not be withdrawn or redefined within that window, > then > you could decode in real time once again. True indeed. Of course, right now the only way to add such information to the templates is via options, so there's still a bit of a bootstrapping problem here... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 3 11:56:47 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785733A6C1B; Mon, 3 Mar 2008 11:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAZKq5JeQOeA; Mon, 3 Mar 2008 11:56:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021673A6ABB; Mon, 3 Mar 2008 11:56:42 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7F53A6ABB for ; Mon, 3 Mar 2008 11:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y24RTfAh5+S2 for ; Mon, 3 Mar 2008 11:56:40 -0800 (PST) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 5C2E03A6BA4 for ; Mon, 3 Mar 2008 11:56:40 -0800 (PST) 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 m23JuPop018251 for ; Mon, 3 Mar 2008 14:56:25 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m23Ju2Di018224 for ; Mon, 3 Mar 2008 14:56:02 -0500 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 m23Ju2Nm018222; Mon, 03 Mar 2008 14:56:02 -0500 (EST) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-32.remote.cert.org [10.25.4.32]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m23Ju2J7022111; Mon, 3 Mar 2008 14:56:02 -0500 Message-Id: <975E1450-791E-43F1-B68E-2D391433C7B9@cert.org> From: Brian Trammell To: Paul Aitken In-Reply-To: <47BE17CF.1060703@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 3 Mar 2008 14:56:01 -0500 References: <47B5A546.5090704@cisco.com> <47B99735.6050200@informatik.uni-tuebingen.de> <47BB0D79.7030703@cisco.com> <963EE26A-62CE-4CA8-BFF9-79412A33C176@cert.org> <47BE17CF.1060703@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Per-SCTP stream draft: New Template ID SHOULD/MUST be used? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Feb 21, 2008, at 7:31 PM, Paul Aitken wrote: > Brian, > >> The CP should be looking at export time when evaluating information >> dependencies (scoped options, templates), anyway. This is >> completely ignored by the protocol > > If you do that, then you'd have to store all the received data records > undecoded for a certain amount of time - even if you have a valid > template to decode them - against the slight possibility of a TWM and > new template definition with an earlier timestamp being received from > another stream. > > Which means you lose the ability to decode data in real time. > Yes, but note that you lose the ability to decode data in real time if and only if zero information loss in an environment in which withdrawals and dynamic template allocation are in use with multiple arbitrary streams is an inviolable requirement. >> IIRC Andrew and I discussed something along these lines in the form >> of a "scope user's guide" way back in San Diego > > If templates contained a valid-from and a valid-to timestamp, with a > guarantee they'd not be withdrawn or redefined within that window, > then > you could decode in real time once again. True indeed. Of course, right now the only way to add such information to the templates is via options, so there's still a bit of a bootstrapping problem here... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 3 14:11:44 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF02E28C3B3; Mon, 3 Mar 2008 14:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBZTe3bJ0j4N; Mon, 3 Mar 2008 14:11:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160D828C1CE; Mon, 3 Mar 2008 14:11:39 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3665228C18D for ; Mon, 3 Mar 2008 14:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW0T1uRtrQ4O for ; Mon, 3 Mar 2008 14:11:37 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 10AE13A6A23 for ; Mon, 3 Mar 2008 14:11:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9B272185E8 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAvio8O6Q2G7 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 76B9D185B5 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: IETF IPFIX Working Group From: Nevil Brownlee Date: Tue, 4 Mar 2008 11:11:23 +1300 X-Mailer: Apple Mail (2.753) Subject: [IPFIX] Agenda for Philadelphia IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Here's the next draft of our agenda; please can those who are presenting send me or Juergen a copy of your slides by Tuesday morning, 11 March. Or earlier, if possible. See you in Philadelphia, Nevil --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #71, Philadelphia Tuesday, 11 March 08 at 1740-1950 ====================================================== Chairs: Nevil Brownlee Juergen QFrom ipfix-bounces@ietf.org Mon Mar 3 14:11:44 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF02E28C3B3; Mon, 3 Mar 2008 14:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBZTe3bJ0j4N; Mon, 3 Mar 2008 14:11:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160D828C1CE; Mon, 3 Mar 2008 14:11:39 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3665228C18D for ; Mon, 3 Mar 2008 14:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW0T1uRtrQ4O for ; Mon, 3 Mar 2008 14:11:37 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 10AE13A6A23 for ; Mon, 3 Mar 2008 14:11:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9B272185E8 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAvio8O6Q2G7 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 76B9D185B5 for ; Tue, 4 Mar 2008 11:11:25 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: IETF IPFIX Working Group From: Nevil Brownlee Date: Tue, 4 Mar 2008 11:11:23 +1300 X-Mailer: Apple Mail (2.753) Subject: [IPFIX] Agenda for Philadelphia IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Here's the next draft of our agenda; please can those who are presenting send me or Juergen a copy of your slides by Tuesday morning, 11 March. Or earlier, if possible. See you in Philadelphia, Nevil --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #71, Philadelphia Tuesday, 11 March 08 at 1740-1950 ====================================================== Chairs: Nevil Brownlee Juergen Quittek AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status = 9 min [Published: - RFC 5101 IPFIX Protocol - RFC 5102 IPFIX Information Model - RFC 5103 IPFIX Biflows In RFC Editor queue: - draft-ietf-ipfix-implementation-guidelines-08.txt (AUTH48) - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt In IETF Last Call: - draft-ietf-ipfix-testing-04.txt ] - draft-ietf-psamp-framework-12.txt [Nick Duffield] Jun 07 - draft-ietf-psamp-sample-tech-10.txt [Tanja Zseby] Jun 07 - draft-ietf-psamp-protocol-09.txt [Benoit Claise] Dec 07 - draft-ietf-psamp-info-07.txt [Thomas Dietz] Oct 07 3. Drafts from the old charter .. =10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-03.txt Feb 08 4. New WG drafts =26 min Two new WG drafts, as agreed on the list after IETF 70: a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-01.txt b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-00.txt ( 5 min) Two more drafts that need to be accepted as WG items: [These need support/consensus, demonstrated by having 3 or more people who'll read and review them] a) Configuration Data Model ( 8 min) - draft-muenz-ipfix-configuration-04.txt b) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 8 min) - draft-claise-ipfix-export-per-sctp-stream-03.txt 5. IPFIX Mediation =50 min a) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) (30 min) - draft-kobayashi-ipfix-large-ps-01.txt "Problems with Flow Collection in Large-Scale Networks" b) IPFIX Mediation: Framework - draft-kobayashi-ipfix-mediator-model-02.txt (20 min) [- draft-dressler-ipfix-aggregation-04.txt] We need to decide how to proceed with the WG's 'Mediation Framework' draft 6. Other Drafts =15 min a) New IEs for the IPFIX Information Model (Paul Aitken) - draft-aitken-ipfix-new-infos-01.txt (10 min) b) Order of Information Elements (Hitoshi Irino) - draft-irino-ipfix-ie-order-04.txt ( 5 min) 7. Any Other Business = 5 min 8. Wrap up, milestone review =10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=71 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix uittek AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status = 9 min [Published: - RFC 5101 IPFIX Protocol - RFC 5102 IPFIX Information Model - RFC 5103 IPFIX Biflows In RFC Editor queue: - draft-ietf-ipfix-implementation-guidelines-08.txt (AUTH48) - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt In IETF Last Call: - draft-ietf-ipfix-testing-04.txt ] - draft-ietf-psamp-framework-12.txt [Nick Duffield] Jun 07 - draft-ietf-psamp-sample-tech-10.txt [Tanja Zseby] Jun 07 - draft-ietf-psamp-protocol-09.txt [Benoit Claise] Dec 07 - draft-ietf-psamp-info-07.txt [Thomas Dietz] Oct 07 3. Drafts from the old charter .. =10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-03.txt Feb 08 4. New WG drafts =26 min Two new WG drafts, as agreed on the list after IETF 70: a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-01.txt b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-00.txt ( 5 min) Two more drafts that need to be accepted as WG items: [These need support/consensus, demonstrated by having 3 or more people who'll read and review them] a) Configuration Data Model ( 8 min) - draft-muenz-ipfix-configuration-04.txt b) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 8 min) - draft-claise-ipfix-export-per-sctp-stream-03.txt 5. IPFIX Mediation =50 min a) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) (30 min) - draft-kobayashi-ipfix-large-ps-01.txt "Problems with Flow Collection in Large-Scale Networks" b) IPFIX Mediation: Framework - draft-kobayashi-ipfix-mediator-model-02.txt (20 min) [- draft-dressler-ipfix-aggregation-04.txt] We need to decide how to proceed with the WG's 'Mediation Framework' draft 6. Other Drafts =15 min a) New IEs for the IPFIX Information Model (Paul Aitken) - draft-aitken-ipfix-new-infos-01.txt (10 min) b) Order of Information Elements (Hitoshi Irino) - draft-irino-ipfix-ie-order-04.txt ( 5 min) 7. Any Other Business = 5 min 8. Wrap up, milestone review =10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=71 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:31:19 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A8D28C108; Sat, 8 Mar 2008 06:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.527 X-Spam-Level: X-Spam-Status: No, score=-99.527 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhGrJk2a7ub1; Sat, 8 Mar 2008 06:31:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593CD28C495; Sat, 8 Mar 2008 06:16:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6C428CA2E for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW4eoZis+M-v for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DC1C53A6CA9 for ; Sat, 8 Mar 2008 05:35:14 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28D9Xol048368 for ; Sat, 8 Mar 2008 22:09:34 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 22:09:39 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308220936.7AAE.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 22:09:35 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A8D28C108; Sat, 8 Mar 2008 06:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.527 X-Spam-Level: X-Spam-Status: No, score=-99.527 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhGrJk2a7ub1; Sat, 8 Mar 2008 06:31:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593CD28C495; Sat, 8 Mar 2008 06:16:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6C428CA2E for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW4eoZis+M-v for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DC1C53A6CA9 for ; Sat, 8 Mar 2008 05:35:14 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28D9Xol048368 for ; Sat, 8 Mar 2008 22:09:34 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 22:09:39 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308220936.7AAE.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 22:09:35 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M〓z > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix k.uni-tuebingen.de> wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M〓z > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:31:20 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A4C28C33A; Sat, 8 Mar 2008 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.858 X-Spam-Level: X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIt4QAK1oH9x; Sat, 8 Mar 2008 06:31:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE48A3A6CB1; Sat, 8 Mar 2008 06:16:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BA428D2A1 for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk96uKx48jXq for ; Sat, 8 Mar 2008 06:15:59 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7B35628D6C5 for ; Sat, 8 Mar 2008 05:35:12 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28DG6ZJ048407 for ; Sat, 8 Mar 2008 22:16:07 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 22:16:12 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308221536.7AB7.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 22:16:08 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A4C28C33A; Sat, 8 Mar 2008 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.858 X-Spam-Level: X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIt4QAK1oH9x; Sat, 8 Mar 2008 06:31:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE48A3A6CB1; Sat, 8 Mar 2008 06:16:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BA428D2A1 for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk96uKx48jXq for ; Sat, 8 Mar 2008 06:15:59 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7B35628D6C5 for ; Sat, 8 Mar 2008 05:35:12 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28DG6ZJ048407 for ; Sat, 8 Mar 2008 22:16:07 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 22:16:12 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308221536.7AB7.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 22:16:08 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard Mz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ni-tuebingen.de> wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard Mz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:32:29 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CA228CA9C; Sat, 8 Mar 2008 06:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.947 X-Spam-Level: X-Spam-Status: No, score=-99.947 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2kIZdHgXK7N; Sat, 8 Mar 2008 06:32:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D8828D605; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798D728CFAD for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkdgRip263p0 for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 613B128D44F for ; Sat, 8 Mar 2008 05:35:19 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CSXVk048143; Sat, 8 Mar 2008 21:28:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:28:44 +0900 From: Kobayashi Atsushi To: Gerhard Muenz In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308210634.7A99.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:28:39 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032545982==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0032545982== Content-Type: text/plain; charset="Shift_JIS" Content-Transfer-Encoding: quoted-printable Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. =20 I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type=20 In addition, it allows "selectionProcess_type" to include "AccessListMatch" element.=20 What do you think about that? I think that it enhances flexibility as optional.=20 Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: >=20 > Dear all, >=20 > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.tx= t >=20 > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. >=20 > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. >=20 > Regards, > Gerhard >=20 > --=20 > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz >=20 ---=20 Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 --===============0032545982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0032545982==-- From ipfix-bounces@ietf.org Sat Mar 8 06:32:29 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CA228CA9C; Sat, 8 Mar 2008 06:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.947 X-Spam-Level: X-Spam-Status: No, score=-99.947 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2kIZdHgXK7N; Sat, 8 Mar 2008 06:32:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D8828D605; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798D728CFAD for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkdgRip263p0 for ; Sat, 8 Mar 2008 06:16:01 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 613B128D44F for ; Sat, 8 Mar 2008 05:35:19 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CSXVk048143; Sat, 8 Mar 2008 21:28:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:28:44 +0900 From: Kobayashi Atsushi To: Gerhard Muenz In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308210634.7A99.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:28:39 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032545982==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0032545982== Content-Type: text/plain; charset="Shift_JIS" Content-Transfer-Encoding: quoted-printable Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. =20 I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type=20 In addition, it allows "selectionProcess_type" to include "AccessListMatch" element.=20 What do you think about that? I think that it enhances flexibility as optional.=20 Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: >=20 > Dear all, >=20 > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.tx= t >=20 > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. >=20 > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. >=20 > Regards, > Gerhard >=20 > --=20 > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz >=20 ---=20 Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 --===============0032545982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0032545982==-- From ipfix-bounces@ietf.org Sat Mar 8 06:33:01 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB8128CB31; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kytv-F9UcaXN; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ECB28E39D; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B3B28CB51 for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg7ehzF-3AnR for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 3D2BE3A69C8 for ; Sat, 8 Mar 2008 05:35:15 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CvdcV048304 for ; Sat, 8 Mar 2008 21:57:40 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:57:46 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308215548.7AA5.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:57:41 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M〓z > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:33:01 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB8128CB31; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kytv-F9UcaXN; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ECB28E39D; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B3B28CB51 for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg7ehzF-3AnR for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 3D2BE3A69C8 for ; Sat, 8 Mar 2008 05:35:15 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CvdcV048304 for ; Sat, 8 Mar 2008 21:57:40 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:57:46 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308215548.7AA5.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:57:41 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. What do you think about that? I think that it enhances flexibility as optional. Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > > Dear all, > > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M〓z > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:33:02 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0FA28CBB3; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSzo+KPpG3IQ; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B79128E391; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA7628C495 for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1sMsIN9h-Hs for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id AB3D428CC9A for ; Sat, 8 Mar 2008 05:35:17 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28Crffx048274 for ; Sat, 8 Mar 2008 21:53:42 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:53:47 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308214201.7AA2.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:53:43 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. = I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type = In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. = What do you think about that? I think that it enhances flexibility as optional. = Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > = > Dear all, > = > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > = > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > = > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > = > Regards, > Gerhard > = > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > = --- = Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:33:02 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0FA28CBB3; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSzo+KPpG3IQ; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B79128E391; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA7628C495 for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1sMsIN9h-Hs for ; Sat, 8 Mar 2008 06:16:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id AB3D428CC9A for ; Sat, 8 Mar 2008 05:35:17 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28Crffx048274 for ; Sat, 8 Mar 2008 21:53:42 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:53:47 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308214201.7AA2.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:53:43 +0900 (JST) Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. = I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type = In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. = What do you think about that? I think that it enhances flexibility as optional. = Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > = > Dear all, > = > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > = > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > = > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > = > Regards, > Gerhard > = > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > = --- = Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:33:02 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2C828CBC5; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5OF9qoC9qof; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF9028E3A6; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C364E28CC9A for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKtwcY5fjgiq for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id E2D3028CC67 for ; Sat, 8 Mar 2008 05:35:20 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CUQRG048158; Sat, 8 Mar 2008 21:30:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:30:32 +0900 From: Kobayashi Atsushi To: Gerhard Muenz In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308212938.7A9F.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:30:28 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. = I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type = In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. = What do you think about that? I think that it enhances flexibility as optional. = Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > = > Dear all, > = > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > = > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > = > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > = > Regards, > Gerhard > = > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > = --- = Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Mar 8 06:33:02 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2C828CBC5; Sat, 8 Mar 2008 06:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5OF9qoC9qof; Sat, 8 Mar 2008 06:32:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF9028E3A6; Sat, 8 Mar 2008 06:16:05 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C364E28CC9A for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKtwcY5fjgiq for ; Sat, 8 Mar 2008 06:16:02 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id E2D3028CC67 for ; Sat, 8 Mar 2008 05:35:20 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m28CUQRG048158; Sat, 8 Mar 2008 21:30:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 08 Mar 2008 21:30:32 +0900 From: Kobayashi Atsushi To: Gerhard Muenz In-Reply-To: <47C2F1CD.5020407@informatik.uni-tuebingen.de> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> Message-Id: <20080308212938.7A9F.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sat, 08 Mar 2008 21:30:28 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Benoit and all, This draft is almost complete and great work. I think that such XML configuration enhances efficiency of the use of flexibility of IPFIX. IMHO, I am afraid that the filtering method is different than current ACL implemented in several routers. Therefore, the IPFIX XML cfg might not be implemented, because of the gap between current ACL filter and IPFIX XML cfg, even if psamp mention "AND" operation only. = I propose the following XML schema added the ACL elements to -03 draft. I am not familiar with YANG yet, sorry. http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html The following Complex/Simple type elements are added. - Complex Type: accessListMatch_type - Complex Type: sequenceList_type - Simple Type: action_type = In addition, it allows "selectionProcess_type" to include "AccessListMatch" element. = What do you think about that? I think that it enhances flexibility as optional. = Regards, Atsushi KOBAYASHI On Mon, 25 Feb 2008 17:50:21 +0100 Gerhard Muenz wrote: > = > Dear all, > = > A new revision of the IPFIX/PSAMP configuration data model has been > published: > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > = > Apart from smaller changes in the model itself, the big change compared > to the previous version concerns the specification language: instead of > XML Schema, we now use YANG, a new language for modelling Netconf data > models. As a consequence, conformance to Netconf can be guaranteed. > = > We received a lot of valuable feedback and support from Martin Bjorklund > who is a Netconf expert and author of the YANG draft. We will try to get > some additional feedback from other Netconf experts as well. > = > Regards, > Gerhard > = > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > = --- = Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 9 00:51:59 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F143A6C40; Sun, 9 Mar 2008 00:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfqjHBYi2uzf; Sun, 9 Mar 2008 00:51:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C10B3A6BD0; Sun, 9 Mar 2008 00:51:57 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6095C3A6B0C for ; Sun, 9 Mar 2008 00:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+05nE4Rdfyf for ; Sun, 9 Mar 2008 00:51:54 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5A55E28C0F6 for ; Sun, 9 Mar 2008 00:51:30 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m298mxcg064493; Sun, 9 Mar 2008 17:49:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 09 Mar 2008 17:49:11 +0900 From: Kobayashi Atsushi To: Kobayashi Atsushi In-Reply-To: <20080308212938.7A9F.AKOBA@nttv6.net> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> <20080308212938.7A9F.AKOBA@nttv6.net> Message-Id: <20080309173742.5623.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sun, 09 Mar 2008 17:49:06 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Sorry for sending duplicate same messages. I tryed to send same message until it updates. It took about 30 minutes. On Sat, 08 Mar 2008 21:30:32 +0900 Kobayashi Atsushi wrote: > > Hi Gerhard, Benoit and all, > > This draft is almost complete and great work. > I think that such XML configuration enhances efficiency of the use of > flexibility of IPFIX. > > IMHO, I am afraid that the filtering method is different than current ACL > implemented in several routers. Therefore, the IPFIX XML cfg might not > be implemented, because of the gap between current ACL filter and IPFIX > XML cfg, even if psamp mention "AND" operation only. > > I propose the following XML schema added the ACL elements to -03 draft. > I am not familiar with YANG yet, sorry. > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > > The following Complex/Simple type elements are added. > - Complex Type: accessListMatch_type > - Complex Type: sequenceList_type > - SFrom ipfix-bounces@ietf.org Sun Mar 9 00:51:59 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F143A6C40; Sun, 9 Mar 2008 00:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfqjHBYi2uzf; Sun, 9 Mar 2008 00:51:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C10B3A6BD0; Sun, 9 Mar 2008 00:51:57 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6095C3A6B0C for ; Sun, 9 Mar 2008 00:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+05nE4Rdfyf for ; Sun, 9 Mar 2008 00:51:54 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5A55E28C0F6 for ; Sun, 9 Mar 2008 00:51:30 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m298mxcg064493; Sun, 9 Mar 2008 17:49:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 09 Mar 2008 17:49:11 +0900 From: Kobayashi Atsushi To: Kobayashi Atsushi In-Reply-To: <20080308212938.7A9F.AKOBA@nttv6.net> References: <47C2F1CD.5020407@informatik.uni-tuebingen.de> <20080308212938.7A9F.AKOBA@nttv6.net> Message-Id: <20080309173742.5623.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Sun, 09 Mar 2008 17:49:06 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New version of IPFIX configuration draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Sorry for sending duplicate same messages. I tryed to send same message until it updates. It took about 30 minutes. On Sat, 08 Mar 2008 21:30:32 +0900 Kobayashi Atsushi wrote: > > Hi Gerhard, Benoit and all, > > This draft is almost complete and great work. > I think that such XML configuration enhances efficiency of the use of > flexibility of IPFIX. > > IMHO, I am afraid that the filtering method is different than current ACL > implemented in several routers. Therefore, the IPFIX XML cfg might not > be implemented, because of the gap between current ACL filter and IPFIX > XML cfg, even if psamp mention "AND" operation only. > > I propose the following XML schema added the ACL elements to -03 draft. > I am not familiar with YANG yet, sorry. > > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.txt > http://www3.plala.or.jp/akoba/ipfix-cfg-acl.html > > The following Complex/Simple type elements are added. > - Complex Type: accessListMatch_type > - Complex Type: sequenceList_type > - Simple Type: action_type > > In addition, it allows "selectionProcess_type" to include > "AccessListMatch" element. > > What do you think about that? I think that it enhances flexibility as > optional. > > Regards, > Atsushi KOBAYASHI > > On Mon, 25 Feb 2008 17:50:21 +0100 > Gerhard Muenz wrote: > > > > > Dear all, > > > > A new revision of the IPFIX/PSAMP configuration data model has been > > published: > > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > > > Apart from smaller changes in the model itself, the big change compared > > to the previous version concerns the specification language: instead of > > XML Schema, we now use YANG, a new language for modelling Netconf data > > models. As a consequence, conformance to Netconf can be guaranteed. > > > > We received a lot of valuable feedback and support from Martin Bjorklund > > who is a Netconf expert and author of the YANG draft. We will try to get > > some additional feedback from other Netconf experts as well. > > > > Regards, > > Gerhard > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix imple Type: action_type > > In addition, it allows "selectionProcess_type" to include > "AccessListMatch" element. > > What do you think about that? I think that it enhances flexibility as > optional. > > Regards, > Atsushi KOBAYASHI > > On Mon, 25 Feb 2008 17:50:21 +0100 > Gerhard Muenz wrote: > > > > > Dear all, > > > > A new revision of the IPFIX/PSAMP configuration data model has been > > published: > > http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt > > > > Apart from smaller changes in the model itself, the big change compared > > to the previous version concerns the specification language: instead of > > XML Schema, we now use YANG, a new language for modelling Netconf data > > models. As a consequence, conformance to Netconf can be guaranteed. > > > > We received a lot of valuable feedback and support from Martin Bjorklund > > who is a Netconf expert and author of the YANG draft. We will try to get > > some additional feedback from other Netconf experts as well. > > > > Regards, > > Gerhard > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 9 18:37:38 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FE228C2BC; Sun, 9 Mar 2008 18:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.279 X-Spam-Level: X-Spam-Status: No, score=-100.279 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPNq5YMJhSPH; Sun, 9 Mar 2008 18:37:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB8428C295; Sun, 9 Mar 2008 18:37:37 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78CE28C23F for ; Sun, 9 Mar 2008 18:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXbOfWSr1s2O for ; Sun, 9 Mar 2008 18:37:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 7636F28C295 for ; Sun, 9 Mar 2008 18:37:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A1ZDm02944 for ; Mon, 10 Mar 2008 02:35:13 +0100 (CET) Received: from [10.82.209.88] (rtp-vpn4-344.cisco.com [10.82.209.88]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A1ZBB25821 for ; Mon, 10 Mar 2008 02:35:11 +0100 (CET) Message-ID: <47D4904E.4060406@cisco.com> Date: Mon, 10 Mar 2008 02:35:10 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] Exporting Type Information for IPFIX IE: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Brian, Lutz, Tanja, I reviewed this draft. I think it looks good Here is some feedback anyway. - Terminology: you should mentioned that the terms from RFC5101 are capitalized - I would put the section 3.1 to 3.8 about the new IE after the section 3.9 "information element type options template". The reason is that, when reading through the IEs definitions, I was trying to deduce the specifications - informationElementRangeBegin and informationElementRangeEnd. I like your definitions, but they don't match with the IE name. What about renaming to informationElementValueRangeLow and informationElementValueRangeHigh - you have sometimes specifications within the IE description, even with SHOULD. We shouldn't have specifications in the description. Example: informationElementRangeBegin - IANA in informationElementSemantics. It's fine to mention that there is an IANA registry, but I don't think it's appropriate to mention: requires Standard Action. This part should be in the IANA consideration sections. - This draft might benefit from two new definitions: information From ipfix-bounces@ietf.org Sun Mar 9 18:37:38 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FE228C2BC; Sun, 9 Mar 2008 18:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.279 X-Spam-Level: X-Spam-Status: No, score=-100.279 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPNq5YMJhSPH; Sun, 9 Mar 2008 18:37:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB8428C295; Sun, 9 Mar 2008 18:37:37 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78CE28C23F for ; Sun, 9 Mar 2008 18:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXbOfWSr1s2O for ; Sun, 9 Mar 2008 18:37:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 7636F28C295 for ; Sun, 9 Mar 2008 18:37:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A1ZDm02944 for ; Mon, 10 Mar 2008 02:35:13 +0100 (CET) Received: from [10.82.209.88] (rtp-vpn4-344.cisco.com [10.82.209.88]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A1ZBB25821 for ; Mon, 10 Mar 2008 02:35:11 +0100 (CET) Message-ID: <47D4904E.4060406@cisco.com> Date: Mon, 10 Mar 2008 02:35:10 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] Exporting Type Information for IPFIX IE: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Brian, Lutz, Tanja, I reviewed this draft. I think it looks good Here is some feedback anyway. - Terminology: you should mentioned that the terms from RFC5101 are capitalized - I would put the section 3.1 to 3.8 about the new IE after the section 3.9 "information element type options template". The reason is that, when reading through the IEs definitions, I was trying to deduce the specifications - informationElementRangeBegin and informationElementRangeEnd. I like your definitions, but they don't match with the IE name. What about renaming to informationElementValueRangeLow and informationElementValueRangeHigh - you have sometimes specifications within the IE description, even with SHOULD. We shouldn't have specifications in the description. Example: informationElementRangeBegin - IANA in informationElementSemantics. It's fine to mention that there is an IANA registry, but I don't think it's appropriate to mention: requires Standard Action. This part should be in the IANA consideration sections. - This draft might benefit from two new definitions: information element type options template and information element type - privateEnterpriseNumber: "A private enterprise number used to scope an informationElementID, as would appear in an IPFIX Template Record." I don't understand the second part of the sentence. Why do you say: "If the Enterprise ID bit of the corresponding Information Element is cleared (has the value 0), this IE should be set to 0." "The presence of a non-zero value in this IE implies that the Enterprise ID bit of the corresponding Information Element is set (has the value 1)." isn't it the logic reverse? If the Enterprise ID bit is set to 1, the corresponding Information Element MAY/SHOULD/MUST ...". - I don't think you want to write the first part of the sentence. Think about UDP Information Element type records SHOULD NOT be duplicated within a Transport Session, but once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. NEW Once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. - "The template SHOULD contain the following Information Elements" Maybe worth a couple of compulsory IEs, such as informationElementID, privateEnterpriseNumber, informationElementDataType, and informationElementSemantics - In the template figure, I would put [scope] under informationElementID and privateEnterpriseNumber, to be inline with the file draft A few editorial changes - this draft -> this document - enterprise specific information element is spelled differently at different locations - information element -> Information Element (several occurences) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix element type options template and information element type - privateEnterpriseNumber: "A private enterprise number used to scope an informationElementID, as would appear in an IPFIX Template Record." I don't understand the second part of the sentence. Why do you say: "If the Enterprise ID bit of the corresponding Information Element is cleared (has the value 0), this IE should be set to 0." "The presence of a non-zero value in this IE implies that the Enterprise ID bit of the corresponding Information Element is set (has the value 1)." isn't it the logic reverse? If the Enterprise ID bit is set to 1, the corresponding Information Element MAY/SHOULD/MUST ...". - I don't think you want to write the first part of the sentence. Think about UDP Information Element type records SHOULD NOT be duplicated within a Transport Session, but once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. NEW Once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. - "The template SHOULD contain the following Information Elements" Maybe worth a couple of compulsory IEs, such as informationElementID, privateEnterpriseNumber, informationElementDataType, and informationElementSemantics - In the template figure, I would put [scope] under informationElementID and privateEnterpriseNumber, to be inline with the file draft A few editorial changes - this draft -> this document - enterprise specific information element is spelled differently at different locations - information element -> Information Element (several occurences) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 9 19:47:00 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D593A6D99; Sun, 9 Mar 2008 19:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF-cQrAEVfsI; Sun, 9 Mar 2008 19:47:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5523A6D71; Sun, 9 Mar 2008 19:46:51 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042F33A6CFC for ; Sun, 9 Mar 2008 19:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj+J5vYPlAFL for ; Sun, 9 Mar 2008 19:46:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 285783A68B9 for ; Sun, 9 Mar 2008 19:46:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A2iOR08634 for ; Mon, 10 Mar 2008 03:44:24 +0100 (CET) Received: from [10.82.209.88] (rtp-vpn4-344.cisco.com [10.82.209.88]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A2iMB19432 for ; Mon, 10 Mar 2008 03:44:22 +0100 (CET) Message-ID: <47D4A086.4040706@cisco.com> Date: Sun, 09 Mar 2008 22:44:22 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Kobayashi-san, I think the draft improved compared to last time. Here is my feedback. - In the terminology section, you're missing a reference to the terminology from RFC5101, since you capitalized some of the terms. - The second is changing the Template and record structure by adding/ deleting specified Information Elements. Example devices for this type are the IPFIX Masquerading Proxy and the IPFIX Concentrator. NEW The second is changing the Template and record structure by adding/ aggregating/deleting specified Information Elements. Example devices for this type are the IPFIX Masquerading Proxy and the IPFIX Concentrator. - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've seen 1/100 - Section 3.1. You're missing an important application -> data retention. - Section 4. twice the same idea in the following sentences It should be noted that the current sampling rate might become infeasible for Exporters within the next five years. We expect to encounter this problem within the next five years in large-scale networks. - I would develop further the section 4.2 to express that there is a different approach than exporting complete flow records to a mediation device, which in turn does some aggregation/filtering. I mean, the router have several different caches, each optimized for a specific application. So each cache has its own series of flow keys. And the content of each cache is sent to a specific collector. For example, a collector for security, another one for capacity planning, etc... - Section 4.4 "In general, load balancing allows work of Collectors to be divided. Classifying Flow Records based on the value of specified Information Elements can prove to be very useful to achive scalability. " This is not load balancing, as the title says. - I would add a new section 4.5 "Flow based sampling" - section 5.1 "Implementing load balancing" "There currently is no description of a classification function in IPFIX." This is normal as IPFIX is the export protocol. You speak about a specific feature of the Exporting Process that would use RFC5101 "According to the current specification, Exporters send all Flow Records to multiple Collectors and Collectors drop uninteresting Flow Records to reduce their load." This is wrong. - "The Collector, however, needs to recognize the precise Observation Point whether Flow Records go through an IPFIX Mediator or not." This is not always true. The answer is: it depends. For example, for the core traffic matrix in capacity planning, having the router exporting the flow records is enough. - section 5.6 "session management" You want to talk about transport session, right? (to refer to RFC5101) This session is confusing. After reading several times, I understand that you speak about the Collecting and Exporting Processes of the mediation device. - section 5.6 "If the session between a Router and a Mediator fails and the IPFIX Mediator shuts down the session between the Collector and the Mediator, the Collector would futilely continue to try to establish the session." "If one of these sessions between Routers and the Mediator fails and IPFIX Mediator shuts down the session between a Collector and the Mediator, other sessions between the Routers and the Mediator would not be relayed at all." Not necessarily. It depends how we write the specifications. - Section 5.6, last paragraph. "Even if one session is reset, the status of the other sessions is kept. However, if Templates that reset the session of Collecting Processes would not be withdrawn, there is a possibility that assigned Template IDs overlap. The Collector might then shut down IPFIX session, because it identifies the overlapping Template ID as part of an anomalous message. In the case of resetting a session of the Collecting Process, the operation processed by IPFIX Mediator should be defined." This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 9 19:47:00 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D593A6D99; Sun, 9 Mar 2008 19:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF-cQrAEVfsI; Sun, 9 Mar 2008 19:47:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5523A6D71; Sun, 9 Mar 2008 19:46:51 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042F33A6CFC for ; Sun, 9 Mar 2008 19:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj+J5vYPlAFL for ; Sun, 9 Mar 2008 19:46:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 285783A68B9 for ; Sun, 9 Mar 2008 19:46:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A2iOR08634 for ; Mon, 10 Mar 2008 03:44:24 +0100 (CET) Received: from [10.82.209.88] (rtp-vpn4-344.cisco.com [10.82.209.88]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2A2iMB19432 for ; Mon, 10 Mar 2008 03:44:22 +0100 (CET) Message-ID: <47D4A086.4040706@cisco.com> Date: Sun, 09 Mar 2008 22:44:22 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Kobayashi-san, I think the draft improved compared to last time. Here is my feedback. - In the terminology section, you're missing a reference to the terminology from RFC5101, since you capitalized some of the terms. - The second is changing the Template and record structure by adding/ deleting specified Information Elements. Example devices for this type are the IPFIX Masquerading Proxy and the IPFIX Concentrator. NEW The second is changing the Template and record structure by adding/ aggregating/deleting specified Information Elements. Example devices for this type are the IPFIX Masquerading Proxy and the IPFIX Concentrator. - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've seen 1/100 - Section 3.1. You're missing an important application -> data retention. - Section 4. twice the same idea in the following sentences It should be noted that the current sampling rate might become infeasible for Exporters within the next five years. We expect to encounter this problem within the next five years in large-scale networks. - I would develop further the section 4.2 to express that there is a different approach than exporting complete flow records to a mediation device, which in turn does some aggregation/filtering. I mean, the router have several different caches, each optimized for a specific application. So each cache has its own series of flow keys. And the content of each cache is sent to a specific collector. For example, a collector for security, another one for capacity planning, etc... - Section 4.4 "In general, load balancing allows work of Collectors to be divided. Classifying Flow Records based on the value of specified Information Elements can prove to be very useful to achive scalability. " This is not load balancing, as the title says. - I would add a new section 4.5 "Flow based sampling" - section 5.1 "Implementing load balancing" "There currently is no description of a classification function in IPFIX." This is normal as IPFIX is the export protocol. You speak about a specific feature of the Exporting Process that would use RFC5101 "According to the current specification, Exporters send all Flow Records to multiple Collectors and Collectors drop uninteresting Flow Records to reduce their load." This is wrong. - "The Collector, however, needs to recognize the precise Observation Point whether Flow Records go through an IPFIX Mediator or not." This is not always true. The answer is: it depends. For example, for the core traffic matrix in capacity planning, having the router exporting the flow records is enough. - section 5.6 "session management" You want to talk about transport session, right? (to refer to RFC5101) This session is confusing. After reading several times, I understand that you speak about the Collecting and Exporting Processes of the mediation device. - section 5.6 "If the session between a Router and a Mediator fails and the IPFIX Mediator shuts down the session between the Collector and the Mediator, the Collector would futilely continue to try to establish the session." "If one of these sessions between Routers and the Mediator fails and IPFIX Mediator shuts down the session between a Collector and the Mediator, other sessions between the Routers and the Mediator would not be relayed at all." Not necessarily. It depends how we write the specifications. - Section 5.6, last paragraph. "Even if one session is reset, the status of the other sessions is kept. However, if Templates that reset the session of Collecting Processes would not be withdrawn, there is a possibility that assigned Template IDs overlap. The Collector might then shut down IPFIX session, because it identifies the overlapping Template ID as part of an anomalous message. In the case of resetting a session of the Collecting Process, the operation processed by IPFIX Mediator should be defined." This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 10 08:02:16 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3E728CFBC; Mon, 10 Mar 2008 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.564 X-Spam-Level: X-Spam-Status: No, score=-96.564 tagged_above=-999 required=5 tests=[AWL=1.274, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igyCGlOuNevB; Mon, 10 Mar 2008 08:02:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956EE28D96B; Mon, 10 Mar 2008 07:31:37 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93B728C635 for ; Mon, 10 Mar 2008 07:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGfd4CY-FyWd for ; Mon, 10 Mar 2008 07:31:29 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id EFC9128E02F for ; Mon, 10 Mar 2008 02:11:57 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2A99Vhu082546 for ; Mon, 10 Mar 2008 18:09:35 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 10 Mar 2008 18:09:39 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47D4A086.4040706@cisco.com> References: <47D4A086.4040706@cisco.com> Message-Id: <20080310154551.5663.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Mon, 10 Mar 2008 18:09:35 +0900 (JST) Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Thank you very much for your feedback. Please see in-line. On Sun, 09 Mar 2008 22:44:22 -0400 Benoit Claise wrote: > Kobayashi-san, > > I think the draft improved compared to last time. > > Here is my feedback. > > - In the terminology section, you're missing a reference to the > terminology from RFC5101, since you capitalized some of the terms. Yes. I missed it. I will improve in next version. > - > > The > second is changing the Template and record structure by adding/ > deleting specified Information Elements. Example devices for > this type are the IPFIX Masquerading Proxy and the IPFIX > Concentrator. > NEW > The > second is changing the Template and record structure by adding/ > aggregating/deleting specified Information Elements. Example devices for > this type are the IPFIX Masquerading Proxy and the IPFIX > Concentrator. > Yes. > - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've > seen 1/100 Where is it? I mentFrom ipfix-bounces@ietf.org Mon Mar 10 08:02:16 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3E728CFBC; Mon, 10 Mar 2008 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.564 X-Spam-Level: X-Spam-Status: No, score=-96.564 tagged_above=-999 required=5 tests=[AWL=1.274, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igyCGlOuNevB; Mon, 10 Mar 2008 08:02:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956EE28D96B; Mon, 10 Mar 2008 07:31:37 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93B728C635 for ; Mon, 10 Mar 2008 07:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGfd4CY-FyWd for ; Mon, 10 Mar 2008 07:31:29 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id EFC9128E02F for ; Mon, 10 Mar 2008 02:11:57 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2A99Vhu082546 for ; Mon, 10 Mar 2008 18:09:35 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 10 Mar 2008 18:09:39 +0900 From: Kobayashi Atsushi To: "ipfix@ietf.org" In-Reply-To: <47D4A086.4040706@cisco.com> References: <47D4A086.4040706@cisco.com> Message-Id: <20080310154551.5663.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Mon, 10 Mar 2008 18:09:35 +0900 (JST) Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Thank you very much for your feedback. Please see in-line. On Sun, 09 Mar 2008 22:44:22 -0400 Benoit Claise wrote: > Kobayashi-san, > > I think the draft improved compared to last time. > > Here is my feedback. > > - In the terminology section, you're missing a reference to the > terminology from RFC5101, since you capitalized some of the terms. Yes. I missed it. I will improve in next version. > - > > The > second is changing the Template and record structure by adding/ > deleting specified Information Elements. Example devices for > this type are the IPFIX Masquerading Proxy and the IPFIX > Concentrator. > NEW > The > second is changing the Template and record structure by adding/ > aggregating/deleting specified Information Elements. Example devices for > this type are the IPFIX Masquerading Proxy and the IPFIX > Concentrator. > Yes. > - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've > seen 1/100 Where is it? I mentioned that "typically sampling packets with rates ranging from 1/10,000 to 1/1,000". > - Section 3.1. You're missing an important application -> data retention. You mean that data retention is storage of traffic data during reasonable amount of time according to government regulation? I was not familiar with data retention using NetFlow/sFlow. Exactly, NetFlow/sFlow/IPFIX can become the tool for data retention. > - Section 4. twice the same idea in the following sentences > > It should be noted that the > current sampling rate might become infeasible for Exporters within > the next five years. We expect to encounter this problem within the > next five years in large-scale networks. > Yes. Latter sentence can be removed. > - I would develop further the section 4.2 to express that there is a > different approach than exporting complete flow records to a mediation > device, which in turn does some aggregation/filtering. I mean, the > router have several different caches, each optimized for a specific > application. So each cache has its own series of flow keys. And the > content of each cache is sent to a specific collector. For example, a > collector for security, another one for capacity planning, etc... I can image you mentioned. Each cache has its own Flow Keys. The output of each cache is send to a specific collector. > - Section 4.4 "In general, load balancing allows work of Collectors to > be divided. Classifying Flow Records based on the value of specified > Information Elements can prove to be very useful to achive scalability. > " This is not load balancing, as the title says. Does it prefer "load sharing method" or "load distribution"? > - I would add a new section 4.5 "Flow based sampling" OK. > - section 5.1 "Implementing load balancing" > > "There currently is no description of a classification function in > IPFIX." > > This is normal as IPFIX is the export protocol. You speak about a > specific feature of the Exporting Process that would use RFC5101 > > "According to the current specification, Exporters send all > Flow Records to multiple Collectors and Collectors drop uninteresting > Flow Records to reduce their load." > > This is wrong. Wrong? If so, I can not image the current specification regarding classification. As another case, observed packets become input to multiple Metering Processes, and in each Metering Process, these interesting packets are selected. Finally, output of each Metering Process is sent to a specific Collector. Is it correct? > - > > "The Collector, however, needs to recognize the > precise Observation Point whether Flow Records go through an IPFIX > Mediator or not." > > This is not always true. The answer is: it depends. Yes. Not alway. For example, in creating traffic matrix using exporter IP address it is necessary. I will improve. > For example, for the core traffic matrix in capacity planning, having > the router exporting the flow records is enough. > - section 5.6 "session management" > You want to talk about transport session, right? (to refer to RFC5101) Yes. It means "Transport Session". > This session is confusing. After reading several times, I understand > that you speak about the Collecting and Exporting Processes of the > mediation device. Yes. I will improve. > - section 5.6 > > "If the session > between a Router and a Mediator fails and the IPFIX Mediator shuts > down the session between the Collector and the Mediator, the > Collector would futilely continue to try to establish the session." > > "If > one of these sessions between Routers and the Mediator fails and > IPFIX Mediator shuts down the session between a Collector and the > Mediator, other sessions between the Routers and the Mediator would > not be relayed at all." > > Not necessarily. It depends how we write the specifications. You mean that removing all of section 5.6 is better? > - Section 5.6, last paragraph. > > "Even if one session is reset, > the status of the other sessions is kioned that "typically sampling packets with rates ranging from 1/10,000 to 1/1,000". > - Section 3.1. You're missing an important application -> data retention. You mean that data retention is storage of traffic data during reasonable amount of time according to government regulation? I was not familiar with data retention using NetFlow/sFlow. Exactly, NetFlow/sFlow/IPFIX can become the tool for data retention. > - Section 4. twice the same idea in the following sentences > > It should be noted that the > current sampling rate might become infeasible for Exporters within > the next five years. We expect to encounter this problem within the > next five years in large-scale networks. > Yes. Latter sentence can be removed. > - I would develop further the section 4.2 to express that there is a > different approach than exporting complete flow records to a mediation > device, which in turn does some aggregation/filtering. I mean, the > router have several different caches, each optimized for a specific > application. So each cache has its own series of flow keys. And the > content of each cache is sent to a specific collector. For example, a > collector for security, another one for capacity planning, etc... I can image you mentioned. Each cache has its own Flow Keys. The output of each cache is send to a specific collector. > - Section 4.4 "In general, load balancing allows work of Collectors to > be divided. Classifying Flow Records based on the value of specified > Information Elements can prove to be very useful to achive scalability. > " This is not load balancing, as the title says. Does it prefer "load sharing method" or "load distribution"? > - I would add a new section 4.5 "Flow based sampling" OK. > - section 5.1 "Implementing load balancing" > > "There currently is no description of a classification function in > IPFIX." > > This is normal as IPFIX is the export protocol. You speak about a > specific feature of the Exporting Process that would use RFC5101 > > "According to the current specification, Exporters send all > Flow Records to multiple Collectors and Collectors drop uninteresting > Flow Records to reduce their load." > > This is wrong. Wrong? If so, I can not image the current specification regarding classification. As another case, observed packets become input to multiple Metering Processes, and in each Metering Process, these interesting packets are selected. Finally, output of each Metering Process is sent to a specific Collector. Is it correct? > - > > "The Collector, however, needs to recognize the > precise Observation Point whether Flow Records go through an IPFIX > Mediator or not." > > This is not always true. The answer is: it depends. Yes. Not alway. For example, in creating traffic matrix using exporter IP address it is necessary. I will improve. > For example, for the core traffic matrix in capacity planning, having > the router exporting the flow records is enough. > - section 5.6 "session management" > You want to talk about transport session, right? (to refer to RFC5101) Yes. It means "Transport Session". > This session is confusing. After reading several times, I understand > that you speak about the Collecting and Exporting Processes of the > mediation device. Yes. I will improve. > - section 5.6 > > "If the session > between a Router and a Mediator fails and the IPFIX Mediator shuts > down the session between the Collector and the Mediator, the > Collector would futilely continue to try to establish the session." > > "If > one of these sessions between Routers and the Mediator fails and > IPFIX Mediator shuts down the session between a Collector and the > Mediator, other sessions between the Routers and the Mediator would > not be relayed at all." > > Not necessarily. It depends how we write the specifications. You mean that removing all of section 5.6 is better? > - Section 5.6, last paragraph. > > "Even if one session is reset, > the status of the other sessions is kept. However, if Templates that > reset the session of Collecting Processes would not be withdrawn, > there is a possibility that assigned Template IDs overlap. The > Collector might then shut down IPFIX session, because it identifies > the overlapping Template ID as part of an anomalous message. In the > case of resetting a session of the Collecting Process, the operation > processed by IPFIX Mediator should be defined." > > This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. I think that it is not necessary to rewrite Template ID in case of relaying from one Transport Session to one Transport Session. But, exactly, assigning new template id in case of all situation is safer for IPFIX protocol. You mean that IPFIX Mediator implemented in relation to RFC5101 does not fall into the situation mentioned in section 5.6? After all, section 5.6 is not necessary, is it? It seems deletable. Regards, Atsushi KOBAYASHI > > Regards, Benoit. > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ept. However, if Templates that > reset the session of Collecting Processes would not be withdrawn, > there is a possibility that assigned Template IDs overlap. The > Collector might then shut down IPFIX session, because it identifies > the overlapping Template ID as part of an anomalous message. In the > case of resetting a session of the Collecting Process, the operation > processed by IPFIX Mediator should be defined." > > This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. I think that it is not necessary to rewrite Template ID in case of relaying from one Transport Session to one Transport Session. But, exactly, assigning new template id in case of all situation is safer for IPFIX protocol. You mean that IPFIX Mediator implemented in relation to RFC5101 does not fall into the situation mentioned in section 5.6? After all, section 5.6 is not necessary, is it? It seems deletable. Regards, Atsushi KOBAYASHI > > Regards, Benoit. > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 10 09:18:20 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3CD3A6ECD; Mon, 10 Mar 2008 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkQUroiy+Cfs; Mon, 10 Mar 2008 09:18:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D18B28C3F8; Mon, 10 Mar 2008 08:51:21 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253C53A6B26 for ; Mon, 10 Mar 2008 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RJ9KhZlK+ht for ; Mon, 10 Mar 2008 08:51:18 -0700 (PDT) Received: from nishidaya.org (nishidaya.org [124.40.9.12]) by core3.amsl.com (Postfix) with ESMTP id 60BBC28CAC0 for ; Mon, 10 Mar 2008 08:31:17 -0700 (PDT) Received: (qmail 50491 invoked by uid 2316); 10 Mar 2008 15:23:31 -0000 Received: from unknown (HELO [IPv6:::1]) ([127.0.0.1]) (envelope-sender ) by 127.0.0.1 (qmail-ldap-1.03) with SMTP for ; 10 Mar 2008 15:23:31 -0000 Message-Id: From: Haruhiko Nishida To: ipfix@ietf.org In-Reply-To: <20080310234156.5675.AKOBA@nttv6.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 10 Mar 2008 11:28:52 -0400 References: <20080310234156.5675.AKOBA@nttv6.net> X-Mailer: Apple Mail (2.919.2) Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org comments inline. -- Haru On 2008/03/10, at 10:42, Kobayashi Atsushi wrote: > > Forwarded by Kobayashi Atsushi > ----------------------- Original Message ----------------------- > From: Kobayashi Atsushi > To: "ipfix@ietf.org" > Date: Mon, 10 Mar 2008 18:09:39 +0900 > Subject: Re: [IPFIX] Problems with Flow Collection in large-scale > networks: feedback > ---- > > > Hi Benoit, > > Thank you very much for your feedback. > Please see in-line. > > On Sun, 09 Mar 2008 22:44:22 -0400 > Benoit Claise wrote: > >> Kobayashi-san, >> >> I think the draft improved compared to last time. >> >> Here is my feedback. >> >> - In the terminology section, you're missing a reference to the >> terminology from RFC5101, since you capitalized some of the terms. > > Yes. I missed it. I will improve in next version. > >> - >> >> The >> second is changing the Template and record structure by >> adding/ >> deleting specified Information Elements. Example devices for >> this type are the IPFIX Masquerading Proxy and the IPFIX >>From ipfix-bounces@ietf.org Mon Mar 10 09:18:20 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3CD3A6ECD; Mon, 10 Mar 2008 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkQUroiy+Cfs; Mon, 10 Mar 2008 09:18:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D18B28C3F8; Mon, 10 Mar 2008 08:51:21 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253C53A6B26 for ; Mon, 10 Mar 2008 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RJ9KhZlK+ht for ; Mon, 10 Mar 2008 08:51:18 -0700 (PDT) Received: from nishidaya.org (nishidaya.org [124.40.9.12]) by core3.amsl.com (Postfix) with ESMTP id 60BBC28CAC0 for ; Mon, 10 Mar 2008 08:31:17 -0700 (PDT) Received: (qmail 50491 invoked by uid 2316); 10 Mar 2008 15:23:31 -0000 Received: from unknown (HELO [IPv6:::1]) ([127.0.0.1]) (envelope-sender ) by 127.0.0.1 (qmail-ldap-1.03) with SMTP for ; 10 Mar 2008 15:23:31 -0000 Message-Id: From: Haruhiko Nishida To: ipfix@ietf.org In-Reply-To: <20080310234156.5675.AKOBA@nttv6.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 10 Mar 2008 11:28:52 -0400 References: <20080310234156.5675.AKOBA@nttv6.net> X-Mailer: Apple Mail (2.919.2) Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org comments inline. -- Haru On 2008/03/10, at 10:42, Kobayashi Atsushi wrote: > > Forwarded by Kobayashi Atsushi > ----------------------- Original Message ----------------------- > From: Kobayashi Atsushi > To: "ipfix@ietf.org" > Date: Mon, 10 Mar 2008 18:09:39 +0900 > Subject: Re: [IPFIX] Problems with Flow Collection in large-scale > networks: feedback > ---- > > > Hi Benoit, > > Thank you very much for your feedback. > Please see in-line. > > On Sun, 09 Mar 2008 22:44:22 -0400 > Benoit Claise wrote: > >> Kobayashi-san, >> >> I think the draft improved compared to last time. >> >> Here is my feedback. >> >> - In the terminology section, you're missing a reference to the >> terminology from RFC5101, since you capitalized some of the terms. > > Yes. I missed it. I will improve in next version. > >> - >> >> The >> second is changing the Template and record structure by >> adding/ >> deleting specified Information Elements. Example devices for >> this type are the IPFIX Masquerading Proxy and the IPFIX >> Concentrator. >> NEW >> The >> second is changing the Template and record structure by >> adding/ >> aggregating/deleting specified Information Elements. >> Example devices for >> this type are the IPFIX Masquerading Proxy and the IPFIX >> Concentrator. >> > > Yes. > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've >> seen 1/100 > > Where is it? > I mentioned that "typically sampling packets with rates ranging from > 1/10,000 to 1/1,000". I thought Benoit knows some use cases using 1/100. If so, it's good news. Benoit, will you let us know some more on the case? (As a draft, we can modify 1/10,000-1/1,000 to 1/10,000-1/100 easily) >> - Section 3.1. You're missing an important application -> data >> retention. > > You mean that data retention is storage of traffic data during > reasonable > amount of time according to government regulation? > I was not familiar with data retention using NetFlow/sFlow. Exactly, > NetFlow/sFlow/IPFIX can become the tool for data retention. neither of me nor Kobayashi-san knows about data retention by netflow/ IPFIX. Could you add some description on the part? >> - Section 4. twice the same idea in the following sentences >> >> It should be noted that the >> current sampling rate might become infeasible for Exporters within >> the next five years. We expect to encounter this problem within >> the >> next five years in large-scale networks. >> > > Yes. Latter sentence can be removed. > >> - I would develop further the section 4.2 to express that there is a >> different approach than exporting complete flow records to a >> mediation >> device, which in turn does some aggregation/filtering. I mean, the >> router have several different caches, each optimized for a specific >> application. So each cache has its own series of flow keys. And the >> content of each cache is sent to a specific collector. For example, a >> collector for security, another one for capacity planning, etc... > > I can image you mentioned. > Each cache has its own Flow Keys. The output of each cache is send > to a > specific collector. > >> - Section 4.4 "In general, load balancing allows work of Collectors >> to >> be divided. Classifying Flow Records based on the value of specified >> Information Elements can prove to be very useful to achive >> scalability. >> " This is not load balancing, as the title says. > > Does it prefer "load sharing method" or "load distribution"? I feel both "load sharing/balancing" wordings are wrong, since in this example collectors have different purposes... (but couldn't find good word yet) >> - I would add a new section 4.5 "Flow based sampling" > > OK. > >> - section 5.1 "Implementing load balancing" >> >> "There currently is no description of a classification function in >> IPFIX." >> >> This is normal as IPFIX is the export protocol. You speak about a >> specific feature of the Exporting Process that would use RFC5101 >> >> "According to the current specification, Exporters send all >> Flow Records to multiple Collectors and Collectors drop >> uninteresting >> Flow Records to reduce their load." >> >> This is wrong. > > Wrong? If so, I can not image the current specification regarding > classification. > > As another case, observed packets become input to multiple Metering > Processes, and in each Metering Process, these interesting packets are > selected. Finally, output of each Metering Process is sent to a > specific > Collector. Is it correct? Purpose of section 5.1 is to say "we need classification function". I believes that we all shares the purpose. Then, we need just rewrite the section. >> "The Collector, however, needs to recognize the >> precise Observation Point whether Flow Records go through an IPFIX >> Mediator or not." >> >> This is not always true. The answer is: it depends. > > Yes. Not alway. For example, in creating traffic matrix using > exporter IP > address it is necessary. I will improve. > > > >> For example, for the core traffic Concentrator. >> NEW >> The >> second is changing the Template and record structure by >> adding/ >> aggregating/deleting specified Information Elements. >> Example devices for >> this type are the IPFIX Masquerading Proxy and the IPFIX >> Concentrator. >> > > Yes. > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've >> seen 1/100 > > Where is it? > I mentioned that "typically sampling packets with rates ranging from > 1/10,000 to 1/1,000". I thought Benoit knows some use cases using 1/100. If so, it's good news. Benoit, will you let us know some more on the case? (As a draft, we can modify 1/10,000-1/1,000 to 1/10,000-1/100 easily) >> - Section 3.1. You're missing an important application -> data >> retention. > > You mean that data retention is storage of traffic data during > reasonable > amount of time according to government regulation? > I was not familiar with data retention using NetFlow/sFlow. Exactly, > NetFlow/sFlow/IPFIX can become the tool for data retention. neither of me nor Kobayashi-san knows about data retention by netflow/ IPFIX. Could you add some description on the part? >> - Section 4. twice the same idea in the following sentences >> >> It should be noted that the >> current sampling rate might become infeasible for Exporters within >> the next five years. We expect to encounter this problem within >> the >> next five years in large-scale networks. >> > > Yes. Latter sentence can be removed. > >> - I would develop further the section 4.2 to express that there is a >> different approach than exporting complete flow records to a >> mediation >> device, which in turn does some aggregation/filtering. I mean, the >> router have several different caches, each optimized for a specific >> application. So each cache has its own series of flow keys. And the >> content of each cache is sent to a specific collector. For example, a >> collector for security, another one for capacity planning, etc... > > I can image you mentioned. > Each cache has its own Flow Keys. The output of each cache is send > to a > specific collector. > >> - Section 4.4 "In general, load balancing allows work of Collectors >> to >> be divided. Classifying Flow Records based on the value of specified >> Information Elements can prove to be very useful to achive >> scalability. >> " This is not load balancing, as the title says. > > Does it prefer "load sharing method" or "load distribution"? I feel both "load sharing/balancing" wordings are wrong, since in this example collectors have different purposes... (but couldn't find good word yet) >> - I would add a new section 4.5 "Flow based sampling" > > OK. > >> - section 5.1 "Implementing load balancing" >> >> "There currently is no description of a classification function in >> IPFIX." >> >> This is normal as IPFIX is the export protocol. You speak about a >> specific feature of the Exporting Process that would use RFC5101 >> >> "According to the current specification, Exporters send all >> Flow Records to multiple Collectors and Collectors drop >> uninteresting >> Flow Records to reduce their load." >> >> This is wrong. > > Wrong? If so, I can not image the current specification regarding > classification. > > As another case, observed packets become input to multiple Metering > Processes, and in each Metering Process, these interesting packets are > selected. Finally, output of each Metering Process is sent to a > specific > Collector. Is it correct? Purpose of section 5.1 is to say "we need classification function". I believes that we all shares the purpose. Then, we need just rewrite the section. >> "The Collector, however, needs to recognize the >> precise Observation Point whether Flow Records go through an IPFIX >> Mediator or not." >> >> This is not always true. The answer is: it depends. > > Yes. Not alway. For example, in creating traffic matrix using > exporter IP > address it is necessary. I will improve. > > > >> For example, for the core traffic matrix in capacity planning, having >> the router exporting the flow records is enough. > >> - section 5.6 "session management" >> You want to talk about transport session, right? (to refer to >> RFC5101) > > Yes. It means "Transport Session". > >> This session is confusing. After reading several times, I understand >> that you speak about the Collecting and Exporting Processes of the >> mediation device. > > Yes. I will improve. > >> - section 5.6 >> >> "If the session >> between a Router and a Mediator fails and the IPFIX Mediator shuts >> down the session between the Collector and the Mediator, the >> Collector would futilely continue to try to establish the session." >> >> "If >> one of these sessions between Routers and the Mediator fails and >> IPFIX Mediator shuts down the session between a Collector and the >> Mediator, other sessions between the Routers and the Mediator would >> not be relayed at all." >> >> Not necessarily. It depends how we write the specifications. > > You mean that removing all of section 5.6 is better? > >> - Section 5.6, last paragraph. >> >> "Even if one session is reset, >> the status of the other sessions is kept. However, if Templates >> that >> reset the session of Collecting Processes would not be withdrawn, >> there is a possibility that assigned Template IDs overlap. The >> Collector might then shut down IPFIX session, because it identifies >> the overlapping Template ID as part of an anomalous message. In >> the >> case of resetting a session of the Collecting Process, the >> operation >> processed by IPFIX Mediator should be defined." >> >> This is wrong IMHO. The mediation device should take care of the >> management of NEW templates. We can't rely on the template id >> received. > > I think that it is not necessary to rewrite Template ID in case of > relaying from one Transport Session to one Transport Session. > > But, exactly, assigning new template id in case of all situation is > safer for IPFIX protocol. > > You mean that IPFIX Mediator implemented in relation to RFC5101 does > not > fall into the situation mentioned in section 5.6? After all, section > 5.6 > is not necessary, is it? It seems deletable. Purpose of section 5.6 is to say "some kind of session management is needed". Since the draft is problem statements, I agree that current draft description is too detailed and should be categorized requirement or specification. > > > Regards, > Atsushi KOBAYASHI > >> >> Regards, Benoit. >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------------- Original Message Ends -------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix matrix in capacity planning, having >> the router exporting the flow records is enough. > >> - section 5.6 "session management" >> You want to talk about transport session, right? (to refer to >> RFC5101) > > Yes. It means "Transport Session". > >> This session is confusing. After reading several times, I understand >> that you speak about the Collecting and Exporting Processes of the >> mediation device. > > Yes. I will improve. > >> - section 5.6 >> >> "If the session >> between a Router and a Mediator fails and the IPFIX Mediator shuts >> down the session between the Collector and the Mediator, the >> Collector would futilely continue to try to establish the session." >> >> "If >> one of these sessions between Routers and the Mediator fails and >> IPFIX Mediator shuts down the session between a Collector and the >> Mediator, other sessions between the Routers and the Mediator would >> not be relayed at all." >> >> Not necessarily. It depends how we write the specifications. > > You mean that removing all of section 5.6 is better? > >> - Section 5.6, last paragraph. >> >> "Even if one session is reset, >> the status of the other sessions is kept. However, if Templates >> that >> reset the session of Collecting Processes would not be withdrawn, >> there is a possibility that assigned Template IDs overlap. The >> Collector might then shut down IPFIX session, because it identifies >> the overlapping Template ID as part of an anomalous message. In >> the >> case of resetting a session of the Collecting Process, the >> operation >> processed by IPFIX Mediator should be defined." >> >> This is wrong IMHO. The mediation device should take care of the >> management of NEW templates. We can't rely on the template id >> received. > > I think that it is not necessary to rewrite Template ID in case of > relaying from one Transport Session to one Transport Session. > > But, exactly, assigning new template id in case of all situation is > safer for IPFIX protocol. > > You mean that IPFIX Mediator implemented in relation to RFC5101 does > not > fall into the situation mentioned in section 5.6? After all, section > 5.6 > is not necessary, is it? It seems deletable. Purpose of section 5.6 is to say "some kind of session management is needed". Since the draft is problem statements, I agree that current draft description is too detailed and should be categorized requirement or specification. > > > Regards, > Atsushi KOBAYASHI > >> >> Regards, Benoit. >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------------- Original Message Ends -------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From kpeto@att.com Mon Mar 10 11:09:47 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E23628C381 for ; Mon, 10 Mar 2008 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.87 X-Spam-Level: X-Spam-Status: No, score=-9.87 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT2=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DIALUP=0.862, HOST_EQ_DIALUP=0.862, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, RELAY_IS_203=0.994, SARE_ADLTSUB2=1.23, SARE_ADULT2=1.42, SARE_SUB_PENIS=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYqdadgjkb93 for ; Mon, 10 Mar 2008 11:09:46 -0700 (PDT) Received: from 203-109-226-85.dialup.ihug.co.nz (203-109-226-85.dialup.ihug.co.nz [203.109.226.85]) by core3.amsl.com (Postfix) with ESMTP id E72793A6D0D for ; Mon, 10 Mar 2008 11:07:59 -0700 (PDT) Date: Mon, 10 Mar 2008 16:17:56 +0000 From: "early toby" X-Mailer: The Bat! (v3.99.27) UNREG X-Priority: 3 (Normal) Message-ID: <05705662.20080310180519@lists.ietf.org> To: "Aurelia Peacock" Subject: Top Penis Enlargement... Get Real Results MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Gain An Amazing 1 to 3 full Inches! VPXL Has Worked For THOUSANDS of Clients. http://burtieoae.com/ From ipfix-bounces@ietf.org Mon Mar 10 20:15:56 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4463A6A7A; Mon, 10 Mar 2008 20:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.157 X-Spam-Level: X-Spam-Status: No, score=-101.157 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8k5thZsoPpL; Mon, 10 Mar 2008 20:15:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E54B3A6A39; Mon, 10 Mar 2008 20:15:55 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CDB3A6A1E for ; Mon, 10 Mar 2008 20:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FezN6AnIb7gs for ; Mon, 10 Mar 2008 20:15:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id BFDC93A6931 for ; Mon, 10 Mar 2008 20:15:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2B3DUq22453 for ; Tue, 11 Mar 2008 04:13:30 +0100 (CET) Received: from [10.82.249.186] (rtp-vpn6-441.cisco.com [10.82.249.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2B3DRB13432 for ; Tue, 11 Mar 2008 04:13:28 +0100 (CET) Message-ID: <47D5F8D7.2070103@cisco.com> Date: Mon, 10 Mar 2008 23:13:27 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122939254==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============2122939254== Content-Type: multipart/alternative; boundary="------------020504000507080002030605" This is a multi-part message in MIME format. --------------020504000507080002030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Elisa, Lutz, Tanja, Arno, The draft improved a lot compared to last version. I have some feedback anyway. A couple of points to be discussed: - during the last IETF meeting, I mentioned that it would be nice to have a delimiter, in order to get some diagnostics information. Note: my (biased) view is the one from a router vendor, so I'm thinking about router diagnostics. You mention "IPFIX files contain only IPFIX messages". I would like to remove that restriction. You inserted the opaqueOctets. This is nice, but heavy compared to a file delimiter - I would like to have a few words about writing into a file directly from a router, for example in section 6.4 - I think that you would benefit from the per-SCTP stream, as the order is From ipfix-bounces@ietf.org Mon Mar 10 20:15:56 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4463A6A7A; Mon, 10 Mar 2008 20:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.157 X-Spam-Level: X-Spam-Status: No, score=-101.157 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8k5thZsoPpL; Mon, 10 Mar 2008 20:15:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E54B3A6A39; Mon, 10 Mar 2008 20:15:55 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CDB3A6A1E for ; Mon, 10 Mar 2008 20:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FezN6AnIb7gs for ; Mon, 10 Mar 2008 20:15:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id BFDC93A6931 for ; Mon, 10 Mar 2008 20:15:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2B3DUq22453 for ; Tue, 11 Mar 2008 04:13:30 +0100 (CET) Received: from [10.82.249.186] (rtp-vpn6-441.cisco.com [10.82.249.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2B3DRB13432 for ; Tue, 11 Mar 2008 04:13:28 +0100 (CET) Message-ID: <47D5F8D7.2070103@cisco.com> Date: Mon, 10 Mar 2008 23:13:27 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" Subject: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122939254==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============2122939254== Content-Type: multipart/alternative; boundary="------------020504000507080002030605" This is a multi-part message in MIME format. --------------020504000507080002030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Elisa, Lutz, Tanja, Arno, The draft improved a lot compared to last version. I have some feedback anyway. A couple of points to be discussed: - during the last IETF meeting, I mentioned that it would be nice to have a delimiter, in order to get some diagnostics information. Note: my (biased) view is the one from a router vendor, so I'm thinking about router diagnostics. You mention "IPFIX files contain only IPFIX messages". I would like to remove that restriction. You inserted the opaqueOctets. This is nice, but heavy compared to a file delimiter - I would like to have a few words about writing into a file directly from a router, for example in section 6.4 - I think that you would benefit from the per-SCTP stream, as the order is maintained. It might be worth stressing that, if the per-SCTP stream is implemented, we would not have the timing issue related to data records sent to multiple SCTP stream. - While I understand that you would like to have the Template(s) at the beginning of the file, it will require huge buffers on a router... unless the per-SCTP stream is supported. That's another advantage of that draft. - how do we treat SCTP assocation and TCP connection reset? the file must be ended? - informationElementAnonymized was in the previous version, but not anymore in this draft. I see "The data described by this Template contains anonymized source and destination IPv4 addresses.". How is it possible without this I.E.? Btw, we should have an anomized I.E., similar to the key IE. - messageScope, sessionScope, etc...: instead of multiplying the information elements "...Scope", for which the content is ignored, why not have a "scope" IE with some values in there. Like in RFC3954: Scope 1 Field Type The relevant portion of the Exporter/NetFlow process to which the Options Template Record refers. Currently defined values are: 1 System 2 Interface 3 Line Card 4 Cache 5 Template - 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, maxExportSeconds? Why not any of the time related I.E.? Not to duplicate the I.Es? Some editorial feedback - IPFIX file reader and writer: instead of "analogous to", what about a "special case of" - section 3, why do you repeat the definition of the IPFIX file... just after the section 2 "terminology" btw - a couple of terms from RFC5101 are not capitalized. For example, "flow" - you mentioned a few times "flow data". Why not Flow Record? unless you want to be generic? - section 5.1 is "record format flexibility" and you speak about "extensibility" - I don't understand what you mean in "The IPFIX Message format has no direct support for indexing. However, its template mechanism and the technique described in "Reducing Redundancy in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy ] can be used to describe the contents of a file in a limited way." - acronyms RAID, CBC - As testing is certainly not the primary use, I would order the section 6.x in this order 6.1 storage of ipfix-collected flow data 6.2 testing IPFIX collecting process - I'm not sure 6.3 "storage of NetFlow version 9-collected flow data" is an applicability of this draft. - in Section 6.2, you have "MAY". This is a specification while this is the applicability section. - IPFIX Transport -> IPFIX transport - message -> IPFIX Message (a few instances) - "options record" is not a valid term according to RFC5101 - that would be good to explicitely show that the IPFIX header is included. For example, in figure 1 Regards, Benoit. --------------020504000507080002030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, Elisa, Lutz, Tanja, Arno,

The draft improved a lot compared to last version.
I have some feedback anyway.

A couple of points to be discussed:
- during the last IETF meeting, I mentioned that it would be nice to have a delimiter, in order to get some diagnostics information. Note: my (biased) view is the one from a router vendor, so I'm thinking about router diagnostics. You mention "IPFIX files contain only IPFIX messages". I would like to remove that restriction.
You inserted the opaqueOctets. This is nice, but heavy compared to a file delimiter
- I would like to have a few words about writing into a file directly from a router, for example in section 6.4
- I think that you would benefit from the per-SCTP stream, as maintained. It might be worth stressing that, if the per-SCTP stream is implemented, we would not have the timing issue related to data records sent to multiple SCTP stream. - While I understand that you would like to have the Template(s) at the beginning of the file, it will require huge buffers on a router... unless the per-SCTP stream is supported. That's another advantage of that draft. - how do we treat SCTP assocation and TCP connection reset? the file must be ended? - informationElementAnonymized was in the previous version, but not anymore in this draft. I see "The data described by this Template contains anonymized source and destination IPv4 addresses.". How is it possible without this I.E.? Btw, we should have an anomized I.E., similar to the key IE. - messageScope, sessionScope, etc...: instead of multiplying the information elements "...Scope", for which the content is ignored, why not have a "scope" IE with some values in there. Like in RFC3954: Scope 1 Field Type The relevant portion of the Exporter/NetFlow process to which the Options Template Record refers. Currently defined values are: 1 System 2 Interface 3 Line Card 4 Cache 5 Template - 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, maxExportSeconds? Why not any of the time related I.E.? Not to duplicate the I.Es? Some editorial feedback - IPFIX file reader and writer: instead of "analogous to", what about a "special case of" - section 3, why do you repeat the definition of the IPFIX file... just after the section 2 "terminology" btw - a couple of terms from RFC5101 are not capitalized. For example, "flow" - you mentioned a few times "flow data". Why not Flow Record? unless you want to be generic? - section 5.1 is "record format flexibility" and you speak about "extensibility" - I don't understand what you mean in "The IPFIX Message format has no direct support for indexing. However, its template mechanism and the technique described in "Reducing Redundancy in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy ] can be used to describe the contents of a file in a limited way." - acronyms RAID, CBC - As testing is certainly not the primary use, I would order the section 6.x in this order 6.1 storage of ipfix-collected flow data 6.2 testing IPFIX collecting process - I'm not sure 6.3 "storage of NetFlow version 9-collected flow data" is an applicability of this draft. - in Section 6.2, you have "MAY". This is a specification while this is the applicability section. - IPFIX Transport -> IPFIX transport - message -> IPFIX Message (a few instances) - "options record" is not a valid term according to RFC5101 - that would be good to explicitely show that the IPFIX header is included. For example, in figure 1 Regards, Benoit. --------------020504000507080002030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, Elisa, Lutz, Tanja, Arno,

The draft improved a lot compared to last version.
I have some feedback anyway.

A couple of points to be discussed:
- during the last IETF meeting, I mentioned that it would be nice to have a delimiter, in order to get some diagnostics information. Note: my (biased) view is the one from a router vendor, so I'm thinking about router diagnostics. You mention "IPFIX files contain only IPFIX messages". I would like to remove that restriction.
You inserted the opaqueOctets. This is nice, but heavy compared to a file delimiter
- I would like to have a few words about writing into a file directly from a router, for example in section 6.4
- I think that you would benefit from the per-SCTP stream, as the order is maintained. It might be worth stressing that, if the per-SCTP stream is implemented, we would not have the timing issue related to data records sent to multiple SCTP stream.
- While I understand that you would like to have the Template(s) at the beginning of the file, it will require huge buffers on a router... unless the per-SCTP stream is supported. That's another advantage of that draft.
- how do we treat SCTP assocation and TCP connection reset? the file must be ended?
- informationElementAnonymized was in the previous version, but not anymore in this draft. I see "The data described by this Template contains anonymized source and destination IPv4 addresses.". How is it possible without this I.E.? Btw, we should have an anomized I.E., similar to the key IE.
- messageScope, sessionScope, etc...: instead of multiplying the information elements "...Scope", for which the content is ignored, why not have a "scope" IE with some values in there. Like in RFC3954:
 Scope 1 Field Type
         The relevant portion of the Exporter/NetFlow process to which
         the Options Template Record refers.
         Currently defined values are:
            1 System
            2 Interface
            3 Line Card
            4 Cache
            5 Template
- 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, maxExportSeconds? Why not any of the time related I.E.? Not to duplicate the I.Es?


Some editorial feedback
- IPFIX file reader and writer: instead of "analogous to", what about a "special case of"
- section 3, why do you repeat the definition of the IPFIX file... just after the section 2 "terminology" btw
- a couple of terms from RFC5101 are not capitalized. For example, "flow"
- you mentioned a few times "flow data". Why not Flow Record? unless you want to be generic?
- section 5.1 is "record format flexibility" and you speak about "extensibility"
- I don't understand what you mean in
      "The IPFIX Message format has no direct support for indexing.
However, its template mechanism and the technique described in
"Reducing Redundancy in IPFIX and PSAMP Reports"
[I-D.ietf-ipfix-reducing-redundancy] can be used to describe the
contents of a file in a limited way."
- acronyms RAID, CBC
- As testing is certainly not the primary use, I would order the section 6.x in this order
     6.1 storage of ipfix-collected flow data
     6.2 testing IPFIX collecting process
- I'm not sure 6.3 "storage of NetFlow version 9-collected flow data" is an applicability of this draft.
- in Section 6.2, you have "MAY". This is a specification while this is the applicability section.
- IPFIX Transport -> IPFIX transport
- message -> IPFIX Message (a few instances)
- "options record" is not a valid term according to RFC5101
- that would be good to explicitely show that the IPFIX header is included. For example, in figure 1

Regards, Benoit.

--------------020504000507080002030605-- --===============2122939254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============2122939254==-- the order is maintained. It might be worth stressing that, if the per-SCTP stream is implemented, we would not have the timing issue related to data records sent to multiple SCTP stream.
- While I understand that you would like to have the Template(s) at the beginning of the file, it will require huge buffers on a router... unless the per-SCTP stream is supported. That's another advantage of that draft.
- how do we treat SCTP assocation and TCP connection reset? the file must be ended?
- informationElementAnonymized was in the previous version, but not anymore in this draft. I see "The data described by this Template contains anonymized source and destination IPv4 addresses.". How is it possible without this I.E.? Btw, we should have an anomized I.E., similar to the key IE.
- messageScope, sessionScope, etc...: instead of multiplying the information elements "...Scope", for which the content is ignored, why not have a "scope" IE with some values in there. Like in RFC3954:
 Scope 1 Field Type
         The relevant portion of the Exporter/NetFlow process to which
         the Options Template Record refers.
         Currently defined values are:
            1 System
            2 Interface
            3 Line Card
            4 Cache
            5 Template
- 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, maxExportSeconds? Why not any of the time related I.E.? Not to duplicate the I.Es?


Some editorial feedback
- IPFIX file reader and writer: instead of "analogous to", what about a "special case of"
- section 3, why do you repeat the definition of the IPFIX file... just after the section 2 "terminology" btw
- a couple of terms from RFC5101 are not capitalized. For example, "flow"
- you mentioned a few times "flow data". Why not Flow Record? unless you want to be generic?
- section 5.1 is "record format flexibility" and you speak about "extensibility"
- I don't understand what you mean in
      "The IPFIX Message format has no direct support for indexing.
However, its template mechanism and the technique described in
"Reducing Redundancy in IPFIX and PSAMP Reports"
[I-D.ietf-ipfix-reducing-redundancy] can be used to describe the
contents of a file in a limited way."
- acronyms RAID, CBC
- As testing is certainly not the primary use, I would order the section 6.x in this order
     6.1 storage of ipfix-collected flow data
     6.2 testing IPFIX collecting process
- I'm not sure 6.3 "storage of NetFlow version 9-collected flow data" is an applicability of this draft.
- in Section 6.2, you have "MAY". This is a specification while this is the applicability section.
- IPFIX Transport -> IPFIX transport
- message -> IPFIX Message (a few instances)
- "options record" is not a valid term according to RFC5101
- that would be good to explicitely show that the IPFIX header is included. For example, in figure 1

Regards, Benoit.

--------------020504000507080002030605-- --===============2122939254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============2122939254==-- From ipfix-bounces@ietf.org Tue Mar 11 03:20:57 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C473928C377; Tue, 11 Mar 2008 03:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOg90sVV1g2a; Tue, 11 Mar 2008 03:20:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD58228C364; Tue, 11 Mar 2008 03:20:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580BA3A6A01 for ; Tue, 11 Mar 2008 03:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNzWCFQ59LCm for ; Tue, 11 Mar 2008 03:20:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E3E8228C36A for ; Tue, 11 Mar 2008 03:20:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,479,1199660400"; d="scan'208";a="3100789" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2008 11:18:28 +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/8.12.11) with ESMTP id m2BAISNh016892; Tue, 11 Mar 2008 11:18:28 +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 m2BAIRHC018860; Tue, 11 Mar 2008 10:18:27 GMT Received: from [10.61.64.103] (ams3-vpn-dhcp103.cisco.com [10.61.64.103]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2BAIRr15856; Tue, 11 Mar 2008 10:18:27 GMT Message-ID: <47D65C7B.8030506@cisco.com> Date: Tue, 11 Mar 2008 10:18:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Benoit Claise References: <47D5F8D7.2070103@cisco.com> In-Reply-To: <47D5F8D7.2070103@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1116; t=1205230708; x=1206094708; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20[IPFIX]=20IPFIX-based=20file=20format=3A=0A=20feedback |Sender:=20; bh=/tcIYxhWUE8kTGcJjL0veiIpDsCiiQKs/w0kpzaqBLw=; b=e8rHmXfFGqqq3QDQ/FRfp/C3g4iqAdwzJn6aNYXe1mGJCQUmB6/zt38QMd Ort8cluwAAw2z0Lv8ZnXO7No79hGY4NbqDXUwTDDbGk97A6CqkBhO7l8kSsz adyDPg7GNz; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-asFrom ipfix-bounces@ietf.org Tue Mar 11 03:20:57 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C473928C377; Tue, 11 Mar 2008 03:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOg90sVV1g2a; Tue, 11 Mar 2008 03:20:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD58228C364; Tue, 11 Mar 2008 03:20:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580BA3A6A01 for ; Tue, 11 Mar 2008 03:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNzWCFQ59LCm for ; Tue, 11 Mar 2008 03:20:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E3E8228C36A for ; Tue, 11 Mar 2008 03:20:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,479,1199660400"; d="scan'208";a="3100789" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2008 11:18:28 +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/8.12.11) with ESMTP id m2BAISNh016892; Tue, 11 Mar 2008 11:18:28 +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 m2BAIRHC018860; Tue, 11 Mar 2008 10:18:27 GMT Received: from [10.61.64.103] (ams3-vpn-dhcp103.cisco.com [10.61.64.103]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2BAIRr15856; Tue, 11 Mar 2008 10:18:27 GMT Message-ID: <47D65C7B.8030506@cisco.com> Date: Tue, 11 Mar 2008 10:18:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Benoit Claise References: <47D5F8D7.2070103@cisco.com> In-Reply-To: <47D5F8D7.2070103@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1116; t=1205230708; x=1206094708; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20[IPFIX]=20IPFIX-based=20file=20format=3A=0A=20feedback |Sender:=20; bh=/tcIYxhWUE8kTGcJjL0veiIpDsCiiQKs/w0kpzaqBLw=; b=e8rHmXfFGqqq3QDQ/FRfp/C3g4iqAdwzJn6aNYXe1mGJCQUmB6/zt38QMd Ort8cluwAAw2z0Lv8ZnXO7No79hGY4NbqDXUwTDDbGk97A6CqkBhO7l8kSsz adyDPg7GNz; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Benoit, Brian, Elisa, Lutz, Tanja, Arno, > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, why > not have a "scope" IE with some values in there. Like in RFC3954: > > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template By all means have a scope IE - but please don't begin to define a new value registry for it. Instead, allow it to be populated with any existing IE, extending the existing IE list if necessary. The RFC3954 registry above is comparable to existing IPFIX IEs: 1 System #149 observationDomainId 2 Interface #10 ingressInterface, #14 egressInterface 3 Line Card #141 lineCardId 4 Cache 5 Template #145 templateId Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix cii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Benoit, Brian, Elisa, Lutz, Tanja, Arno, > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, why > not have a "scope" IE with some values in there. Like in RFC3954: > > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template By all means have a scope IE - but please don't begin to define a new value registry for it. Instead, allow it to be populated with any existing IE, extending the existing IE list if necessary. The RFC3954 registry above is comparable to existing IPFIX IEs: 1 System #149 observationDomainId 2 Interface #10 ingressInterface, #14 egressInterface 3 Line Card #141 lineCardId 4 Cache 5 Template #145 templateId Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Mar 11 07:05:25 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2572D28C404; Tue, 11 Mar 2008 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.722 X-Spam-Level: X-Spam-Status: No, score=-100.722 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlffHDuEefyY; Tue, 11 Mar 2008 07:05:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B013A68DE; Tue, 11 Mar 2008 07:05:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDCA28C3AB for ; Tue, 11 Mar 2008 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNAoKdJbysW0 for ; Tue, 11 Mar 2008 07:05:20 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id A0DE73A69C0 for ; Tue, 11 Mar 2008 07:05:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 963D8480414 for ; Wed, 12 Mar 2008 03:03:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDvzAtVoCjgJ for ; Wed, 12 Mar 2008 03:03:00 +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 mailhost.auckland.ac.nz (Postfix) with ESMTP id 73E10480412 for ; Wed, 12 Mar 2008 03:03:00 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.13.1/8.13.1) with ESMTP id m2BE30Ml021907 for ; Wed, 12 Mar 2008 03:03:00 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.13.1/8.13.1/Submit) id m2BE30PR021906 for ipfix@ietf.org; Wed, 12 Mar 2008 03:03:00 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dhcp-33dd.ietf71.ietf.org (dhcp-33dd.ietf71.ietf.org [130.129.51.221]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Wed, 12 Mar 2008 03:03:00 +1300 Message-ID: <20080312030300.dj17mfb0ysscw0ws@webmail.auckland.ac.nz> Date: Wed, 12 Mar 2008 03:03:00 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) Subject: [IPFIX] Presentations for IPFIX session this afternoon X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put all the presentations I've reFrom ipfix-bounces@ietf.org Tue Mar 11 07:05:25 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2572D28C404; Tue, 11 Mar 2008 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.722 X-Spam-Level: X-Spam-Status: No, score=-100.722 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlffHDuEefyY; Tue, 11 Mar 2008 07:05:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B013A68DE; Tue, 11 Mar 2008 07:05:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDCA28C3AB for ; Tue, 11 Mar 2008 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNAoKdJbysW0 for ; Tue, 11 Mar 2008 07:05:20 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id A0DE73A69C0 for ; Tue, 11 Mar 2008 07:05:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 963D8480414 for ; Wed, 12 Mar 2008 03:03:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDvzAtVoCjgJ for ; Wed, 12 Mar 2008 03:03:00 +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 mailhost.auckland.ac.nz (Postfix) with ESMTP id 73E10480412 for ; Wed, 12 Mar 2008 03:03:00 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.13.1/8.13.1) with ESMTP id m2BE30Ml021907 for ; Wed, 12 Mar 2008 03:03:00 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.13.1/8.13.1/Submit) id m2BE30PR021906 for ipfix@ietf.org; Wed, 12 Mar 2008 03:03:00 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dhcp-33dd.ietf71.ietf.org (dhcp-33dd.ietf71.ietf.org [130.129.51.221]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Wed, 12 Mar 2008 03:03:00 +1300 Message-ID: <20080312030300.dj17mfb0ysscw0ws@webmail.auckland.ac.nz> Date: Wed, 12 Mar 2008 03:03:00 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) Subject: [IPFIX] Presentations for IPFIX session this afternoon X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put all the presentations I've received so far on the meeting materials page, i.e. at https://datatracker.ietf.org/meeting/71/materials If you're presenting, or want to send me an updated version of your presentation, please email it to me real soon now ... See you this afternoon, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ceived so far on the meeting materials page, i.e. at https://datatracker.ietf.org/meeting/71/materials If you're presenting, or want to send me an updated version of your presentation, please email it to me real soon now ... See you this afternoon, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Mar 11 09:05:41 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921CB28C39D; Tue, 11 Mar 2008 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd-I8AMfhsMP; Tue, 11 Mar 2008 09:05:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D755A28C1B9; Tue, 11 Mar 2008 09:05:39 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D213728C128 for ; Tue, 11 Mar 2008 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rc1nSlYQZsU for ; Tue, 11 Mar 2008 09:05:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C352228C1B9 for ; Tue, 11 Mar 2008 09:05:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG3FN02699; Tue, 11 Mar 2008 17:03:15 +0100 (CET) Received: from [10.82.241.14] (rtp-vpn2-270.cisco.com [10.82.241.14]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG3BB05431; Tue, 11 Mar 2008 17:03:13 +0100 (CET) Message-ID: <47D6AD3F.3080102@cisco.com> Date: Tue, 11 Mar 2008 12:03:11 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Kobayashi Atsushi References: <47D4A086.4040706@cisco.com> <20080310154551.5663.AKOBA@nttv6.net> In-Reply-To: <20080310154551.5663.AKOBA@nttv6.net> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0681601788==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0681601788== Content-Type: multipart/alternative; boundary="------------090804080601030409090404" This is a multi-part message in MIME format. --------------090804080601030409090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kobayashi-san, > > > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've >> seen 1/100 >> > > Where is it? > I mentioned that "typically sampling packets with rates ranging from > 1/10,000 to 1/1,000". > I mean that I have seen customers with 1/100. > >> - Section 3.1. You're missing an important application -> data retention. >> > > You mean that data retention is storage of traffic data during reasonable > amount of time according to government regulation? > I was not familiar with data retention using NetFlow/sFlow. Exactly, > NetFlow/sFlow/IPFIX can become the tool for data retention. > Data retention is now a law at the European level. And obviously, NetFlow/IPFIX is a master piece in the architecture. > >> - I would develop further the section 4.2 to express that there is a >> different approach than exporting complete flow records to a mediation >> device, which in turn does some aggregation/filtering. I mean, the >> router have several different caches, each optimized for a specific >> application. So each cache has its own series of flow keys. And the >> content of each cache is sent to a specific collector. For example, a >> collector for security, another one for capacity planning, etc... >> > > I can image you mentioned. > Each cache has its own Flow Keys. The output of each cache is send to a > specific collector. > Exactly. > >> - Section 4.4 "In general, load balancing allows work of Collectors to >> be divided. Classifying Flow Records based on the value of specified >> Information Elements can prove to be very useful to achive scalability. >> " This is not load balancing, as the title says. >> > > Does it prefer "load sharing method" or "load distribution"? > Maybe export filtering? > > > >> - section 5.1 "Implementing load balancing" >> >> "There currently is no description of a classification function in >> IPFIX." >> >> This is normal as IPFIX is the export protocol. You speak about a >> specific feature of the Exporting Process that would use RFC5101 >> >> "According to the current specification, Exporters send all >> Flow Records to multiple Collectors and Collectors drop uninteresting >> Flow Records to reduce their load." >> >> This is wrong. >> > > Wrong? If so, I can not image the current specification regarding > classification. > I mean that IPFIX, being an export protocol, doesn't impose any constraints on the metering process and on what you export to collectors. It doesn't impose that you export ALL flow records to collector(s), and then do filtering. Hence, my example in this email thread: multiple caches, each with its own set of flow keys, exported to different collectors. Even if you add filtering before exporting, you can still use IPFIX. > As another case, observed packets become input to multiple Metering > Processes, and in each Metering Process, these interesting packets are > selected. Finally, output of each Metering Process is sent to a specific > Collector. Is it correct? > >> - section 5.6 >> >> "If the session >> between a Router and a Mediator fails and the IPFIX Mediator shuts >> down the session between the Collector and the Mediator, the >> Collector would futilely continue to try to establish the session." >> >> "If >> one of these sessions between Routers and the Mediator fails and >> IPFIX Mediator shuts down the session between a Collector and the >> Mediator, other sessions between the Routers and the Mediator would >> not be relayed at all." >> >> Not necessarily. It depends how we write the specifications. >> > > You mean that removing all of section 5.6 is better? > no, I mean that your statements assume certain specifications/implementations at the mediation device. > >> - Section 5.6, last paragraph. >> >> "Even if one session is reset, >> the status of the other sessions is kept. However, if Templates that >> reset the session of Collecting Processes would not be withdrawn, >> there is a possibility that assigned Template IDs overlap. The >> Collector might then shut down IPFIX session, because it identifies >> the overlapping Template ID as part of an anomalous message. In the >> case of resetting a session of the Collecting Process, the operation >> processed by IPFIX Mediator should be defined." >> >> This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. >> > > I think that it is not necessary to rewrite Template ID in case of > relaying from one Transport Session to one Transport Session. > Correct, but that's the only case. And if you have a single Transport Session matching to another Transport Session, I'm questioning the need for a mediation device ;-) > But, exactly, assigning new template id in case of all situation is > safer for IPFIX protocol. > > You mean that IPFIX Mediator implemented in relation to RFC5101 does not > fall into the situation mentioned in section 5.6? After all, section 5.6 > is not necessary, is it? It seems deletable. > I think that you should leave it in there, but that you have to explain the potential problems, without assuming a specific implementation. Regards, Benoit. > Regards, > Atsushi KOBAYASHI > > >> Regards, Benoit. >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------090804080601030409090404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Kobayashi-san,


  
- Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've 
seen 1/100
    

Where is it?
I mentioned that "typically sampling packets with rates ranging from
1/10,000 to 1/1,000".
I mean that I have seen customers with 1/100.
  
- Section 3.1. You're missing an important application -> data retention.
    

You mean that data retention is storage of traffic data during reasonable
amount of time according to government regulation?
I was not familiar with data retention using NetFlow/sFlow. Exactly,
NetFlow/sFlow/IPFIX can become the tool for data retention.
Data retention is now a law at the European level.
And obviously, NetFlow/IPFIX is a master piece in the architecture.
  
- I would develop further the section 4.2 to express that there is a 
different approach than exporting complete flow records to a mediation 
device, which in turn does some aggregation/filtering. I mean, the 
router have several different caches, each optimized for a specific 
application. So each cache has its own series of flow keys. And the 
content of each cache is sent to a specific collector. For example, a 
collector for security, another one for capacity planning, etc...
    

I can image you mentioned.
Each cache has its own Flow Keys. The output of each cache is send to a
specific collector.
Exactly.
  
- Section 4.4 "In general, load balancing allows work of Collectors to 
be divided. Classifying Flow Records based on the value of specified 
Information Elements can prove to be very useful to achive scalability. 
" This is not load balancing, as the title says.
    

Does it prefer "load sharing method" or "load distribution"?
Maybe export filtering?



  
- section 5.1 "Implementing load balancing"

   "There currently is no description of a classification function in
   IPFIX."

This is normal as IPFIX is the export protocol. You speak about a 
specific feature of the Exporting Process that would use RFC5101

   "According to the current specification, Exporters send all
   Flow Records to multiple Collectors and Collectors drop uninteresting
   Flow Records to reduce their load."

This is wrong.
    

Wrong? If so, I can not image the current specification regarding
classification.
I mean that IPFIX, being an export protocol, doesn't impose any constraints on the metering process and on what you export to collectors.
It doesn't impose that you export ALL flow records to collector(s), and then do filtering.
Hence, my example in this email thread: multiple caches, each with its own set of flow keys, exported to different collectors. Even if you add filtering before exporting, you can still use IPFIX.
As another case, observed packets become input to multiple Metering
Processes, and in each Metering Process, these interesting packets are
selected. Finally, output of each Metering Process is sent to a specific
Collector. Is it correct?
  
- section 5.6

   "If the session
   between a Router and a Mediator fails and the IPFIX Mediator shuts
   down the session between the Collector and the Mediator, the
   Collector would futilely continue to try to establish the session."

   "If
   one of these sessions between Routers and the Mediator fails and
   IPFIX Mediator shuts down the session between a Collector and the
   Mediator, other sessions between the Routers and the Mediator would
   not be relayed at all."

Not necessarily. It depends how we write the specifications.
    

You mean that removing all of section 5.6 is better?
no, I mean that your statements assume certain specifications/implementations at the mediation device.
  
- Section 5.6, last paragraph.

   "Even if one session is reset,
   the status of the other sessions is kept.  However, if Templates that
   reset the session of Collecting Processes would not be withdrawn,
   there is a possibility that assigned Template IDs overlap.  The
   Collector might then shut down IPFIX session, because it identifies
   the overlapping Template ID as part of an anomalous message.  In the
   case of resetting a session of the Collecting Process, the operation
   processed by IPFIX Mediator should be defined."

This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received.
    

I think that it is not necessary to rewrite Template ID in case of
relaying from one Transport Session to one Transport Session.
Correct, but that's the only case.
And if you have a single Transport Session matching to another Transport Session, I'm questioning the need for a mediation device ;-) 
But, exactly, assigning new template id in case of all situation is
safer for IPFIX protocol.

You mean that IPFIX Mediator implemented in relation to RFC5101 does not
fall into the situation mentioned in section 5.6? After all, section 5.6
is not necessary, is it? It seems deletable.
I think that you should leave it in there, but that you have to explain the potential problems, without assuming a specific implementation.

Regards, Benoit.
Regards,
Atsushi KOBAYASHI

  
Regards, Benoit.





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

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

--------------090804080601030409090404-- --===============0681601788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0681601788==-- From ipfix-bounces@ietf.org Tue Mar 11 09:05:41 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921CB28C39D; Tue, 11 Mar 2008 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd-I8AMfhsMP; Tue, 11 Mar 2008 09:05:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D755A28C1B9; Tue, 11 Mar 2008 09:05:39 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D213728C128 for ; Tue, 11 Mar 2008 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rc1nSlYQZsU for ; Tue, 11 Mar 2008 09:05:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C352228C1B9 for ; Tue, 11 Mar 2008 09:05:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG3FN02699; Tue, 11 Mar 2008 17:03:15 +0100 (CET) Received: from [10.82.241.14] (rtp-vpn2-270.cisco.com [10.82.241.14]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG3BB05431; Tue, 11 Mar 2008 17:03:13 +0100 (CET) Message-ID: <47D6AD3F.3080102@cisco.com> Date: Tue, 11 Mar 2008 12:03:11 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Kobayashi Atsushi References: <47D4A086.4040706@cisco.com> <20080310154551.5663.AKOBA@nttv6.net> In-Reply-To: <20080310154551.5663.AKOBA@nttv6.net> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0681601788==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0681601788== Content-Type: multipart/alternative; boundary="------------090804080601030409090404" This is a multi-part message in MIME format. --------------090804080601030409090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kobayashi-san, > > > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've >> seen 1/100 >> > > Where is it? > I mentioned that "typically sampling packets with rates ranging from > 1/10,000 to 1/1,000". > I mean that I have seen customers with 1/100. > >> - Section 3.1. You're missing an important application -> data retention. >> > > You mean that data retention is storage of traffic data during reasonable > amount of time according to government regulation? > I was not familiar with data retention using NetFlow/sFlow. Exactly, > NetFlow/sFlow/IPFIX can become the tool for data retention. > Data retention is now a law at the European level. And obviously, NetFlow/IPFIX is a master piece in the architecture. > >> - I would develop further the section 4.2 to express that there is a >> different approach than exporting complete flow records to a mediation >> device, which in turn does some aggregation/filtering. I mean, the >> router have several different caches, each optimized for a specific >> application. So each cache has its own series of flow keys. And the >> content of each cache is sent to a specific collector. For example, a >> collector for security, another one for capacity planning, etc... >> > > I can image you mentioned. > Each cache has its own Flow Keys. The output of each cache is send to a > specific collector. > Exactly. > >> - Section 4.4 "In general, load balancing allows work of Collectors to >> be divided. Classifying Flow Records based on the value of specified >> Information Elements can prove to be very useful to achive scalability. >> " This is not load balancing, as the title says. >> > > Does it prefer "load sharing method" or "load distribution"? > Maybe export filtering? > > > >> - section 5.1 "Implementing load balancing" >> >> "There currently is no description of a classification function in >> IPFIX." >> >> This is normal as IPFIX is the export protocol. You speak about a >> specific feature of the Exporting Process that would use RFC5101 >> >> "According to the current specification, Exporters send all >> Flow Records to multiple Collectors and Collectors drop uninteresting >> Flow Records to reduce their load." >> >> This is wrong. >> > > Wrong? If so, I can not image the current specification regarding > classification. > I mean that IPFIX, being an export protocol, doesn't impose any constraints on the metering process and on what you export to collectors. It doesn't impose that you export ALL flow records to collector(s), and then do filtering. Hence, my example in this email thread: multiple caches, each with its own set of flow keys, exported to different collectors. Even if you add filtering before exporting, you can still use IPFIX. > As another case, observed packets become input to multiple Metering > Processes, and in each Metering Process, these interesting packets are > selected. Finally, output of each Metering Process is sent to a specific > Collector. Is it correct? > >> - section 5.6 >> >> "If the session >> between a Router and a Mediator fails and the IPFIX Mediator shuts >> down the session between the Collector and the Mediator, the >> Collector would futilely continue to try to establish the session." >> >> "If >> one of these sessions between Routers and the Mediator fails and >> IPFIX Mediator shuts down the session between a Collector and the >> Mediator, other sessions between the Routers and the Mediator would >> not be relayed at all." >> >> Not necessarily. It depends how we write the specifications. >> > > You mean that removing all of section 5.6 is better? > no, I mean that your statements assume certain specifications/implementations at the mediation device. > >> - Section 5.6, last paragraph. >> >> "Even if one session is reset, >> the status of the other sessions is kept. However, if Templates that >> reset the session of Collecting Processes would not be withdrawn, >> there is a possibility that assigned Template IDs overlap. The >> Collector might then shut down IPFIX session, because it identifies >> the overlapping Template ID as part of an anomalous message. In the >> case of resetting a session of the Collecting Process, the operation >> processed by IPFIX Mediator should be defined." >> >> This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. >> > > I think that it is not necessary to rewrite Template ID in case of > relaying from one Transport Session to one Transport Session. > Correct, but that's the only case. And if you have a single Transport Session matching to another Transport Session, I'm questioning the need for a mediation device ;-) > But, exactly, assigning new template id in case of all situation is > safer for IPFIX protocol. > > You mean that IPFIX Mediator implemented in relation to RFC5101 does not > fall into the situation mentioned in section 5.6? After all, section 5.6 > is not necessary, is it? It seems deletable. > I think that you should leave it in there, but that you have to explain the potential problems, without assuming a specific implementation. Regards, Benoit. > Regards, > Atsushi KOBAYASHI > > >> Regards, Benoit. >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------090804080601030409090404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Kobayashi-san,


  
- Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've 
seen 1/100
    

Where is it?
I mentioned that "typically sampling packets with rates ranging from
1/10,000 to 1/1,000".
I mean that I have seen customers with 1/100.
  
- Section 3.1. You're missing an important application -> data retention.
    

You mean that data retention is storage of traffic data during reasonable
amount of time according to government regulation?
I was not familiar with data retention using NetFlow/sFlow. Exactly,
NetFlow/sFlow/IPFIX can become the tool for data retention.
Data retention is now a law at the European level.
And obviously, NetFlow/IPFIX is a master piece in the architecture.
  
- I would develop further the section 4.2 to express that there is a 
different approach than exporting complete flow records to a mediation 
device, which in turn does some aggregation/filtering. I mean, the 
router have several different caches, each optimized for a specific 
application. So each cache has its own series of flow keys. And the 
content of each cache is sent to a specific collector. For example, a 
collector for security, another one for capacity planning, etc...
    

I can image you mentioned.
Each cache has its own Flow Keys. The output of each cache is send to a
specific collector.
Exactly.
  
- Section 4.4 "In general, load balancing allows work of Collectors to 
be divided. Classifying Flow Records based on the value of specified 
Information Elements can prove to be very useful to achive scalability. 
" This is not load balancing, as the title says.
    

Does it prefer "load sharing method" or "load distribution"?
Maybe export filtering?



  
- section 5.1 "Implementing load balancing"

   "There currently is no description of a classification function in
   IPFIX."

This is normal as IPFIX is the export protocol. You speak about a 
specific feature of the Exporting Process that would use RFC5101

   "According to the current specification, Exporters send all
   Flow Records to multiple Collectors and Collectors drop uninteresting
   Flow Records to reduce their load."

This is wrong.
    

Wrong? If so, I can not image the current specification regarding
classification.
I mean that IPFIX, being an export protocol, doesn't impose any constraints on the metering process and on what you export to collectors.
It doesn't impose that you export ALL flow records to collector(s), and then do filtering.
Hence, my example in this email thread: multiple caches, each with its own set of flow keys, exported to different collectors. Even if you add filtering before exporting, you can still use IPFIX.
As another case, observed packets become input to multiple Metering
Processes, and in each Metering Process, these interesting packets are
selected. Finally, output of each Metering Process is sent to a specific
Collector. Is it correct?
  
- section 5.6

   "If the session
   between a Router and a Mediator fails and the IPFIX Mediator shuts
   down the session between the Collector and the Mediator, the
   Collector would futilely continue to try to establish the session."

   "If
   one of these sessions between Routers and the Mediator fails and
   IPFIX Mediator shuts down the session between a Collector and the
   Mediator, other sessions between the Routers and the Mediator would
   not be relayed at all."

Not necessarily. It depends how we write the specifications.
    

You mean that removing all of section 5.6 is better?
no, I mean that your statements assume certain specifications/implementations at the mediation device.
  
- Section 5.6, last paragraph.

   "Even if one session is reset,
   the status of the other sessions is kept.  However, if Templates that
   reset the session of Collecting Processes would not be withdrawn,
   there is a possibility that assigned Template IDs overlap.  The
   Collector might then shut down IPFIX session, because it identifies
   the overlapping Template ID as part of an anomalous message.  In the
   case of resetting a session of the Collecting Process, the operation
   processed by IPFIX Mediator should be defined."

This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received.
    

I think that it is not necessary to rewrite Template ID in case of
relaying from one Transport Session to one Transport Session.
Correct, but that's the only case.
And if you have a single Transport Session matching to another Transport Session, I'm questioning the need for a mediation device ;-) 
But, exactly, assigning new template id in case of all situation is
safer for IPFIX protocol.

You mean that IPFIX Mediator implemented in relation to RFC5101 does not
fall into the situation mentioned in section 5.6? After all, section 5.6
is not necessary, is it? It seems deletable.
I think that you should leave it in there, but that you have to explain the potential problems, without assuming a specific implementation.

Regards, Benoit.
Regards,
Atsushi KOBAYASHI

  
Regards, Benoit.





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

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

--------------090804080601030409090404-- --===============0681601788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0681601788==-- From ipfix-bounces@ietf.org Tue Mar 11 09:08:20 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E8328C300; Tue, 11 Mar 2008 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.642 X-Spam-Level: X-Spam-Status: No, score=-100.642 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwFJrYsle7hT; Tue, 11 Mar 2008 09:08:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201C93A693B; Tue, 11 Mar 2008 09:08:10 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC7228C397 for ; Tue, 11 Mar 2008 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82coSwt9FOLf for ; Tue, 11 Mar 2008 09:08:03 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 095283A67B1 for ; Tue, 11 Mar 2008 09:07:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG4vB02815; Tue, 11 Mar 2008 17:04:57 +0100 (CET) Received: from [10.82.241.14] (rtp-vpn2-270.cisco.com [10.82.241.14]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG4tB10594; Tue, 11 Mar 2008 17:04:55 +0100 (CET) Message-ID: <47D6ADA6.80909@cisco.com> Date: Tue, 11 Mar 2008 12:04:54 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Haruhiko Nishida References: <20080310234156.5675.AKOBA@nttv6.net> In-Reply-To: Cc: ipfix@ietf.org Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1813475292==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1813475292== Content-Type: multipart/alternative; boundary="------------080409000904020501080304" This is a multi-part message in MIME format. --------------080409000904020501080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Haruhiko-san, >> You mean that data retention is storage of traffic data during >> reasonable >> amount of time according to government regulation? >> I was not familiar with data retention using NetFlow/sFlow. Exactly, >> NetFlow/sFlow/IPFIX can become the tool for data retention. >> > > neither of me nor Kobayashi-san knows about data retention by netflow/ > IPFIX. Could you add some description on the part? > Ok, I'll write some text later. >> >> >>> - Section 5.6, last paragraph. >>> >>> "Even if one session is reset, >>> the status of the other sessions is kept. However, if Templates >>> that >>> reset the session of Collecting Processes would not be withdrawn, >>> there is a possibility that assigned Template IDs overlap. The >>> Collector might then shut down IPFIX session, because it identifies >>> the overlapping Template ID as part of an anomalous message. In >>> the >>> case of resetting a session of the Collecting Process, the >>> operation >>> processed by IPFIX Mediator should be defined." >>> >>> This is wrong IMHO. The mediation device should take care of the >>> management of NEW templates. We can't rely on the template id >>> received. >>> >> I think that it is not necessary to rewrite Template ID in case of >> relaying from one Transport Session to one Transport Session. >> >> But, exactly, assigning new template id in case of all situation is >> safer for IPFIX protocol. >> >> You mean that IPFIX Mediator implemented in relation to RFC5101 does >> not >> fall into the situation mentioned in section 5.6? After all, section >> 5.6 >> is not necessary, is it? It seems deletable. >> > > Purpose of section 5.6 is to say "some kind of session management is > needed". Since the draft is problem statements, I agree that current > draft description is too detailed and should be categorized > requirement or specification. > Exactly. Regards, Benoit. --------------080409000904020501080304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Haruhiko-san, 
You mean that data retention is storage of traffic data during  
reasonable
amount of time according to government regulation?
I was not familiar with data retention using NetFlow/sFlow. Exactly,
NetFlow/sFlow/IPFIX can become the tool for data retention.
    

neither of me nor Kobayashi-san knows about data retention by netflow/ 
IPFIX. Could you add some description on the part?
Ok, I'll write some text later. 

    
- Section 5.6, last paragraph.

  "Even if one session is reset,
  the status of the other sessions is kept.  However, if Templates  
that
  reset the session of Collecting Processes would not be withdrawn,
  there is a possibility that assigned Template IDs overlap.  The
  Collector might then shut down IPFIX session, because it identifies
  the overlapping Template ID as part of an anomalous message.  In  
the
  case of resetting a session of the Collecting Process, the  
operation
  processed by IPFIX Mediator should be defined."

This is wrong IMHO. The mediation device should take care of the  
management of NEW templates. We can't rely on the template id  
received.
      
I think that it is not necessary to rewrite Template ID in case of
relaying from one Transport Session to one Transport Session.

But, exactly, assigning new template id in case of all situation is
safer for IPFIX protocol.

You mean that IPFIX Mediator implemented in relation to RFC5101 does  
not
fall into the situation mentioned in section 5.6? After all, section  
5.6
is not necessary, is it? It seems deletable.
    

Purpose of section 5.6 is to say "some kind of session management is  
needed". Since the draft is problem statements, I agree that current  
draft description is too detailed and should be categorized  
requirement or specification.
Exactly.

Regards, Benoit.
--------------080409000904020501080304-- --===============1813475292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1813475292==-- From ipfix-bounces@ietf.org Tue Mar 11 09:08:20 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E8328C300; Tue, 11 Mar 2008 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.642 X-Spam-Level: X-Spam-Status: No, score=-100.642 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwFJrYsle7hT; Tue, 11 Mar 2008 09:08:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201C93A693B; Tue, 11 Mar 2008 09:08:10 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC7228C397 for ; Tue, 11 Mar 2008 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82coSwt9FOLf for ; Tue, 11 Mar 2008 09:08:03 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 095283A67B1 for ; Tue, 11 Mar 2008 09:07:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG4vB02815; Tue, 11 Mar 2008 17:04:57 +0100 (CET) Received: from [10.82.241.14] (rtp-vpn2-270.cisco.com [10.82.241.14]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2BG4tB10594; Tue, 11 Mar 2008 17:04:55 +0100 (CET) Message-ID: <47D6ADA6.80909@cisco.com> Date: Tue, 11 Mar 2008 12:04:54 -0400 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Haruhiko Nishida References: <20080310234156.5675.AKOBA@nttv6.net> In-Reply-To: Cc: ipfix@ietf.org Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1813475292==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1813475292== Content-Type: multipart/alternative; boundary="------------080409000904020501080304" This is a multi-part message in MIME format. --------------080409000904020501080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Haruhiko-san, >> You mean that data retention is storage of traffic data during >> reasonable >> amount of time according to government regulation? >> I was not familiar with data retention using NetFlow/sFlow. Exactly, >> NetFlow/sFlow/IPFIX can become the tool for data retention. >> > > neither of me nor Kobayashi-san knows about data retention by netflow/ > IPFIX. Could you add some description on the part? > Ok, I'll write some text later. >> >> >>> - Section 5.6, last paragraph. >>> >>> "Even if one session is reset, >>> the status of the other sessions is kept. However, if Templates >>> that >>> reset the session of Collecting Processes would not be withdrawn, >>> there is a possibility that assigned Template IDs overlap. The >>> Collector might then shut down IPFIX session, because it identifies >>> the overlapping Template ID as part of an anomalous message. In >>> the >>> case of resetting a session of the Collecting Process, the >>> operation >>> processed by IPFIX Mediator should be defined." >>> >>> This is wrong IMHO. The mediation device should take care of the >>> management of NEW templates. We can't rely on the template id >>> received. >>> >> I think that it is not necessary to rewrite Template ID in case of >> relaying from one Transport Session to one Transport Session. >> >> But, exactly, assigning new template id in case of all situation is >> safer for IPFIX protocol. >> >> You mean that IPFIX Mediator implemented in relation to RFC5101 does >> not >> fall into the situation mentioned in section 5.6? After all, section >> 5.6 >> is not necessary, is it? It seems deletable. >> > > Purpose of section 5.6 is to say "some kind of session management is > needed". Since the draft is problem statements, I agree that current > draft description is too detailed and should be categorized > requirement or specification. > Exactly. Regards, Benoit. --------------080409000904020501080304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Haruhiko-san, 
You mean that data retention is storage of traffic data during  
reasonable
amount of time according to government regulation?
I was not familiar with data retention using NetFlow/sFlow. Exactly,
NetFlow/sFlow/IPFIX can become the tool for data retention.
    

neither of me nor Kobayashi-san knows about data retention by netflow/ 
IPFIX. Could you add some description on the part?
Ok, I'll write some text later. 

    
- Section 5.6, last paragraph.

  "Even if one session is reset,
  the status of the other sessions is kept.  However, if Templates  
that
  reset the session of Collecting Processes would not be withdrawn,
  there is a possibility that assigned Template IDs overlap.  The
  Collector might then shut down IPFIX session, because it identifies
  the overlapping Template ID as part of an anomalous message.  In  
the
  case of resetting a session of the Collecting Process, the  
operation
  processed by IPFIX Mediator should be defined."

This is wrong IMHO. The mediation device should take care of the  
management of NEW templates. We can't rely on the template id  
received.
      
I think that it is not necessary to rewrite Template ID in case of
relaying from one Transport Session to one Transport Session.

But, exactly, assigning new template id in case of all situation is
safer for IPFIX protocol.

You mean that IPFIX Mediator implemented in relation to RFC5101 does  
not
fall into the situation mentioned in section 5.6? After all, section  
5.6
is not necessary, is it? It seems deletable.
    

Purpose of section 5.6 is to say "some kind of session management is  
needed". Since the draft is problem statements, I agree that current  
draft description is too detailed and should be categorized  
requirement or specification.
Exactly.

Regards, Benoit.
--------------080409000904020501080304-- --===============1813475292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1813475292==-- From ipfix-bounces@ietf.org Tue Mar 11 11:03:37 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4031628C1E6; Tue, 11 Mar 2008 11:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.998 X-Spam-Level: X-Spam-Status: No, score=-98.998 tagged_above=-999 required=5 tests=[AWL=1.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtROlSiZSfEc; Tue, 11 Mar 2008 11:03:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1863A6AAF; Tue, 11 Mar 2008 11:03:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D093B3A6B37 for ; Tue, 11 Mar 2008 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An3B1fF8I1es for ; Tue, 11 Mar 2008 11:03:33 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 8A0133A6974 for ; Tue, 11 Mar 2008 11:03:32 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2BI0uI7005352; Wed, 12 Mar 2008 03:00:57 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 12 Mar 2008 03:01:03 +0900 From: Kobayashi Atsushi To: Benoit Claise In-Reply-To: <47D6AD3F.3080102@cisco.com> References: <20080310154551.5663.AKOBA@nttv6.net> <47D6AD3F.3080102@cisco.com> Message-Id: <20080312023322.FA93.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Wed, 12 Mar 2008 03:00:58 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Please see in-line. On Tue, 11 Mar 2008 12:03:11 -0400 Benoit Claise wrote: > Kobayashi-san, > > > > > > > > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've > >> seen 1/100 > >> > > > > Where is it? > > I mentioned that "typically sampling packets with rates ranging from > > 1/10,000 to 1/1,000". > > > I mean that I have seen customers with 1/100. I focus on large-scale networks. I have not seen tier1 level provider with 1/100. Is it true? It must be huge Flow Records. My simple question. > > > >> - Section 3.1. You're missing an important application -> data retention. > >> > > > > You mean that data retention is storage of traffic data during reasonable > > amount of time according to government regulation? > > I was not familiar with data retention using NetFlow/sFlow. Exactly, > > NetFlow/sFlow/IPFIX can become the tool for data retention. > > > Data retention is now a law at the European level. > And obviously, NetFlow/IPFIFrom ipfix-bounces@ietf.org Tue Mar 11 11:03:37 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4031628C1E6; Tue, 11 Mar 2008 11:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.998 X-Spam-Level: X-Spam-Status: No, score=-98.998 tagged_above=-999 required=5 tests=[AWL=1.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtROlSiZSfEc; Tue, 11 Mar 2008 11:03:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1863A6AAF; Tue, 11 Mar 2008 11:03:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D093B3A6B37 for ; Tue, 11 Mar 2008 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An3B1fF8I1es for ; Tue, 11 Mar 2008 11:03:33 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 8A0133A6974 for ; Tue, 11 Mar 2008 11:03:32 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2BI0uI7005352; Wed, 12 Mar 2008 03:00:57 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 12 Mar 2008 03:01:03 +0900 From: Kobayashi Atsushi To: Benoit Claise In-Reply-To: <47D6AD3F.3080102@cisco.com> References: <20080310154551.5663.AKOBA@nttv6.net> <47D6AD3F.3080102@cisco.com> Message-Id: <20080312023322.FA93.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Wed, 12 Mar 2008 03:00:58 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Problems with Flow Collection in large-scale networks: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Benoit, Please see in-line. On Tue, 11 Mar 2008 12:03:11 -0400 Benoit Claise wrote: > Kobayashi-san, > > > > > > > > >> - Section 3.1. You mentioned sampling rate of 1/1000 to 1/1000. I've > >> seen 1/100 > >> > > > > Where is it? > > I mentioned that "typically sampling packets with rates ranging from > > 1/10,000 to 1/1,000". > > > I mean that I have seen customers with 1/100. I focus on large-scale networks. I have not seen tier1 level provider with 1/100. Is it true? It must be huge Flow Records. My simple question. > > > >> - Section 3.1. You're missing an important application -> data retention. > >> > > > > You mean that data retention is storage of traffic data during reasonable > > amount of time according to government regulation? > > I was not familiar with data retention using NetFlow/sFlow. Exactly, > > NetFlow/sFlow/IPFIX can become the tool for data retention. > > > Data retention is now a law at the European level. > And obviously, NetFlow/IPFIX is a master piece in the architecture. > > > >> - I would develop further the section 4.2 to express that there is a > >> different approach than exporting complete flow records to a mediation > >> device, which in turn does some aggregation/filtering. I mean, the > >> router have several different caches, each optimized for a specific > >> application. So each cache has its own series of flow keys. And the > >> content of each cache is sent to a specific collector. For example, a > >> collector for security, another one for capacity planning, etc... > >> > > > > I can image you mentioned. > > Each cache has its own Flow Keys. The output of each cache is send to a > > specific collector. > > > Exactly. > > > >> - Section 4.4 "In general, load balancing allows work of Collectors to > >> be divided. Classifying Flow Records based on the value of specified > >> Information Elements can prove to be very useful to achive scalability. > >> " This is not load balancing, as the title says. > >> > > > > Does it prefer "load sharing method" or "load distribution"? > > > Maybe export filtering? Maybe it is so. > > > > > > > > >> - section 5.1 "Implementing load balancing" > >> > >> "There currently is no description of a classification function in > >> IPFIX." > >> > >> This is normal as IPFIX is the export protocol. You speak about a > >> specific feature of the Exporting Process that would use RFC5101 > >> > >> "According to the current specification, Exporters send all > >> Flow Records to multiple Collectors and Collectors drop uninteresting > >> Flow Records to reduce their load." > >> > >> This is wrong. > >> > > > > Wrong? If so, I can not image the current specification regarding > > classification. > > > I mean that IPFIX, being an export protocol, doesn't impose any > constraints on the metering process and on what you export to collectors. > It doesn't impose that you export ALL flow records to collector(s), and > then do filtering. Yes. It is one solution of using feature of IPFIX. I don't mean to impose it. I will improve the description of this section. > Hence, my example in this email thread: multiple caches, each with its > own set of flow keys, exported to different collectors. Even if you add > filtering before exporting, you can still use IPFIX. Yes. Your idea using multiple caches can be applied to Metering Process in Mediator, too. > > As another case, observed packets become input to multiple Metering > > Processes, and in each Metering Process, these interesting packets are > > selected. Finally, output of each Metering Process is sent to a specific > > Collector. Is it correct? > > > >> - section 5.6 > >> > >> "If the session > >> between a Router and a Mediator fails and the IPFIX Mediator shuts > >> down the session between the Collector and the Mediator, the > >> Collector would futilely continue to try to establish the session." > >> > >> "If > >> one of these sessions between Routers and the Mediator fails and > >> IPFIX Mediator shuts down the session between a Collector and the > >> Mediator, other sessions between the Routers and the Mediator would > >> not be relayed at all." > >> > >> Not necessarily. It depends how we write the specifications. > >> > > > > You mean that removing all of section 5.6 is better? > > > no, I mean that your statements assume certain > specifications/implementations at the mediation device. OK. I understand you mean. I should not assume some specification. > > > >> - Section 5.6, last paragraph. > >> > >> "Even if one session is reset, > >> the status of the other sessions is kept. However, if Templates that > >> reset the session of Collecting Processes would not be withdrawn, > >> there is a possibility that assigned Template IDs overlap. The > >> Collector might then shut down IPFIX session, because it identifies > >> the overlapping Template ID as part of an anomalous message. In the > >> case of resetting a session of the CollecX is a master piece in the architecture. > > > >> - I would develop further the section 4.2 to express that there is a > >> different approach than exporting complete flow records to a mediation > >> device, which in turn does some aggregation/filtering. I mean, the > >> router have several different caches, each optimized for a specific > >> application. So each cache has its own series of flow keys. And the > >> content of each cache is sent to a specific collector. For example, a > >> collector for security, another one for capacity planning, etc... > >> > > > > I can image you mentioned. > > Each cache has its own Flow Keys. The output of each cache is send to a > > specific collector. > > > Exactly. > > > >> - Section 4.4 "In general, load balancing allows work of Collectors to > >> be divided. Classifying Flow Records based on the value of specified > >> Information Elements can prove to be very useful to achive scalability. > >> " This is not load balancing, as the title says. > >> > > > > Does it prefer "load sharing method" or "load distribution"? > > > Maybe export filtering? Maybe it is so. > > > > > > > > >> - section 5.1 "Implementing load balancing" > >> > >> "There currently is no description of a classification function in > >> IPFIX." > >> > >> This is normal as IPFIX is the export protocol. You speak about a > >> specific feature of the Exporting Process that would use RFC5101 > >> > >> "According to the current specification, Exporters send all > >> Flow Records to multiple Collectors and Collectors drop uninteresting > >> Flow Records to reduce their load." > >> > >> This is wrong. > >> > > > > Wrong? If so, I can not image the current specification regarding > > classification. > > > I mean that IPFIX, being an export protocol, doesn't impose any > constraints on the metering process and on what you export to collectors. > It doesn't impose that you export ALL flow records to collector(s), and > then do filtering. Yes. It is one solution of using feature of IPFIX. I don't mean to impose it. I will improve the description of this section. > Hence, my example in this email thread: multiple caches, each with its > own set of flow keys, exported to different collectors. Even if you add > filtering before exporting, you can still use IPFIX. Yes. Your idea using multiple caches can be applied to Metering Process in Mediator, too. > > As another case, observed packets become input to multiple Metering > > Processes, and in each Metering Process, these interesting packets are > > selected. Finally, output of each Metering Process is sent to a specific > > Collector. Is it correct? > > > >> - section 5.6 > >> > >> "If the session > >> between a Router and a Mediator fails and the IPFIX Mediator shuts > >> down the session between the Collector and the Mediator, the > >> Collector would futilely continue to try to establish the session." > >> > >> "If > >> one of these sessions between Routers and the Mediator fails and > >> IPFIX Mediator shuts down the session between a Collector and the > >> Mediator, other sessions between the Routers and the Mediator would > >> not be relayed at all." > >> > >> Not necessarily. It depends how we write the specifications. > >> > > > > You mean that removing all of section 5.6 is better? > > > no, I mean that your statements assume certain > specifications/implementations at the mediation device. OK. I understand you mean. I should not assume some specification. > > > >> - Section 5.6, last paragraph. > >> > >> "Even if one session is reset, > >> the status of the other sessions is kept. However, if Templates that > >> reset the session of Collecting Processes would not be withdrawn, > >> there is a possibility that assigned Template IDs overlap. The > >> Collector might then shut down IPFIX session, because it identifies > >> the overlapping Template ID as part of an anomalous message. In the > >> case of resetting a session of the Collecting Process, the operation > >> processed by IPFIX Mediator should be defined." > >> > >> This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. > >> > > > > I think that it is not necessary to rewrite Template ID in case of > > relaying from one Transport Session to one Transport Session. > > > Correct, but that's the only case. > And if you have a single Transport Session matching to another Transport > Session, I'm questioning the need for a mediation device ;-) In following case of using Masquerading Proxy , we can image it. .--------------. IPFIX | | IPFIX -----> | -anonymize-> | -------> IPFIX | | IPFIX -----> | -anonymize-> | -------> IPFIX | | IPFIX -----> | -anonymize-> | -------> | | '--------------' Regards, Atsushi KOABYASHI _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ting Process, the operation > >> processed by IPFIX Mediator should be defined." > >> > >> This is wrong IMHO. The mediation device should take care of the management of NEW templates. We can't rely on the template id received. > >> > > > > I think that it is not necessary to rewrite Template ID in case of > > relaying from one Transport Session to one Transport Session. > > > Correct, but that's the only case. > And if you have a single Transport Session matching to another Transport > Session, I'm questioning the need for a mediation device ;-) In following case of using Masquerading Proxy , we can image it. .--------------. IPFIX | | IPFIX -----> | -anonymize-> | -------> IPFIX | | IPFIX -----> | -anonymize-> | -------> IPFIX | | IPFIX -----> | -anonymize-> | -------> | | '--------------' Regards, Atsushi KOABYASHI _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Mar 11 16:03:25 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847113A6BAD; Tue, 11 Mar 2008 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKh1mX4n5FOB; Tue, 11 Mar 2008 16:03:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B967C3A6A4B; Tue, 11 Mar 2008 16:03:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6683A6810 for ; Tue, 11 Mar 2008 16:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e21-G5rX8PGC for ; Tue, 11 Mar 2008 16:03:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 01A753A6AB4 for ; Tue, 11 Mar 2008 16:03:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,482,1199660400"; d="scan'208";a="3184157" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 00:00:51 +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/8.12.11) with ESMTP id m2BN0pS1013330; Wed, 12 Mar 2008 00:00:51 +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 m2BN0pvB024384; Tue, 11 Mar 2008 23:00:51 GMT Received: from [10.61.80.252] (ams3-vpn-dhcp4349.cisco.com [10.61.80.252]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2BN0or18623; Tue, 11 Mar 2008 23:00:50 GMT Message-ID: <47D70F2C.7010807@cisco.com> Date: Tue, 11 Mar 2008 23:01:00 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Gerhard Muenz , Benoit Claise DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15890; t=1205276451; x=1206140451; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-muenz-ipfix-configuration-04. txt |Sender:=20; bh=fU5RlIbby+Virtl8m23oQo68ipYEcNuM8ZAJo/39kG0=; b=rn3uZQz48OWAVGOHyTrEv1kXCAE7XeCM3R1qIwVzI9Y7rnzq5kmu9nIXpP QVV3X9RcVB1J5whp5tRDFCeBEHe00zK0gV2Fo6VfZ65Zv6vzfygYI1ypdifE hqY+m7DV4g; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, From ipfix-bounces@ietf.org Tue Mar 11 16:03:25 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847113A6BAD; Tue, 11 Mar 2008 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKh1mX4n5FOB; Tue, 11 Mar 2008 16:03:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B967C3A6A4B; Tue, 11 Mar 2008 16:03:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6683A6810 for ; Tue, 11 Mar 2008 16:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e21-G5rX8PGC for ; Tue, 11 Mar 2008 16:03:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 01A753A6AB4 for ; Tue, 11 Mar 2008 16:03:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,482,1199660400"; d="scan'208";a="3184157" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 00:00:51 +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/8.12.11) with ESMTP id m2BN0pS1013330; Wed, 12 Mar 2008 00:00:51 +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 m2BN0pvB024384; Tue, 11 Mar 2008 23:00:51 GMT Received: from [10.61.80.252] (ams3-vpn-dhcp4349.cisco.com [10.61.80.252]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2BN0or18623; Tue, 11 Mar 2008 23:00:50 GMT Message-ID: <47D70F2C.7010807@cisco.com> Date: Tue, 11 Mar 2008 23:01:00 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Gerhard Muenz , Benoit Claise DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15890; t=1205276451; x=1206140451; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-muenz-ipfix-configuration-04. txt |Sender:=20; bh=fU5RlIbby+Virtl8m23oQo68ipYEcNuM8ZAJo/39kG0=; b=rn3uZQz48OWAVGOHyTrEv1kXCAE7XeCM3R1qIwVzI9Y7rnzq5kmu9nIXpP QVV3X9RcVB1J5whp5tRDFCeBEHe00zK0gV2Fo6VfZ65Zv6vzfygYI1ypdifE hqY+m7DV4g; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Benoit, Here with a review of draft-muenz-ipfix-configuration-04.txt Overall, it's a very strong draft which I'd like to see adopted as a WG item. Cheers, P. 2. Introduction, 2nd paragraph: > The purpose of this document is the specification of a device- > independent configuration data model that covers the commonly > available configuration parameters of IPFIX Metering Processes, ^^^^^ > Exporting Processes, and Collecting Processes. 2.1. IPFIX Documents Overview > The IPFIX protocol [RFC5101] provides network administrators with > access to IP flow information. The architecture for the export of > measured IP flow information out of an IPFIX exporting process to a > collecting process is defined in [I-D.ietf-ipfix-architecture], per > the requirements defined in [RFC3917], which specifies how ^^^^^ > IPFIX data records and templates are carried via a number of > transport protocols from IPFIX exporting processes to IPFIX > collecting process. IPFIX has a formal description of IPFIX > information elements, their name, type and additional semantic > information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] > specifies the IPFIX Management Information Base. Finally, > ^ > [I-D.ietf-ipfix-as] describes what type of applications can use the > IPFIX protocol and how they can use the information provided. It > furthermore shows how the IPFIX framework relates to other > architectures and frameworks. 4. Structure of the Configuration Data Model > The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies > the role and function of IPFIX Metering Processes, Exporting ^^^^^ > Processes, and Collecting Processes. In [I-D.ietf-psamp-framework], the > corresponding information is specified for the PSAMP architecture. > IPFIX and PSAMP compliant monitoring device implementations usually > maintain the separation of Metering Processes, Exporting Processes, > and Collecting Processes (although they do not necessarily implement > all of them). Furthermore, they provide various configuration > possibilities; some of them are specified as mandatory by the IPFIX > protocol [RFC5101]. The configuration data model enables the setting > of commonly available configuration parameters for IPFIX Metering ^^^^^ > Processes, Exporting Processes, and Collecting Processes. > In > addition, it allows specifying the composition of Metering Processes, > Exporting Processes, and Collecting Processes within a monitoring > device configuration. This implies that an Exporting Process and Collecting Process will exist within the same device? Instead, consider: In addition, it allows specifying the composition of Metering Processes and Exporting Processes within a monitoring device, and the associated Collecting Processes. > In the following, we use Unified Modeling Language (UML) class > diagrams Could you cite a reference for this please? > Figure 1 below shows the main classes in the configuration data model. ^^^^^ ^^-- or "of"? > o The ObservationPoint class specifies an Observation Point (e.g. > interface) of the monitoring device which is used for traffic > monitoring. Furthermore, it configures Metering Processes that > process the observed packets. - it might configure which MP's process the observed packets, but should not configure those MPs themselves. - consider "specifies an *IPFIX* Observation Point". > o The MeteringProcess class represents a Metering Process. A - consider "an IPFIX Metering Process". > Metering Process requires a record cache which is represented by - depends on the definition of "record". Most likely the cache contents will be related to the data records which appear from the exporting process, but we shouldn't assume or imply that the MP cache contains exactly those records. > an instance of the Cache class. In order to enable the usage of > the same record cache in multiple Metering Processes, the - please first explain why multiple MP would want to use a single cache? And conversely, whether a single MP may use multiple caches, and if so, briefly mention why it may wish to do so? > MeteringProcess class contains only a reference to an instance of > the Cache class. Note that the usage of the same cache implies > that the Template defining the record format is identical for the > corresponding Metering Processes. Additionally, the Agreed, the cache definitions will be the same. However, I don't like using "Template" to describe this, since it implies the Exporting Process Template, which may be quite different even for the same cache. For clarity, I'd much prefer the cache "template" to have its own name (eg, cache definition, cache layout) even if it's essentially a template. > o The SelectionProcess class contains the configuration parameters > of a Selection Process, which is a Primitive Selector (i.e., > sampler or filter). An instance of the SelectionProcess class can > be referred to from multiple Metering Processes, which allows the ^^ > o The Cache class contains configuration parameters of a cache which > stores the Flow Records in the monitoring device. Configuration ^^^^^^ - because RFC 5101 says "The Metering Process generates Flow Records." > parameters of the Cache class specify the record format > (Template), expiration parameters, and cache size. In addition, Again, even though the cache contents may conveniently expressed as a template, IPFIX Templates belong to the Exporting Process, and one cache may be exported using many different IPFIX Templates. So for clarity I'd prefer to express the cache record format using a different name. > references to one or multiple Exporting Processes can be included. > An instance of the Cache class can be referred from multiple > Metering Processes, enabling the shared usage of the same record > cache in different Metering Processes. As the Template is defined As above, I'd like to see a small note indicating why this might be useful - not as a justification, but simply to clarify the intention to the reader. > in the Cache class, using the same record cache implies that the > record format is identical. Also, the same Exporting Processes > will be used, as these are linked to the record cache. If the Template is defined in the Cache, aren't you constraining the Exporting Process to always export the same cache in the same way? So what if two EPs want to export the same fields in different orders, or if we want to export a sub-set of fields from the cache? Now different export templates are required that don't match the cache template - which is why I want to be clear that these "templates" are distinct from one another. > o The ExportingProcess class contains configuration parameters of an > Exporting Process. It defines the export parameters and > destinations. An instance of the ExportingProcess class can be > referred from multiple instances of the Cache class. Presumably multiple EPs can be referenced from a single cache, as Figure 1 seems to show? > As can be seen in Figure 1, the MeteringProcess class defines > references to instances of the SelectionProcess class and the Cache > class. It acts as an envelope element specifying a series of > Selection Processes, forming a Selection Sequence, and a record > cache. > The order in which the user specifies Selection Processes in > the XML document corresponds to the order in which they are applied. > Hence, by using UML associations instead of aggregation > relationships, the same Selection Processes and record caches can be > deployed in different Metering Processes. An example is given in > Section 7.1. > The MeteringProcess class itself is not instantiated, > but specified as part of the ObservationPoint class. Using the same > Metering Process with different Observation Points is achieved by > referring to the same instances of the SelectionProcess class and the > Cache class. Considering Selection Processes and Cache Parameters as > instances (and not the complete Metering Process) corresponds to the > common practice to implement Selection Processes and record caches as > independent modules. This is a lot of text. Consider breaking it up as shown. 5.1. ObservationPoint Class > The ObservationPoint class identifies an Observation Point of the > monitoring device, which is either an interface or a linecard. For "post" elements, the OP may be considered to be a process inside the box. RFC 5101 says: An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. - so some grouping of interfaces / linecards may be desirable too. Also, recall that IPFIX allows an OP to be composed of set of OPs: Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. 5.2. MeteringProcess Class > The MeteringProcess class represents a Metering Process. It refers > to one instance of the Cache class that specifies a record cache in > the monitoring device. In addition, the MeteringProcess class may > refer to one or multiple instances of the SelectionProcess class > which specify sampling and filtering methods applied to the packets > before entering the record cache. The order of the Selection > Processes references in the XML document corresponds to the sequence > in which they are applied. If no SelectionProcess is specified, all > observed packets are selected. Is it possible to disable a MP? ie, to have MPs configured but inactive? This may be useful during configuration - so the config can be loaded, then activated. It may also be useful to have configs standing by - eg day/night monitoring, or weekday/weekend. Or normal / attack scenario. The same is true for EP too - it may be desirable to have an EP standing bye, configured and ready to leap into action at a moment's notice :-) 5.3. SelectionProcess Class The configuration parameters seems to be related to the PSAMP selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled registry. Do you envisage the configuration model encompassing additions to the selectorAlgorithm? 5.4. Cache Class > o cacheSize: maximum number of records in the cache. This could be mistaken for the number of bytes the cache consumes. Consider eg "maxRecords" ? > o activeTimeout: timeout after which an active Flow is timed out > anyway even if there is still a continuous flow of packets. > o idleTimeout: A Flow is considered to be timed out if no packets > belonging to the Flow have been observed for the amount of time > specified by this parameter. In what units are these timeouts expressed? What ranges do they have? 5.4.1. Template Class Is it likely (or even allowed) that a cache (and thus, the template) will contain enterprise specific IEs from different enterprises? If not, then the field definition need not contain the enterpriseNumber. Rather, I expect this would be a property of the Monitoring Process (since the MP may be connected to a different vendor's EP). Presumably the ieID would suffice to indicate that it's an enterprise-specific ID by having its top bit set? > o templateId: This is an optional parameter which allows specifying > a Template ID value for the Template. As specified in the IPFIX > protocol [RFC5101], the Template ID must be locally unique per > Observation Domain and Transport Session, Oh dear, no! This concerns the Exporting Process, which is nothing to do with the Monitoring Process, which is what owns the cache. How do you propose to communicate the IDs between the processes? > o isFlowKey: If present, this field is a Flow Key. It may be more convenient to have a boolean - so, if present and set, then the field is a key field. > The order of the fields in the XML document corresponds to the order > in the Template. Are implementations free to store the fields in whatever order they like? eg, put all the key fields adjacent to one another? Or according to draft-irino-ipfix-ie-order ? 5.5.2. Export Parameters Classes > o sourceIpAddress: In the case of UdpExport, this optional parameter > may appear once to set the source IP address. If this parameter > is omitted, the address assigned to the outgoing interface is > used. If the exporring device is a router then it can selects the output interface itself, according to its own routing table. But what if it's not a router? How would it determine the correct outgoing interface? > In the case of SctpExport, this optional parameter may appear > multiple times to specify the list of eligible local IP addresses > of the SCTP association [RFC4960]. If omitted, all locally > assigned IP addresses are used by the SCTP endpoint. Really? Even if those addresses are assigned to interfaces in different networks? :-o > o uri: file name and location encoded as URI if the measurement data > is exported to a file. So the file can be local or even remote? 5.5.3. Option Class The list is difficult to read. A little whitespace would improve it greatly :-) > The Option Template can be specified manually, using the > OptionTemplate class. Consider adding this as an "or, ..." at the bottom of the list. > The timeout parameter specifies the reporting interval. Consider also having a packet interval - because it may be more appropriate to export the option (and templates, BTW) more frequently in proportion to the amount of data that's exported. 5.5.4. OptionTemplate Class Again, the same questions about enterpriseNumber. > If the parameter isScope is present, the field is a scope field. Same point about isFlowKey: a boolean may be more useful. 5.6. CollectingProcess Class and Receiver Class > o ipAddress, transportPort: IP address and port number of the > receiving port. If ipAddress is omitted, the Collecting Process > receives data sent to any local IP address. If there are multiple collecting processes running in the same server, would/should they all receive data from the same port(s)? (ie, data duplication). 6. YANG Module of the IPFIX/PSAMP Configuration Data Model I'm not familiar with YANG, so I didn't review this. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix Benoit, Here with a review of draft-muenz-ipfix-configuration-04.txt Overall, it's a very strong draft which I'd like to see adopted as a WG item. Cheers, P. 2. Introduction, 2nd paragraph: > The purpose of this document is the specification of a device- > independent configuration data model that covers the commonly > available configuration parameters of IPFIX Metering Processes, ^^^^^ > Exporting Processes, and Collecting Processes. 2.1. IPFIX Documents Overview > The IPFIX protocol [RFC5101] provides network administrators with > access to IP flow information. The architecture for the export of > measured IP flow information out of an IPFIX exporting process to a > collecting process is defined in [I-D.ietf-ipfix-architecture], per > the requirements defined in [RFC3917], which specifies how ^^^^^ > IPFIX data records and templates are carried via a number of > transport protocols from IPFIX exporting processes to IPFIX > collecting process. IPFIX has a formal description of IPFIX > information elements, their name, type and additional semantic > information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] > specifies the IPFIX Management Information Base. Finally, > ^ > [I-D.ietf-ipfix-as] describes what type of applications can use the > IPFIX protocol and how they can use the information provided. It > furthermore shows how the IPFIX framework relates to other > architectures and frameworks. 4. Structure of the Configuration Data Model > The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies > the role and function of IPFIX Metering Processes, Exporting ^^^^^ > Processes, and Collecting Processes. In [I-D.ietf-psamp-framework], the > corresponding information is specified for the PSAMP architecture. > IPFIX and PSAMP compliant monitoring device implementations usually > maintain the separation of Metering Processes, Exporting Processes, > and Collecting Processes (although they do not necessarily implement > all of them). Furthermore, they provide various configuration > possibilities; some of them are specified as mandatory by the IPFIX > protocol [RFC5101]. The configuration data model enables the setting > of commonly available configuration parameters for IPFIX Metering ^^^^^ > Processes, Exporting Processes, and Collecting Processes. > In > addition, it allows specifying the composition of Metering Processes, > Exporting Processes, and Collecting Processes within a monitoring > device configuration. This implies that an Exporting Process and Collecting Process will exist within the same device? Instead, consider: In addition, it allows specifying the composition of Metering Processes and Exporting Processes within a monitoring device, and the associated Collecting Processes. > In the following, we use Unified Modeling Language (UML) class > diagrams Could you cite a reference for this please? > Figure 1 below shows the main classes in the configuration data model. ^^^^^ ^^-- or "of"? > o The ObservationPoint class specifies an Observation Point (e.g. > interface) of the monitoring device which is used for traffic > monitoring. Furthermore, it configures Metering Processes that > process the observed packets. - it might configure which MP's process the observed packets, but should not configure those MPs themselves. - consider "specifies an *IPFIX* Observation Point". > o The MeteringProcess class represents a Metering Process. A - consider "an IPFIX Metering Process". > Metering Process requires a record cache which is represented by - depends on the definition of "record". Most likely the cache contents will be related to the data records which appear from the exporting process, but we shouldn't assume or imply that the MP cache contains exactly those records. > an instance of the Cache class. In order to enable the usage of > the same record cache in multiple Metering Processes, the - please first explain why multiple MP would want to use a single cache? And conversely, whether a single MP may use multiple caches, and if so, briefly mention why it may wish to do so? > MeteringProcess class contains only a reference to an instance of > the Cache class. Note that the usage of the same cache implies > that the Template defining the record format is identical for the > corresponding Metering Processes. Additionally, the Agreed, the cache definitions will be the same. However, I don't like using "Template" to describe this, since it implies the Exporting Process Template, which may be quite different even for the same cache. For clarity, I'd much prefer the cache "template" to have its own name (eg, cache definition, cache layout) even if it's essentially a template. > o The SelectionProcess class contains the configuration parameters > of a Selection Process, which is a Primitive Selector (i.e., > sampler or filter). An instance of the SelectionProcess class can > be referred to from multiple Metering Processes, which allows the ^^ > o The Cache class contains configuration parameters of a cache which > stores the Flow Records in the monitoring device. Configuration ^^^^^^ - because RFC 5101 says "The Metering Process generates Flow Records." > parameters of the Cache class specify the record format > (Template), expiration parameters, and cache size. In addition, Again, even though the cache contents may conveniently expressed as a template, IPFIX Templates belong to the Exporting Process, and one cache may be exported using many different IPFIX Templates. So for clarity I'd prefer to express the cache record format using a different name. > references to one or multiple Exporting Processes can be included. > An instance of the Cache class can be referred from multiple > Metering Processes, enabling the shared usage of the same record > cache in different Metering Processes. As the Template is defined As above, I'd like to see a small note indicating why this might be useful - not as a justification, but simply to clarify the intention to the reader. > in the Cache class, using the same record cache implies that the > record format is identical. Also, the same Exporting Processes > will be used, as these are linked to the record cache. If the Template is defined in the Cache, aren't you constraining the Exporting Process to always export the same cache in the same way? So what if two EPs want to export the same fields in different orders, or if we want to export a sub-set of fields from the cache? Now different export templates are required that don't match the cache template - which is why I want to be clear that these "templates" are distinct from one another. > o The ExportingProcess class contains configuration parameters of an > Exporting Process. It defines the export parameters and > destinations. An instance of the ExportingProcess class can be > referred from multiple instances of the Cache class. Presumably multiple EPs can be referenced from a single cache, as Figure 1 seems to show? > As can be seen in Figure 1, the MeteringProcess class defines > references to instances of the SelectionProcess class and the Cache > class. It acts as an envelope element specifying a series of > Selection Processes, forming a Selection Sequence, and a record > cache. > The order in which the user specifies Selection Processes in > the XML document corresponds to the order in which they are applied. > Hence, by using UML associations instead of aggregation > relationships, the same Selection Processes and record caches can be > deployed in different Metering Processes. An example is given in > Section 7.1. > The MeteringProcess class itself is not instantiated, > but specified as part of the ObservationPoint class. Using the same > Metering Process with different Observation Points is achieved by > referring to the same instances of the SelectionProcess class and the > Cache class. Considering Selection Processes and Cache Parameters as > instances (and not the complete Metering Process) corresponds to the > common practice to implement Selection Processes and record caches as > independent modules. This is a lot of text. Consider breaking it up as shown. 5.1. ObservationPoint Class > The ObservationPoint class identifies an Observation Point of the > monitoring device, which is either an interface or a linecard. For "post" elements, the OP may be considered to be a process inside the box. RFC 5101 says: An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. - so some grouping of interfaces / linecards may be desirable too. Also, recall that IPFIX allows an OP to be composed of set of OPs: Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. 5.2. MeteringProcess Class > The MeteringProcess class represents a Metering Process. It refers > to one instance of the Cache class that specifies a record cache in > the monitoring device. In addition, the MeteringProcess class may > refer to one or multiple instances of the SelectionProcess class > which specify sampling and filtering methods applied to the packets > before entering the record cache. The order of the Selection > Processes references in the XML document corresponds to the sequence > in which they are applied. If no SelectionProcess is specified, all > observed packets are selected. Is it possible to disable a MP? ie, to have MPs configured but inactive? This may be useful during configuration - so the config can be loaded, then activated. It may also be useful to have configs standing by - eg day/night monitoring, or weekday/weekend. Or normal / attack scenario. The same is true for EP too - it may be desirable to have an EP standing bye, configured and ready to leap into action at a moment's notice :-) 5.3. SelectionProcess Class The configuration parameters seems to be related to the PSAMP selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled registry. Do you envisage the configuration model encompassing additions to the selectorAlgorithm? 5.4. Cache Class > o cacheSize: maximum number of records in the cache. This could be mistaken for the number of bytes the cache consumes. Consider eg "maxRecords" ? > o activeTimeout: timeout after which an active Flow is timed out > anyway even if there is still a continuous flow of packets. > o idleTimeout: A Flow is considered to be timed out if no packets > belonging to the Flow have been observed for the amount of time > specified by this parameter. In what units are these timeouts expressed? What ranges do they have? 5.4.1. Template Class Is it likely (or even allowed) that a cache (and thus, the template) will contain enterprise specific IEs from different enterprises? If not, then the field definition need not contain the enterpriseNumber. Rather, I expect this would be a property of the Monitoring Process (since the MP may be connected to a different vendor's EP). Presumably the ieID would suffice to indicate that it's an enterprise-specific ID by having its top bit set? > o templateId: This is an optional parameter which allows specifying > a Template ID value for the Template. As specified in the IPFIX > protocol [RFC5101], the Template ID must be locally unique per > Observation Domain and Transport Session, Oh dear, no! This concerns the Exporting Process, which is nothing to do with the Monitoring Process, which is what owns the cache. How do you propose to communicate the IDs between the processes? > o isFlowKey: If present, this field is a Flow Key. It may be more convenient to have a boolean - so, if present and set, then the field is a key field. > The order of the fields in the XML document corresponds to the order > in the Template. Are implementations free to store the fields in whatever order they like? eg, put all the key fields adjacent to one another? Or according to draft-irino-ipfix-ie-order ? 5.5.2. Export Parameters Classes > o sourceIpAddress: In the case of UdpExport, this optional parameter > may appear once to set the source IP address. If this parameter > is omitted, the address assigned to the outgoing interface is > used. If the exporring device is a router then it can selects the output interface itself, according to its own routing table. But what if it's not a router? How would it determine the correct outgoing interface? > In the case of SctpExport, this optional parameter may appear > multiple times to specify the list of eligible local IP addresses > of the SCTP association [RFC4960]. If omitted, all locally > assigned IP addresses are used by the SCTP endpoint. Really? Even if those addresses are assigned to interfaces in different networks? :-o > o uri: file name and location encoded as URI if the measurement data > is exported to a file. So the file can be local or even remote? 5.5.3. Option Class The list is difficult to read. A little whitespace would improve it greatly :-) > The Option Template can be specified manually, using the > OptionTemplate class. Consider adding this as an "or, ..." at the bottom of the list. > The timeout parameter specifies the reporting interval. Consider also having a packet interval - because it may be more appropriate to export the option (and templates, BTW) more frequently in proportion to the amount of data that's exported. 5.5.4. OptionTemplate Class Again, the same questions about enterpriseNumber. > If the parameter isScope is present, the field is a scope field. Same point about isFlowKey: a boolean may be more useful. 5.6. CollectingProcess Class and Receiver Class > o ipAddress, transportPort: IP address and port number of the > receiving port. If ipAddress is omitted, the Collecting Process > receives data sent to any local IP address. If there are multiple collecting processes running in the same server, would/should they all receive data from the same port(s)? (ie, data duplication). 6. YANG Module of the IPFIX/PSAMP Configuration Data Model I'm not familiar with YANG, so I didn't review this. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Mar 12 06:00:04 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250883A6E3D; Wed, 12 Mar 2008 06:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpMUVBPV-8j0; Wed, 12 Mar 2008 05:59:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A764528C6DC; Wed, 12 Mar 2008 05:59:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0BC28C71A for ; Wed, 12 Mar 2008 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 675tiQvPPhb5 for ; Wed, 12 Mar 2008 05:59:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 79A1728C715 for ; Wed, 12 Mar 2008 05:59:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,488,1199660400"; d="asc'?scan'208";a="3250038" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 13:57:09 +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/8.12.11) with ESMTP id m2CCv9Vl014522; Wed, 12 Mar 2008 13:57:09 +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 m2CCv9vB029853; Wed, 12 Mar 2008 12:57:09 GMT Received: from [144.254.153.48] (dhcp-144-254-153-48.cisco.com [144.254.153.48]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2CCv9j03896; Wed, 12 Mar 2008 12:57:09 GMT From: Andrew Johnson To: Benoit Claise In-Reply-To: <47D5F8D7.2070103@cisco.com> References: <47D5F8D7.2070103@cisco.com> Date: Wed, 12 Mar 2008 12:57:07 +0000 Message-Id: <1205326627.9226.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.1mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1709; t=1205326629; x=1206190629; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=3N8WzLojWR5cXoj8btoVBQ7SzYWgSNzusD6QlgOha/g=; b=Lm4h9QF2AfAEWAnTEpQeeCgAkPWV8mwe/JXkgvANJxc06Kpr345ePdtcTm +0kPkB5ksLoRWCqTM7AyGOFumXW112Dda31HHKSt+Ll5toEIVdxhuVsKRb6X 3z7la1m9gQ; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1767407686==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============1767407686== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GhAhQitwo6agsiYaKIGN" --=-GhAhQitwo6agsiYaKIGN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Benoit et al. On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: [SNIP] > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, why > not have a "scope" IE with some values in there. Like in RFC3954: > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template A series of IEs that are only useful for defining the scope may seem undesirable but I think the principle could be very useful. We already have Template ID and Line Card IDs that can be used more explicitly for scoping options. Perhaps defining streamID, messageID and sessionID would be more palatable, with the special case of using them with a length of zero means *this* message or *this* session. The messageID could reference the message sequence number sent for each message. The sessionID is trickier, but it is possible to have the Exporting Process choose the ID and communicate it to the Collector. Cheers Andrew --=-GhAhQitwo6agsiYaKIGN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBH19MdxaGr6Yt1y6ARAh5mAJ0dsXv7+Q2UV+ehgYDyGUeLgY2OrACfWBkS rYFb6WV70s1YszTsEeWfCA8= =jZ1X -----END PGP SIGNATURE----- --=-GhAhQitwo6agsiYaKIGN-- --===============1767407686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1767407686==-- From ipfix-bounces@ietf.org Wed Mar 12 06:00:04 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250883A6E3D; Wed, 12 Mar 2008 06:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpMUVBPV-8j0; Wed, 12 Mar 2008 05:59:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A764528C6DC; Wed, 12 Mar 2008 05:59:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0BC28C71A for ; Wed, 12 Mar 2008 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 675tiQvPPhb5 for ; Wed, 12 Mar 2008 05:59:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 79A1728C715 for ; Wed, 12 Mar 2008 05:59:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,488,1199660400"; d="asc'?scan'208";a="3250038" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 13:57:09 +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/8.12.11) with ESMTP id m2CCv9Vl014522; Wed, 12 Mar 2008 13:57:09 +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 m2CCv9vB029853; Wed, 12 Mar 2008 12:57:09 GMT Received: from [144.254.153.48] (dhcp-144-254-153-48.cisco.com [144.254.153.48]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2CCv9j03896; Wed, 12 Mar 2008 12:57:09 GMT From: Andrew Johnson To: Benoit Claise In-Reply-To: <47D5F8D7.2070103@cisco.com> References: <47D5F8D7.2070103@cisco.com> Date: Wed, 12 Mar 2008 12:57:07 +0000 Message-Id: <1205326627.9226.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.1mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1709; t=1205326629; x=1206190629; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=3N8WzLojWR5cXoj8btoVBQ7SzYWgSNzusD6QlgOha/g=; b=Lm4h9QF2AfAEWAnTEpQeeCgAkPWV8mwe/JXkgvANJxc06Kpr345ePdtcTm +0kPkB5ksLoRWCqTM7AyGOFumXW112Dda31HHKSt+Ll5toEIVdxhuVsKRb6X 3z7la1m9gQ; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1767407686==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============1767407686== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GhAhQitwo6agsiYaKIGN" --=-GhAhQitwo6agsiYaKIGN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Benoit et al. On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: [SNIP] > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, why > not have a "scope" IE with some values in there. Like in RFC3954: > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template A series of IEs that are only useful for defining the scope may seem undesirable but I think the principle could be very useful. We already have Template ID and Line Card IDs that can be used more explicitly for scoping options. Perhaps defining streamID, messageID and sessionID would be more palatable, with the special case of using them with a length of zero means *this* message or *this* session. The messageID could reference the message sequence number sent for each message. The sessionID is trickier, but it is possible to have the Exporting Process choose the ID and communicate it to the Collector. Cheers Andrew --=-GhAhQitwo6agsiYaKIGN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBH19MdxaGr6Yt1y6ARAh5mAJ0dsXv7+Q2UV+ehgYDyGUeLgY2OrACfWBkS rYFb6WV70s1YszTsEeWfCA8= =jZ1X -----END PGP SIGNATURE----- --=-GhAhQitwo6agsiYaKIGN-- --===============1767407686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1767407686==-- From ipfix-bounces@ietf.org Wed Mar 12 08:49:22 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3C628C518; Wed, 12 Mar 2008 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Ptd1WA2MyP; Wed, 12 Mar 2008 08:49:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7489E28C738; Wed, 12 Mar 2008 08:49:17 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2743A3A6DE6 for ; Wed, 12 Mar 2008 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxIUnD4fhagD for ; Wed, 12 Mar 2008 08:49:10 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id F3C5E3A6E82 for ; Wed, 12 Mar 2008 08:48:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 77E2C9C52F for ; Thu, 13 Mar 2008 04:45:42 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lKvv4zU-Ju5 for ; Thu, 13 Mar 2008 04:45:42 +1300 (NZDT) Received: from dhcp-12a0.ietf71.ietf.org (dhcp-12a0.ietf71.ietf.org [130.129.18.160]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9E8BD9C527 for ; Thu, 13 Mar 2008 04:45:41 +1300 (NZDT) From: Nevil Brownlee To: ipfix@ietf.org Organization: U Auckland Date: Thu, 13 Mar 2008 04:45:37 +1300 Message-Id: <1205336737.7556.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Subject: [IPFIX] DRAFT minutes for IPFIX meeting at IETF-71 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Here are my draft minutes of our meeting yesterday. Please send me any corrections or suggested imporovements. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand Minutes of the IPFIX WG meeting, 11 Mar 09, at IETF-71, Philadelphia Chair: Nevil Brownlee Nevil reviewed our current drafts: RFCs 5101, 5102 and 5103 are published, the 'implementation-guidelines' draft is in RFC Editor 48 hours state, and the 'ipfix-testing' draft is waiting for author responses to the Gen Area review. The psamp 'framework,From ipfix-bounces@ietf.org Wed Mar 12 08:49:22 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3C628C518; Wed, 12 Mar 2008 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Ptd1WA2MyP; Wed, 12 Mar 2008 08:49:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7489E28C738; Wed, 12 Mar 2008 08:49:17 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2743A3A6DE6 for ; Wed, 12 Mar 2008 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxIUnD4fhagD for ; Wed, 12 Mar 2008 08:49:10 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id F3C5E3A6E82 for ; Wed, 12 Mar 2008 08:48:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 77E2C9C52F for ; Thu, 13 Mar 2008 04:45:42 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lKvv4zU-Ju5 for ; Thu, 13 Mar 2008 04:45:42 +1300 (NZDT) Received: from dhcp-12a0.ietf71.ietf.org (dhcp-12a0.ietf71.ietf.org [130.129.18.160]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9E8BD9C527 for ; Thu, 13 Mar 2008 04:45:41 +1300 (NZDT) From: Nevil Brownlee To: ipfix@ietf.org Organization: U Auckland Date: Thu, 13 Mar 2008 04:45:37 +1300 Message-Id: <1205336737.7556.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Subject: [IPFIX] DRAFT minutes for IPFIX meeting at IETF-71 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Here are my draft minutes of our meeting yesterday. Please send me any corrections or suggested imporovements. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand Minutes of the IPFIX WG meeting, 11 Mar 09, at IETF-71, Philadelphia Chair: Nevil Brownlee Nevil reviewed our current drafts: RFCs 5101, 5102 and 5103 are published, the 'implementation-guidelines' draft is in RFC Editor 48 hours state, and the 'ipfix-testing' draft is waiting for author responses to the Gen Area review. The psamp 'framework,' 'sampling technology' and 'protocol' drafts have been submitted to IESG, and 'information-model' is ready to submit. Thomas Dietz presented the 'ipfix MIB;' this is now ready for WG Last Call. It is the last work item from our old charter. Elise Boschi presented the 'Exporting Type Information' draft. Some issues were raised, they will be resolved on the list. The draft will then be ready for WGLC. Brian Trammell presented the 'ipfix-file' draft. It has a few remaining issues; work continues to resolve these before the Dublin IETF meeting. Benoit Claise presented the 'configuration-model' draft on behalf of Gerhard Muenz; the structure of the model is specified as a YANG module. Work on this is continuing, perhaps it will use the YANG language (discussed in the canmod BOF). This draft was accepted as a wg draft, with Paul Aitken, Christophe Sommer and Benoit Claise as reviewers. Benoit presented the 'per-stream-sctp-exporting' draft. This was accepted as a wg draft, with Elisa Boschi, Brian Trammell and Kobayashi Atsushi as reviewers. Kobayashi Atsushi presented draft-kobayashi-ipfix-large-ps-01.txt. This was accepted as a wg draft, it will become the 'ipfix mediators problem statement' draft. The next agenda item was the 'mediators framework.' Four people presented material for this: Kobayashi Atsushi, Emile Stephan, Falko Dressler and Elisa Boschi. There was extensive discussion, particularly about the form of the eventual framework draft; it needs to be similar to an 'architecture' draft, explaining how a (network of) mediators can be put together. Nevil announced that the wg will hold an editing session for authors/contributors to the framework documents on Thursday morning in room 414. Dan Romascanu commented that the framework will be an important step towards developing a mediators architecture, and encouraged people to "watch closely, contribute to the framework discussion, but also to start work on their individual 'mediator' projects." Paul Aitken has submitted a new individual draft, 'new information elements;' Benoit presented this on his behalf. The procedure for obtaining element numbers of new IEs was discussed; Dan says that one should simply request them from IANA. Benoit and Nevil agreed to discuss this with IANA, Nevil will report back to the list. Hitoshi Irino presented the latest version of his 'order of ipfix information elements' draft. He would like ipfix implementers to test his ideas on their implementations. Nevil will revise the wg's milestones and post them to the list. ----------------------------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ' 'sampling technology' and 'protocol' drafts have been submitted to IESG, and 'information-model' is ready to submit. Thomas Dietz presented the 'ipfix MIB;' this is now ready for WG Last Call. It is the last work item from our old charter. Elise Boschi presented the 'Exporting Type Information' draft. Some issues were raised, they will be resolved on the list. The draft will then be ready for WGLC. Brian Trammell presented the 'ipfix-file' draft. It has a few remaining issues; work continues to resolve these before the Dublin IETF meeting. Benoit Claise presented the 'configuration-model' draft on behalf of Gerhard Muenz; the structure of the model is specified as a YANG module. Work on this is continuing, perhaps it will use the YANG language (discussed in the canmod BOF). This draft was accepted as a wg draft, with Paul Aitken, Christophe Sommer and Benoit Claise as reviewers. Benoit presented the 'per-stream-sctp-exporting' draft. This was accepted as a wg draft, with Elisa Boschi, Brian Trammell and Kobayashi Atsushi as reviewers. Kobayashi Atsushi presented draft-kobayashi-ipfix-large-ps-01.txt. This was accepted as a wg draft, it will become the 'ipfix mediators problem statement' draft. The next agenda item was the 'mediators framework.' Four people presented material for this: Kobayashi Atsushi, Emile Stephan, Falko Dressler and Elisa Boschi. There was extensive discussion, particularly about the form of the eventual framework draft; it needs to be similar to an 'architecture' draft, explaining how a (network of) mediators can be put together. Nevil announced that the wg will hold an editing session for authors/contributors to the framework documents on Thursday morning in room 414. Dan Romascanu commented that the framework will be an important step towards developing a mediators architecture, and encouraged people to "watch closely, contribute to the framework discussion, but also to start work on their individual 'mediator' projects." Paul Aitken has submitted a new individual draft, 'new information elements;' Benoit presented this on his behalf. The procedure for obtaining element numbers of new IEs was discussed; Dan says that one should simply request them from IANA. Benoit and Nevil agreed to discuss this with IANA, Nevil will report back to the list. Hitoshi Irino presented the latest version of his 'order of ipfix information elements' draft. He would like ipfix implementers to test his ideas on their implementations. Nevil will revise the wg's milestones and post them to the list. ----------------------------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Mar 12 09:03:54 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341073A6E9F; Wed, 12 Mar 2008 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qTD80xL7jW2; Wed, 12 Mar 2008 09:03:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D4F3A6EC4; Wed, 12 Mar 2008 09:03:49 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC34128C1EC for ; Wed, 12 Mar 2008 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoPSiB+a5aYu for ; Wed, 12 Mar 2008 09:03:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 75D3728C737 for ; Wed, 12 Mar 2008 09:03:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,489,1199660400"; d="scan'208";a="3279704" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 17:00:40 +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/8.12.11) with ESMTP id m2CG0e78026646; Wed, 12 Mar 2008 17:00:40 +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 m2CG0ZCh021670; Wed, 12 Mar 2008 16:00:35 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2CG0Yj21235; Wed, 12 Mar 2008 16:00:34 GMT Message-ID: <47D7FE30.3080808@cisco.com> Date: Wed, 12 Mar 2008 16:00:48 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Thomas Dietz , kobayashi atsushi , Benoit Claise DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6437; t=1205337640; x=1206201640; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-ietf-ipfix-mib-03 |Sender:=20; bh=6g/f0nxFJrmeE5hrUY613FE7pNe0o7r7yGDY65fQ+ZI=; b=px9DAs9Kryrc9bxmy9bBjx90lVlzbTLTrWRKH9O5vxpssFWRCxvrc/U+YA DAMClE3J/SMobnM0JfVO6RKj335YggzooKMTxZrwUPHhm2zCxqzoAKRyqTMz q7RNTizKcj; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-ietf-ipfix-mib-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org ThomaFrom ipfix-bounces@ietf.org Wed Mar 12 09:03:54 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341073A6E9F; Wed, 12 Mar 2008 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qTD80xL7jW2; Wed, 12 Mar 2008 09:03:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D4F3A6EC4; Wed, 12 Mar 2008 09:03:49 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC34128C1EC for ; Wed, 12 Mar 2008 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoPSiB+a5aYu for ; Wed, 12 Mar 2008 09:03:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 75D3728C737 for ; Wed, 12 Mar 2008 09:03:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,489,1199660400"; d="scan'208";a="3279704" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2008 17:00:40 +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/8.12.11) with ESMTP id m2CG0e78026646; Wed, 12 Mar 2008 17:00:40 +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 m2CG0ZCh021670; Wed, 12 Mar 2008 16:00:35 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2CG0Yj21235; Wed, 12 Mar 2008 16:00:34 GMT Message-ID: <47D7FE30.3080808@cisco.com> Date: Wed, 12 Mar 2008 16:00:48 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Thomas Dietz , kobayashi atsushi , Benoit Claise DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6437; t=1205337640; x=1206201640; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-ietf-ipfix-mib-03 |Sender:=20; bh=6g/f0nxFJrmeE5hrUY613FE7pNe0o7r7yGDY65fQ+ZI=; b=px9DAs9Kryrc9bxmy9bBjx90lVlzbTLTrWRKH9O5vxpssFWRCxvrc/U+YA DAMClE3J/SMobnM0JfVO6RKj335YggzooKMTxZrwUPHhm2zCxqzoAKRyqTMz q7RNTizKcj; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-ietf-ipfix-mib-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Thomas, Atsushi-san, Benoit, Here with a quick review of draft-ietf-ipfix-mib-03. Mostly just editorial stuff, except for a question on the ipfixTransportSessionGroupTable. Cheers, P. 5.1. The Transport Session Table > For SCTP the table contains the SCTP Assoc Id I'd prefer to say "SCTP association ID", else use "sctpAssocId" per RFC 3873. 5.1.1. The Transport Session Group Table > For failover a Transport Session group can contain one Transport > Session with member type "primary" and several Transport Sessions > with type "secondary". Entries with other member types are not > allowed for that group. Unfortunately this doesn't allow for a very flexible hierarchy. > The values in brackets are the OID numbers. The Collector would then > have the same entry except that the index would be different (e.g. 17). may ---^^^^^ > We further asume that the Exporter uses the above connection as the > primary export for a session protected by a secondary backup > connection with an ipfixTransportSessionIndex of 28. Both, Exporter > and Collector, also need to have a Transport Session Group Table. > For the export this may look like the following table: -> "Both the Exporter and Collector need to have ..." > Since the Collector does not know which Transport Sessions belong > together it has one Transport Session Group Table entry per Transport > Session. So the entry for the given example is the following: Why have the ipfixTransportSessionGroupTable on the collector at all? 5.2. The Observation Domain Table > The Observation Domain Table (ipfixObservationDomainTable) contains a > reference to the ENTITY MIB [RFC4133]. The objects in the ENTITY MIB > denote the Observation Point associated with the given Observation > Domain Id. In addition a direction can be given to render more > specific which flow to monitor. "specifically". > Since a Collector could receive the > same Observation Domain Id in different sessions (thus from different > Exporters) the table takes the Transport Session index as first > index. The Transport Session index would be typically zero (0) at an > Exporter because the Observation Domain Id is usually unique per > Device and thus need not to be scoped by the Transport Session. Who can say what is usual? eg the above may not hold for an intermediate node (eg, an aggregator). Rather, consider: The Transport Session index may be zero (0) when the Observation Domain Id is unique per Device and does not need to be scoped by the Transport Session. 5.3. The Template Table > In addition it contains an inactive timeout > to terminate Flows that are inactive for a certain amount of time and > an active timeout to expire Flows that are still active to get > intermediate Flow Records for these long-living Flows. Surely these timeouts are properties of the cache in which these flows are stored, and really nothing to do with the templates? 5.4. The Template Definition Table > This leads to the following Template Table defining Template and > Option Template: > > ipfixTemplateTable (5) > | > +- ipfixTemplateEntry (1) > | > +- index (11) > | > +- index (3) > | > + index (257) > | +- ipfixTemplateId (1) = 257 > | +- ipfixTemplateSetId (2) = 2 > | +- ipfixTemplateAccessTime (3) = 2007-7-9,12:49:11.2,+2:0 > | +- ipfixTemplateActiveTimeout (4) = 0 > | +- ipfixTemplateInactiveTimeout (5) = 500 > | > + index (264) > +- ipfixTemplateId (1) = 264 > +- ipfixTemplateSetId (2) = 3 > +- ipfixTemplateAccessTime (3) = 2007-7-9,12:47:04.8,+2:0 > +- ipfixTemplateActiveTimeout (4) = 0 > +- ipfixTemplateInactiveTimeout (5) = 0 Template 264 isn't mentioned elsewhere, so could just be removed from here fors, Atsushi-san, Benoit, Here with a quick review of draft-ietf-ipfix-mib-03. Mostly just editorial stuff, except for a question on the ipfixTransportSessionGroupTable. Cheers, P. 5.1. The Transport Session Table > For SCTP the table contains the SCTP Assoc Id I'd prefer to say "SCTP association ID", else use "sctpAssocId" per RFC 3873. 5.1.1. The Transport Session Group Table > For failover a Transport Session group can contain one Transport > Session with member type "primary" and several Transport Sessions > with type "secondary". Entries with other member types are not > allowed for that group. Unfortunately this doesn't allow for a very flexible hierarchy. > The values in brackets are the OID numbers. The Collector would then > have the same entry except that the index would be different (e.g. 17). may ---^^^^^ > We further asume that the Exporter uses the above connection as the > primary export for a session protected by a secondary backup > connection with an ipfixTransportSessionIndex of 28. Both, Exporter > and Collector, also need to have a Transport Session Group Table. > For the export this may look like the following table: -> "Both the Exporter and Collector need to have ..." > Since the Collector does not know which Transport Sessions belong > together it has one Transport Session Group Table entry per Transport > Session. So the entry for the given example is the following: Why have the ipfixTransportSessionGroupTable on the collector at all? 5.2. The Observation Domain Table > The Observation Domain Table (ipfixObservationDomainTable) contains a > reference to the ENTITY MIB [RFC4133]. The objects in the ENTITY MIB > denote the Observation Point associated with the given Observation > Domain Id. In addition a direction can be given to render more > specific which flow to monitor. "specifically". > Since a Collector could receive the > same Observation Domain Id in different sessions (thus from different > Exporters) the table takes the Transport Session index as first > index. The Transport Session index would be typically zero (0) at an > Exporter because the Observation Domain Id is usually unique per > Device and thus need not to be scoped by the Transport Session. Who can say what is usual? eg the above may not hold for an intermediate node (eg, an aggregator). Rather, consider: The Transport Session index may be zero (0) when the Observation Domain Id is unique per Device and does not need to be scoped by the Transport Session. 5.3. The Template Table > In addition it contains an inactive timeout > to terminate Flows that are inactive for a certain amount of time and > an active timeout to expire Flows that are still active to get > intermediate Flow Records for these long-living Flows. Surely these timeouts are properties of the cache in which these flows are stored, and really nothing to do with the templates? 5.4. The Template Definition Table > This leads to the following Template Table defining Template and > Option Template: > > ipfixTemplateTable (5) > | > +- ipfixTemplateEntry (1) > | > +- index (11) > | > +- index (3) > | > + index (257) > | +- ipfixTemplateId (1) = 257 > | +- ipfixTemplateSetId (2) = 2 > | +- ipfixTemplateAccessTime (3) = 2007-7-9,12:49:11.2,+2:0 > | +- ipfixTemplateActiveTimeout (4) = 0 > | +- ipfixTemplateInactiveTimeout (5) = 500 > | > + index (264) > +- ipfixTemplateId (1) = 264 > +- ipfixTemplateSetId (2) = 3 > +- ipfixTemplateAccessTime (3) = 2007-7-9,12:47:04.8,+2:0 > +- ipfixTemplateActiveTimeout (4) = 0 > +- ipfixTemplateInactiveTimeout (5) = 0 Template 264 isn't mentioned elsewhere, so could just be removed from here for clarity. > The Template Definition Table for the Template may look like follows: > > ipfixTemplateDefinitionTable (6) > | > +- ipfixTemplateDefinitionEntry (1) > | > +- index (11) > | > +- index (3) > | > + index (257) > | > +- index (1) > | +- ipfixTemplateDefinitionIndex (1) = 1 > | +- ipfixTemplateDefinitionIeId (2) = 158 > | | (flowStartDeltaMicroseconds) > | +- ipfixTemplateDefinitionIeLength (3) = 4 > | +- ipfixTemplateDefinitionFlags (4) = 0 > | > +- index (2) > | +- ipfixTemplateDefinitionIndex (1) = 2 > | +- ipfixTemplateDefinitionIeId (2) = 159 > | | (flowStartDeltaMicroseconds) That should be flowEndDeltaMicroseconds. 5.6. The Selector Functions > The subtree ipfixSelectorFunctions is a placeholder where all > standard filtering and sampling functions should be located (if any) > and is mainly built for extensibility in future versions. It > currently contains the Select All functions (ipfixFuncSelectAll). ^^^^^^^^^ "function" (ie, singular). 5.6.1. Textual Convention IpfixFunctionAvailabilty > In conjunction with the Selector Functions the textual convention > IpfixFunctionAvailabilty is defined in the MIB. It MUST be used > within all Selector Functions to indicate if a standard function is > currently available at the Device or not. The previously mentioned > Select All function is always available. ^^ "MUST always be available". 5.7. The Statistical Tables > The remaining tables are all for statistical evaluation and all of > them are optional. Those table gather statistical values for a > corresponding table of those described above. "These tables gather statistical values for the corresponding tables described above." -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix clarity. > The Template Definition Table for the Template may look like follows: > > ipfixTemplateDefinitionTable (6) > | > +- ipfixTemplateDefinitionEntry (1) > | > +- index (11) > | > +- index (3) > | > + index (257) > | > +- index (1) > | +- ipfixTemplateDefinitionIndex (1) = 1 > | +- ipfixTemplateDefinitionIeId (2) = 158 > | | (flowStartDeltaMicroseconds) > | +- ipfixTemplateDefinitionIeLength (3) = 4 > | +- ipfixTemplateDefinitionFlags (4) = 0 > | > +- index (2) > | +- ipfixTemplateDefinitionIndex (1) = 2 > | +- ipfixTemplateDefinitionIeId (2) = 159 > | | (flowStartDeltaMicroseconds) That should be flowEndDeltaMicroseconds. 5.6. The Selector Functions > The subtree ipfixSelectorFunctions is a placeholder where all > standard filtering and sampling functions should be located (if any) > and is mainly built for extensibility in future versions. It > currently contains the Select All functions (ipfixFuncSelectAll). ^^^^^^^^^ "function" (ie, singular). 5.6.1. Textual Convention IpfixFunctionAvailabilty > In conjunction with the Selector Functions the textual convention > IpfixFunctionAvailabilty is defined in the MIB. It MUST be used > within all Selector Functions to indicate if a standard function is > currently available at the Device or not. The previously mentioned > Select All function is always available. ^^ "MUST always be available". 5.7. The Statistical Tables > The remaining tables are all for statistical evaluation and all of > them are optional. Those table gather statistical values for a > corresponding table of those described above. "These tables gather statistical values for the corresponding tables described above." -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Mar 12 12:19:12 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E963A6EDB; Wed, 12 Mar 2008 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.518 X-Spam-Level: X-Spam-Status: No, score=-105.518 tagged_above=-999 required=5 tests=[AWL=-5.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvNFrK0YfHFV; Wed, 12 Mar 2008 12:19:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A873A6EE9; Wed, 12 Mar 2008 12:19:11 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7C83A6ECF for ; Wed, 12 Mar 2008 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnb8gG5gXsfb for ; Wed, 12 Mar 2008 12:19:09 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id E03643A67AF for ; Wed, 12 Mar 2008 12:19:08 -0700 (PDT) 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 m2CJGhO5008549 for ; Wed, 12 Mar 2008 15:16:43 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2CJGJOZ008519 for ; Wed, 12 Mar 2008 15:16:19 -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 m2CJGJ7h008517; Wed, 12 Mar 2008 15:16:19 -0400 (EDT) Received: from [130.129.87.32] (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.70) with ESMTP id m2CJGJFl028829; Wed, 12 Mar 2008 15:16:19 -0400 Message-Id: From: Brian Trammell To: Andrew Johnson In-Reply-To: <1205326627.9226.19.camel@localhost> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 12 Mar 2008 15:16:18 -0400 References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Andrew, Paul, Benoit, all, Thanks for the comments; I'll respond in more detail to the rest of them in another thread, but I did want to get into this issue specifically... Basically, what Andrew said. Details inline. On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: > Hi Benoit et al. > > On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: > [SNIP] >> - messageScope, sessionScope, etc...: instead of multiplying the >> information elements "...Scope", for which the content is ignored, >> why >> not have a "scope" IE with some valueFrom ipfix-bounces@ietf.org Wed Mar 12 12:19:12 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E963A6EDB; Wed, 12 Mar 2008 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.518 X-Spam-Level: X-Spam-Status: No, score=-105.518 tagged_above=-999 required=5 tests=[AWL=-5.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvNFrK0YfHFV; Wed, 12 Mar 2008 12:19:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A873A6EE9; Wed, 12 Mar 2008 12:19:11 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7C83A6ECF for ; Wed, 12 Mar 2008 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnb8gG5gXsfb for ; Wed, 12 Mar 2008 12:19:09 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id E03643A67AF for ; Wed, 12 Mar 2008 12:19:08 -0700 (PDT) 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 m2CJGhO5008549 for ; Wed, 12 Mar 2008 15:16:43 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2CJGJOZ008519 for ; Wed, 12 Mar 2008 15:16:19 -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 m2CJGJ7h008517; Wed, 12 Mar 2008 15:16:19 -0400 (EDT) Received: from [130.129.87.32] (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.70) with ESMTP id m2CJGJFl028829; Wed, 12 Mar 2008 15:16:19 -0400 Message-Id: From: Brian Trammell To: Andrew Johnson In-Reply-To: <1205326627.9226.19.camel@localhost> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 12 Mar 2008 15:16:18 -0400 References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Andrew, Paul, Benoit, all, Thanks for the comments; I'll respond in more detail to the rest of them in another thread, but I did want to get into this issue specifically... Basically, what Andrew said. Details inline. On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: > Hi Benoit et al. > > On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: > [SNIP] >> - messageScope, sessionScope, etc...: instead of multiplying the >> information elements "...Scope", for which the content is ignored, >> why >> not have a "scope" IE with some values in there. Like in RFC3954: >> Scope 1 Field Type >> The relevant portion of the Exporter/NetFlow process to which >> the Options Template Record refers. >> Currently defined values are: >> 1 System >> 2 Interface >> 3 Line Card >> 4 Cache >> 5 Template > > A series of IEs that are only useful for defining the scope may seem > undesirable but I think the principle could be very useful. > > We already have Template ID and Line Card IDs that can be used more > explicitly for scoping options. Perhaps defining streamID, messageID > and sessionID would be more palatable, with the special case of using > them with a length of zero means *this* message or *this* session. Yes, indeed. The whole meaning of messageScope is to scope things to _this_ message, and the ability to scope to other messages by messageID would make the proposed mechanism more powerful. However, there are a few problems/unresolved issues here: 1. Multiple messages in the same session can have the same sequence number (non-data records don't increment sequence, so template-only messages or withdrawals will repeat sequence numbers) 2. Sequence number wraparound will occur; how to handle this? 3. Would sequence numbers have to match, or would addressing any record with a messageID refer to the message containing that record? If not, how to handle the error? 4. Would CPs be _required_ to handle Message ID correctly? If so, that has serious resource implications... These (well, these and laziness) are the reasons that messageScope was designed to refer only to the current message. > The messageID could reference the message sequence number sent for > each > message. The sessionID is trickier, but it is possible to have the > Exporting Process choose the ID and communicate it to the Collector. Session ID, i.e., allowing information in one transport session to be scoped to another, violates the assumption in 5101 that the transport session is the root scope, and scoped information and templates in one session are independent from those in any other. Referring to sessions other than *this* session is impossible, because in IPFIX, other sessions _do not exist_. So, while we certainly could recommend that these IEs be sent with reduced-length encoding (we're not in the text or examples now, I don't think) I don't think that expanding the meaning for cross- message or cross-session references is something that should we should do _at this point_. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix s in there. Like in RFC3954: >> Scope 1 Field Type >> The relevant portion of the Exporter/NetFlow process to which >> the Options Template Record refers. >> Currently defined values are: >> 1 System >> 2 Interface >> 3 Line Card >> 4 Cache >> 5 Template > > A series of IEs that are only useful for defining the scope may seem > undesirable but I think the principle could be very useful. > > We already have Template ID and Line Card IDs that can be used more > explicitly for scoping options. Perhaps defining streamID, messageID > and sessionID would be more palatable, with the special case of using > them with a length of zero means *this* message or *this* session. Yes, indeed. The whole meaning of messageScope is to scope things to _this_ message, and the ability to scope to other messages by messageID would make the proposed mechanism more powerful. However, there are a few problems/unresolved issues here: 1. Multiple messages in the same session can have the same sequence number (non-data records don't increment sequence, so template-only messages or withdrawals will repeat sequence numbers) 2. Sequence number wraparound will occur; how to handle this? 3. Would sequence numbers have to match, or would addressing any record with a messageID refer to the message containing that record? If not, how to handle the error? 4. Would CPs be _required_ to handle Message ID correctly? If so, that has serious resource implications... These (well, these and laziness) are the reasons that messageScope was designed to refer only to the current message. > The messageID could reference the message sequence number sent for > each > message. The sessionID is trickier, but it is possible to have the > Exporting Process choose the ID and communicate it to the Collector. Session ID, i.e., allowing information in one transport session to be scoped to another, violates the assumption in 5101 that the transport session is the root scope, and scoped information and templates in one session are independent from those in any other. Referring to sessions other than *this* session is impossible, because in IPFIX, other sessions _do not exist_. So, while we certainly could recommend that these IEs be sent with reduced-length encoding (we're not in the text or examples now, I don't think) I don't think that expanding the meaning for cross- message or cross-session references is something that should we should do _at this point_. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Mar 12 17:13:05 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9800D28C535; Wed, 12 Mar 2008 17:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMsYzTTCfk55; Wed, 12 Mar 2008 17:13:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D433A684D; Wed, 12 Mar 2008 17:13:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EBE3A6968 for ; Wed, 12 Mar 2008 17:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DssL+T0es0DV for ; Wed, 12 Mar 2008 17:13:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0F61F3A67B3 for ; Wed, 12 Mar 2008 17:13:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,491,1199660400"; d="asc'?scan'208";a="3312193" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2008 01:10:39 +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/8.12.11) with ESMTP id m2D0AdYv032671; Thu, 13 Mar 2008 01:10:39 +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 m2D0AdCh005440; Thu, 13 Mar 2008 00:10:39 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2D0Acj28702; Thu, 13 Mar 2008 00:10:38 GMT From: Andrew Johnson To: Brian Trammell In-Reply-To: References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> Date: Thu, 13 Mar 2008 00:10:37 +0000 Message-Id: <1205367037.9782.94.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.1mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5977; t=1205367039; x=1206231039; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=aYJPpQuoP6m2czp5YRF3epIs7y8srQw99Ey5tuqsxWY=; b=SrEpjGgM97ArjZUy4kRFo5F/3DfErY5AFBpcN3ihrhNVSdhDPcQ0KQaS43 D6VKtvCsPtS8RVtyr7tWr7MUlTT6EQ8z9ioPMv7AN0OpxNlD26bdEKhW743t jsaTJHYX9+; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485557761From ipfix-bounces@ietf.org Wed Mar 12 17:13:05 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9800D28C535; Wed, 12 Mar 2008 17:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMsYzTTCfk55; Wed, 12 Mar 2008 17:13:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D433A684D; Wed, 12 Mar 2008 17:13:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EBE3A6968 for ; Wed, 12 Mar 2008 17:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DssL+T0es0DV for ; Wed, 12 Mar 2008 17:13:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0F61F3A67B3 for ; Wed, 12 Mar 2008 17:13:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,491,1199660400"; d="asc'?scan'208";a="3312193" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2008 01:10:39 +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/8.12.11) with ESMTP id m2D0AdYv032671; Thu, 13 Mar 2008 01:10:39 +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 m2D0AdCh005440; Thu, 13 Mar 2008 00:10:39 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2D0Acj28702; Thu, 13 Mar 2008 00:10:38 GMT From: Andrew Johnson To: Brian Trammell In-Reply-To: References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> Date: Thu, 13 Mar 2008 00:10:37 +0000 Message-Id: <1205367037.9782.94.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.1mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5977; t=1205367039; x=1206231039; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=aYJPpQuoP6m2czp5YRF3epIs7y8srQw99Ey5tuqsxWY=; b=SrEpjGgM97ArjZUy4kRFo5F/3DfErY5AFBpcN3ihrhNVSdhDPcQ0KQaS43 D6VKtvCsPtS8RVtyr7tWr7MUlTT6EQ8z9ioPMv7AN0OpxNlD26bdEKhW743t jsaTJHYX9+; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485557761==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0485557761== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KUCuEYTgNsxF/QVaGK6f" --=-KUCuEYTgNsxF/QVaGK6f Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote: > Andrew, Paul, Benoit, all, >=20 > Thanks for the comments; I'll respond in more detail to the rest of =20 > them in another thread, but I did want to get into this issue =20 > specifically... >=20 > Basically, what Andrew said. Details inline. >=20 > On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: >=20 > > Hi Benoit et al. > > > > On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: > > [SNIP] > >> - messageScope, sessionScope, etc...: instead of multiplying the > >> information elements "...Scope", for which the content is ignored, =20 > >> why > >> not have a "scope" IE with some values in there. Like in RFC3954: > >> Scope 1 Field Type > >> The relevant portion of the Exporter/NetFlow process to which > >> the Options Template Record refers. > >> Currently defined values are: > >> 1 System > >> 2 Interface > >> 3 Line Card > >> 4 Cache > >> 5 Template > > > > A series of IEs that are only useful for defining the scope may seem > > undesirable but I think the principle could be very useful. > > > > We already have Template ID and Line Card IDs that can be used more > > explicitly for scoping options. Perhaps defining streamID, messageID > > and sessionID would be more palatable, with the special case of using > > them with a length of zero means *this* message or *this* session. >=20 > Yes, indeed. The whole meaning of messageScope is to scope things to =20 > _this_ message, and the ability to scope to other messages by =20 > messageID would make the proposed mechanism more powerful. However, > there are a few problems/unresolved issues here: >=20 > 1. Multiple messages in the same session can have the same sequence =20 > number (non-data records don't increment sequence, so template-only =20 > messages or withdrawals will repeat sequence numbers) This is a very good point. Perhaps the answer is as simple as it will apply to all these messages. This could be good or bad depending on what you're trying to say. > 2. Sequence number wraparound will occur; how to handle this? I would say that the messageID would be a forward reference to either this message or a future one. In general options are scoped to future info rather than past stuff. That said, it would seem hard to predict a future sequence number, or at the very least the exporter could delay the sending of the option until the message it is needed in. That said, what about the case where the scoped data fills a packet completely, perhaps because of a really big packet section field. We might want to send the option in one packet referencing the next. > 3. Would sequence numbers have to match, or would addressing any =20 > record with a messageID refer to the message containing that record? =20 > If not, how to handle the error? I would say we want an exact match. If the sequence passes without an exact match then the CP can discard the info and log an error. =20 > 4. Would CPs be _required_ to handle Message ID correctly? If so, that =20 > has serious resource implications... I'm not so sure. If we consider that the info is only valid for one message in the near future then really the CP will only have to hold on for a couple at a time. One other minor issue is that each stream has independent sequence numbers so you could have the same messageID in multiple streams. This can be fixed by scoping the messageID to the stream or insisting that the streamID is sent as scope too. > These (well, these and laziness) are the reasons that messageScope was =20 > designed to refer only to the current message. >=20 > > The messageID could reference the message sequence number sent for =20 > > eac==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0485557761== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KUCuEYTgNsxF/QVaGK6f" --=-KUCuEYTgNsxF/QVaGK6f Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote: > Andrew, Paul, Benoit, all, >=20 > Thanks for the comments; I'll respond in more detail to the rest of =20 > them in another thread, but I did want to get into this issue =20 > specifically... >=20 > Basically, what Andrew said. Details inline. >=20 > On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: >=20 > > Hi Benoit et al. > > > > On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: > > [SNIP] > >> - messageScope, sessionScope, etc...: instead of multiplying the > >> information elements "...Scope", for which the content is ignored, =20 > >> why > >> not have a "scope" IE with some values in there. Like in RFC3954: > >> Scope 1 Field Type > >> The relevant portion of the Exporter/NetFlow process to which > >> the Options Template Record refers. > >> Currently defined values are: > >> 1 System > >> 2 Interface > >> 3 Line Card > >> 4 Cache > >> 5 Template > > > > A series of IEs that are only useful for defining the scope may seem > > undesirable but I think the principle could be very useful. > > > > We already have Template ID and Line Card IDs that can be used more > > explicitly for scoping options. Perhaps defining streamID, messageID > > and sessionID would be more palatable, with the special case of using > > them with a length of zero means *this* message or *this* session. >=20 > Yes, indeed. The whole meaning of messageScope is to scope things to =20 > _this_ message, and the ability to scope to other messages by =20 > messageID would make the proposed mechanism more powerful. However, > there are a few problems/unresolved issues here: >=20 > 1. Multiple messages in the same session can have the same sequence =20 > number (non-data records don't increment sequence, so template-only =20 > messages or withdrawals will repeat sequence numbers) This is a very good point. Perhaps the answer is as simple as it will apply to all these messages. This could be good or bad depending on what you're trying to say. > 2. Sequence number wraparound will occur; how to handle this? I would say that the messageID would be a forward reference to either this message or a future one. In general options are scoped to future info rather than past stuff. That said, it would seem hard to predict a future sequence number, or at the very least the exporter could delay the sending of the option until the message it is needed in. That said, what about the case where the scoped data fills a packet completely, perhaps because of a really big packet section field. We might want to send the option in one packet referencing the next. > 3. Would sequence numbers have to match, or would addressing any =20 > record with a messageID refer to the message containing that record? =20 > If not, how to handle the error? I would say we want an exact match. If the sequence passes without an exact match then the CP can discard the info and log an error. =20 > 4. Would CPs be _required_ to handle Message ID correctly? If so, that =20 > has serious resource implications... I'm not so sure. If we consider that the info is only valid for one message in the near future then really the CP will only have to hold on for a couple at a time. One other minor issue is that each stream has independent sequence numbers so you could have the same messageID in multiple streams. This can be fixed by scoping the messageID to the stream or insisting that the streamID is sent as scope too. > These (well, these and laziness) are the reasons that messageScope was =20 > designed to refer only to the current message. >=20 > > The messageID could reference the message sequence number sent for =20 > > each > > message. The sessionID is trickier, but it is possible to have the > > Exporting Process choose the ID and communicate it to the Collector. >=20 > Session ID, i.e., allowing information in one transport session to be =20 > scoped to another, violates the assumption in 5101 that the transport =20 > session is the root scope, and scoped information and templates in one =20 > session are independent from those in any other. Referring to sessions =20 > other than *this* session is impossible, because in IPFIX, other =20 > sessions _do not exist_. Is there an assumption about the session being the root scope? We explicitly defined a number of IDs to be within a session, but surely some information is considered persistent across sessions, after all IPFIX requires tearing down and restarting a session for a number of reasons. A sessionID might be useful for reporting stats on torn down sessions, or storing/passing information about contributing sessions for an file/aggregator. That said, I can't see a safe way of defining a session ID without scoping the ID to the current session, which makes it a bit tricky. I think session can only be defined across sessions as the source/dest ports and addresses and a time period. > So, while we certainly could recommend that these IEs be sent with =20 > reduced-length encoding (we're not in the text or examples now, I =20 > don't think) I don't think that expanding the meaning for cross-=20 > message or cross-session references is something that should we should =20 > do _at this point_. Does RLE allow you to reduce them to 0 bytes? Cheers Andrew --=-KUCuEYTgNsxF/QVaGK6f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBH2HD6xaGr6Yt1y6ARAt5nAJ9yGAGyPmGEpbvXKCxEi/ruH8yDMgCgz0xT XJOWmBm5JNyJp5Hkgl9eoUo= =bi1r -----END PGP SIGNATURE----- --=-KUCuEYTgNsxF/QVaGK6f-- --===============0485557761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0485557761==-- h > > message. The sessionID is trickier, but it is possible to have the > > Exporting Process choose the ID and communicate it to the Collector. >=20 > Session ID, i.e., allowing information in one transport session to be =20 > scoped to another, violates the assumption in 5101 that the transport =20 > session is the root scope, and scoped information and templates in one =20 > session are independent from those in any other. Referring to sessions =20 > other than *this* session is impossible, because in IPFIX, other =20 > sessions _do not exist_. Is there an assumption about the session being the root scope? We explicitly defined a number of IDs to be within a session, but surely some information is considered persistent across sessions, after all IPFIX requires tearing down and restarting a session for a number of reasons. A sessionID might be useful for reporting stats on torn down sessions, or storing/passing information about contributing sessions for an file/aggregator. That said, I can't see a safe way of defining a session ID without scoping the ID to the current session, which makes it a bit tricky. I think session can only be defined across sessions as the source/dest ports and addresses and a time period. > So, while we certainly could recommend that these IEs be sent with =20 > reduced-length encoding (we're not in the text or examples now, I =20 > don't think) I don't think that expanding the meaning for cross-=20 > message or cross-session references is something that should we should =20 > do _at this point_. Does RLE allow you to reduce them to 0 bytes? Cheers Andrew --=-KUCuEYTgNsxF/QVaGK6f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBH2HD6xaGr6Yt1y6ARAt5nAJ9yGAGyPmGEpbvXKCxEi/ruH8yDMgCgz0xT XJOWmBm5JNyJp5Hkgl9eoUo= =bi1r -----END PGP SIGNATURE----- --=-KUCuEYTgNsxF/QVaGK6f-- --===============0485557761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0485557761==-- From ipfix-bounces@ietf.org Thu Mar 13 05:15:27 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D5B28C117; Thu, 13 Mar 2008 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.601 X-Spam-Level: X-Spam-Status: No, score=-99.601 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sU12JP+e2x; Thu, 13 Mar 2008 05:15:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CEB28C75B; Thu, 13 Mar 2008 05:15:25 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6473A6820 for ; Thu, 13 Mar 2008 05:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S27iYuvlfap6 for ; Thu, 13 Mar 2008 05:15:22 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1F3EF28C7E8 for ; Thu, 13 Mar 2008 05:15:21 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2DCCS9A042694; Thu, 13 Mar 2008 21:12:29 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 13 Mar 2008 21:12:35 +0900 From: Kobayashi Atsushi To: Nevil Brownlee In-Reply-To: <1205336737.7556.15.camel@localhost> References: <1205336737.7556.15.camel@localhost> Message-Id: <20080313210416.ED02.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Thu, 13 Mar 2008 21:12:29 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] DRAFT minutes for IPFIX meeting at IETF-71 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, > Nevil announced that the wg will > hold an editing session for authors/contributors to the framework > documents on Thursday morning in room 414. I prepared slide regarding IPFIX protocol considerations. It summarizes discussion points. Please get from the following site. http://www3.plala.or.jp/akoba/ietf71st_mediator.pdf Regards, Atsushi KOBAYASHI _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Mar 13 05:15:27 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D5B28C117; Thu, 13 Mar 2008 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.601 X-Spam-Level: X-Spam-Status: No, score=-99.601 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sU12JP+e2x; Thu, 13 Mar 2008 05:15:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CEB28C75B; Thu, 13 Mar 2008 05:15:25 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6473A6820 for ; Thu, 13 Mar 2008 05:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S27iYuvlfap6 for ; Thu, 13 Mar 2008 05:15:22 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1F3EF28C7E8 for ; Thu, 13 Mar 2008 05:15:21 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m2DCCS9A042694; Thu, 13 Mar 2008 21:12:29 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 13 Mar 2008 21:12:35 +0900 From: Kobayashi Atsushi To: Nevil Brownlee In-Reply-To: <1205336737.7556.15.camel@localhost> References: <1205336737.7556.15.camel@localhost> Message-Id: <20080313210416.ED02.AKOBA@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Thu, 13 Mar 2008 21:12:29 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] DRAFT minutes for IPFIX meeting at IETF-71 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, > Nevil announced that the wg will > hold an editing session for authors/contributors to the framework > documents on Thursday morning in room 414. I prepared slide regarding IPFIX protocol considerations. It summarizes discussion points. Please get from the following site. http://www3.plala.or.jp/akoba/ietf71st_mediator.pdf Regards, Atsushi KOBAYASHI _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Mar 13 12:09:34 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E5D3A6EC9; Thu, 13 Mar 2008 12:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQcSx9Oosnvr; Thu, 13 Mar 2008 12:09:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2603A6A5A; Thu, 13 Mar 2008 12:09:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EE23A693E for ; Thu, 13 Mar 2008 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9fj1s6ubg45 for ; Thu, 13 Mar 2008 12:09:29 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 5EA6B3A6ECE for ; Thu, 13 Mar 2008 12:09:23 -0700 (PDT) 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 m2DJ6vF7011895 for ; Thu, 13 Mar 2008 15:06:57 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2DJ69nn011796 for ; Thu, 13 Mar 2008 15:06:09 -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 m2DJ69D8011794; Thu, 13 Mar 2008 15:06:09 -0400 (EDT) Received: from [130.129.85.218] (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.70) with ESMTP id m2DJ68DH019180; Thu, 13 Mar 2008 15:06:09 -0400 Message-Id: From: Brian Trammell To: Andrew Johnson In-Reply-To: <1205367037.9782.94.camel@localhost> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 13 Mar 2008 15:06:08 -0400 References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> <1205367037.9782.94.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Mar 12, 2008, at 8:10 PM, Andrew Johnson wrote: > > On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote: >> Andrew, Paul, Benoit, all, >> >> Thanks for the comments; I'll respond in more detail to the rest of >> them in another thread, but I did want to get into this issue >> specifically... >> >> Basically, what Andrew said. Details inline. >> >> On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: >> >>> Hi Benoit et al. >>> >>> On Mon, 2008-03-10 at From ipfix-bounces@ietf.org Thu Mar 13 12:09:34 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E5D3A6EC9; Thu, 13 Mar 2008 12:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQcSx9Oosnvr; Thu, 13 Mar 2008 12:09:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2603A6A5A; Thu, 13 Mar 2008 12:09:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EE23A693E for ; Thu, 13 Mar 2008 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9fj1s6ubg45 for ; Thu, 13 Mar 2008 12:09:29 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 5EA6B3A6ECE for ; Thu, 13 Mar 2008 12:09:23 -0700 (PDT) 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 m2DJ6vF7011895 for ; Thu, 13 Mar 2008 15:06:57 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2DJ69nn011796 for ; Thu, 13 Mar 2008 15:06:09 -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 m2DJ69D8011794; Thu, 13 Mar 2008 15:06:09 -0400 (EDT) Received: from [130.129.85.218] (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.70) with ESMTP id m2DJ68DH019180; Thu, 13 Mar 2008 15:06:09 -0400 Message-Id: From: Brian Trammell To: Andrew Johnson In-Reply-To: <1205367037.9782.94.camel@localhost> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 13 Mar 2008 15:06:08 -0400 References: <47D5F8D7.2070103@cisco.com> <1205326627.9226.19.camel@localhost> <1205367037.9782.94.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Mar 12, 2008, at 8:10 PM, Andrew Johnson wrote: > > On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote: >> Andrew, Paul, Benoit, all, >> >> Thanks for the comments; I'll respond in more detail to the rest of >> them in another thread, but I did want to get into this issue >> specifically... >> >> Basically, what Andrew said. Details inline. >> >> On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote: >> >>> Hi Benoit et al. >>> >>> On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote: >>> [SNIP] >>>> - messageScope, sessionScope, etc...: instead of multiplying the >>>> information elements "...Scope", for which the content is ignored, >>>> why >>>> not have a "scope" IE with some values in there. Like in RFC3954: >>>> Scope 1 Field Type >>>> The relevant portion of the Exporter/NetFlow process to >>>> which >>>> the Options Template Record refers. >>>> Currently defined values are: >>>> 1 System >>>> 2 Interface >>>> 3 Line Card >>>> 4 Cache >>>> 5 Template >>> >>> A series of IEs that are only useful for defining the scope may seem >>> undesirable but I think the principle could be very useful. >>> >>> We already have Template ID and Line Card IDs that can be used more >>> explicitly for scoping options. Perhaps defining streamID, >>> messageID >>> and sessionID would be more palatable, with the special case of >>> using >>> them with a length of zero means *this* message or *this* session. >> >> Yes, indeed. The whole meaning of messageScope is to scope things to >> _this_ message, and the ability to scope to other messages by >> messageID would make the proposed mechanism more powerful. However, >> there are a few problems/unresolved issues here: >> >> 1. Multiple messages in the same session can have the same sequence >> number (non-data records don't increment sequence, so template-only >> messages or withdrawals will repeat sequence numbers) > > This is a very good point. Perhaps the answer is as simple as it > will > apply to all these messages. This could be good or bad depending on > what you're trying to say. For the current application of messageScope, the MD5 checksum, this is very, very bad. Messages must be uniquely identified in order to checksum them. >> 2. Sequence number wraparound will occur; how to handle this? > > I would say that the messageID would be a forward reference to either > this message or a future one. In general options are scoped to future > info rather than past stuff. That said, it would seem hard to > predict a > future sequence number, or at the very least the exporter could delay > the sending of the option until the message it is needed in. Again for checksums, it's much better to have the reference go _back_ in time. So there are a couple of use cases here, and they conflict. > That said, what about the case where the scoped data fills a packet > completely, perhaps because of a really big packet section field. We > might want to send the option in one packet referencing the next. _That_'s a good example, but the right way to do that right now, I think, would be to use an existing identifier; flowID or the universally useful commonPropertiesID. >> 3. Would sequence numbers have to match, or would addressing any >> record with a messageID refer to the message containing that record? >> If not, how to handle the error? > > I would say we want an exact match. If the sequence passes without an > exact match then the CP can discard the info and log an error. > > >> 4. Would CPs be _required_ to handle Message ID correctly? If so, >> that >> has serious resource implications... > > I'm not so sure. If we consider that the info is only valid for one > message in the near future then really the CP will only have to hold > on > for a couple at a time. > > One other minor issue is that each stream has independent sequence > numbers so you could have the same messageID in multiple streams. > This > can be fixed by scoping the messageID to the stream or insisting that > the streamID is sent as scope too. You'd have to do the latter (streams are not universal, and restricting message ID scope to stream might break stream selection approaches other than per-stream). >> These (well, these and laziness) are the reasons that messageScope >> was >> designed to refer only to the current message. I'll reply to myself here to sum up. This is a very interesting discussion, but it's getting bigger, and bigger, and further and further from the context in which it originated. I don't think we want to define direct inter-message and inter-session metadata references -- which look to be a whole lot of work and potentially quite restrictive if not done very, very right -- in the file draft. I'll propose the following: the messageMD5Checksum IE could be redefined such that it contains the MD5 checksum for the containing message regardless of how it's scoped; this would obviate the need for the messageScope IE entirely within the file draft. (I'm not yet sure how to do the same for sessionScope. The "right" thing to do here would be to allow scope-length zero -- such that the only scope is the implicit root, observation domain and transport session -- but we made that illegal in 5101.) >> So, while we certainly could recommend that these IEs be sent with >> reduced-length encoding (we're not in the text or examples now, I >> don't think) I don't think that expanding the meaning for cross- >> message or cross-session references is something that should we >> should >> do _at this point_. > > Does RLE allow you to reduce them to 0 bytes? Per 5101 section 6.2 para 4, zero is not explicitly forbidden, but there is an example stating the minimum size for unsigned64 is 1. However, octet is not a data type for which RLE (actually, RSE, reduced-size encoding) is allowed. So no, this won't work, anyway... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix 23:13 -0400, Benoit Claise wrote: >>> [SNIP] >>>> - messageScope, sessionScope, etc...: instead of multiplying the >>>> information elements "...Scope", for which the content is ignored, >>>> why >>>> not have a "scope" IE with some values in there. Like in RFC3954: >>>> Scope 1 Field Type >>>> The relevant portion of the Exporter/NetFlow process to >>>> which >>>> the Options Template Record refers. >>>> Currently defined values are: >>>> 1 System >>>> 2 Interface >>>> 3 Line Card >>>> 4 Cache >>>> 5 Template >>> >>> A series of IEs that are only useful for defining the scope may seem >>> undesirable but I think the principle could be very useful. >>> >>> We already have Template ID and Line Card IDs that can be used more >>> explicitly for scoping options. Perhaps defining streamID, >>> messageID >>> and sessionID would be more palatable, with the special case of >>> using >>> them with a length of zero means *this* message or *this* session. >> >> Yes, indeed. The whole meaning of messageScope is to scope things to >> _this_ message, and the ability to scope to other messages by >> messageID would make the proposed mechanism more powerful. However, >> there are a few problems/unresolved issues here: >> >> 1. Multiple messages in the same session can have the same sequence >> number (non-data records don't increment sequence, so template-only >> messages or withdrawals will repeat sequence numbers) > > This is a very good point. Perhaps the answer is as simple as it > will > apply to all these messages. This could be good or bad depending on > what you're trying to say. For the current application of messageScope, the MD5 checksum, this is very, very bad. Messages must be uniquely identified in order to checksum them. >> 2. Sequence number wraparound will occur; how to handle this? > > I would say that the messageID would be a forward reference to either > this message or a future one. In general options are scoped to future > info rather than past stuff. That said, it would seem hard to > predict a > future sequence number, or at the very least the exporter could delay > the sending of the option until the message it is needed in. Again for checksums, it's much better to have the reference go _back_ in time. So there are a couple of use cases here, and they conflict. > That said, what about the case where the scoped data fills a packet > completely, perhaps because of a really big packet section field. We > might want to send the option in one packet referencing the next. _That_'s a good example, but the right way to do that right now, I think, would be to use an existing identifier; flowID or the universally useful commonPropertiesID. >> 3. Would sequence numbers have to match, or would addressing any >> record with a messageID refer to the message containing that record? >> If not, how to handle the error? > > I would say we want an exact match. If the sequence passes without an > exact match then the CP can discard the info and log an error. > > >> 4. Would CPs be _required_ to handle Message ID correctly? If so, >> that >> has serious resource implications... > > I'm not so sure. If we consider that the info is only valid for one > message in the near future then really the CP will only have to hold > on > for a couple at a time. > > One other minor issue is that each stream has independent sequence > numbers so you could have the same messageID in multiple streams. > This > can be fixed by scoping the messageID to the stream or insisting that > the streamID is sent as scope too. You'd have to do the latter (streams are not universal, and restricting message ID scope to stream might break stream selection approaches other than per-stream). >> These (well, these and laziness) are the reasons that messageScope >> was >> designed to refer only to the current message. I'll reply to myself here to sum up. This is a very interesting discussion, but it's getting bigger, and bigger, and further and further from the context in which it originated. I don't think we want to define direct inter-message and inter-session metadata references -- which look to be a whole lot of work and potentially quite restrictive if not done very, very right -- in the file draft. I'll propose the following: the messageMD5Checksum IE could be redefined such that it contains the MD5 checksum for the containing message regardless of how it's scoped; this would obviate the need for the messageScope IE entirely within the file draft. (I'm not yet sure how to do the same for sessionScope. The "right" thing to do here would be to allow scope-length zero -- such that the only scope is the implicit root, observation domain and transport session -- but we made that illegal in 5101.) >> So, while we certainly could recommend that these IEs be sent with >> reduced-length encoding (we're not in the text or examples now, I >> don't think) I don't think that expanding the meaning for cross- >> message or cross-session references is something that should we >> should >> do _at this point_. > > Does RLE allow you to reduce them to 0 bytes? Per 5101 section 6.2 para 4, zero is not explicitly forbidden, but there is an example stating the minimum size for unsigned64 is 1. However, octet is not a data type for which RLE (actually, RSE, reduced-size encoding) is allowed. So no, this won't work, anyway... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From nobody@cp.gomventshost.com Fri Mar 14 06:06:42 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FD83A6F0D for ; Fri, 14 Mar 2008 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.514 X-Spam-Level: **** X-Spam-Status: No, score=4.514 tagged_above=-999 required=5 tests=[AV:HTML.Phishing.Auction-293=0.1, AWL=-0.052, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HEADER_CTYPE_ONLY=0.56, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, TVD_PH_SUBJ_META=0, URIBL_GREY=0.25, AV:HTML.Phishing.Auction-293=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS+EhmNPW5CB for ; Fri, 14 Mar 2008 06:06:42 -0700 (PDT) Received: from cp.gomventshost.com (mail.gomventshost.com [64.69.43.91]) by core3.amsl.com (Postfix) with ESMTP id 8F00A3A6AB5 for ; Fri, 14 Mar 2008 06:06:42 -0700 (PDT) Received: from nobody by cp.gomventshost.com with local (Exim 4.63) (envelope-from ) id 1Ja9a3-0004za-4W for ipfix-archive@megatron.ietf.org; Fri, 14 Mar 2008 08:04:15 -0500 To: ipfix-archive@megatron.ietf.org Subject: Question from eBay Member From: member@ebay.com Content-Type: text/html; Message-Id: Date: Fri, 14 Mar 2008 08:04:15 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.gomventshost.com X-AntiAbuse: Original Domain - megatron.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - cp.gomventshost.com
eBay New Unpaid Item Message from gbgb004: #120070947123 -- response required


Dear eBay member,

eBay member gbgb004 has left you a message regarding item #120070947123.

View the dispute thread to respond.

Regards,

Customer Support (Trust aand Safety Department)
eBay International AG

 

Copyright  2006 eBay, Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc.

From ipfix-bounces@ietf.org Fri Mar 14 09:40:33 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E09B28C47D; Fri, 14 Mar 2008 09:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.805 X-Spam-Level: X-Spam-Status: No, score=-100.805 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_64=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKLTwcB05+oE; Fri, 14 Mar 2008 09:40:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA6028C345; Fri, 14 Mar 2008 09:40:31 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464573A680B; Fri, 14 Mar 2008 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-DANWEb3d-P; Fri, 14 Mar 2008 09:40:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 553B628C345; Fri, 14 Mar 2008 09:40:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,502,1199660400"; d="scan'208";a="3524801" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2008 17:38:07 +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/8.12.11) with ESMTP id m2EGc789021057; Fri, 14 Mar 2008 17:38:07 +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 m2EGc6Ch016170; Fri, 14 Mar 2008 16:38:06 GMT Received: from [10.61.97.52] (dhcp-10-61-97-52.cisco.com [10.61.97.52]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2EGbwW06878; Fri, 14 Mar 2008 16:38:02 GMT Message-ID: <47DAA9FC.3000202@cisco.com> Date: Fri, 14 Mar 2008 16:38:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: "Joel M. Halpern" References: <47B61982.8040005@joelhalpern.com> In-Reply-To: <47B61982.8040005@joelhalpern.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12555; t=1205512687; x=1206376687; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20Gen-Art=20IETF=20LC=20review=3A=20draft -ietf-ipfix-testing-04.txt |Sender:=20; bh=rpuvXRzq5dc19SBgWlOxfwlGeWsc8h4rmKv/UXCgOxY=; b=VPkGL7Hln0sISRuiPeFIRcUj599nnsH0x/dpSICOed90I7GjGE++ZJlJ+Y EtYj93fjV4z0yhhwryteqs98RvKPZ2mTtXDGuFQNCuDCmLIydlWpU709vcHn ZrEiIw9r63; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Joel, Apologies for not responding sooner to your review, as it came right ahead of the -00 and -nn cutoffs. Please see some responses inline. > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: Guidelines for IP Flow Information eXport (IPFIX) Testing > Reviewer: Joel M. Halpern > Review Date: 15-Feb-2008 > IETF LC End Date: 26-Feb-2008 > IESG Telechat date: N/A > > Summary: This document needs some additional work before publication as > an informational RFC. > I would particularly recommend considering addressing at least the first > comment below prior to RFC publication. > I would also suggest that the test descriptions need some clarification > as described in the technical section below, particularly items 5 and 6. > > Comments: > > Conceptual: > 1) While the document is being published as an information RFC, the > wording of the abstract and introduction make it seem that this document > is actually defining conformance to the IPFIX RFCs. The IETF has > generally carefully steered clear of defining such conformance. > So, while publishing a useful test suite is probably a good idea, I > strongly recommend fixing the wording of at least the abstract and > introduction to make it quite clear that these are not mandatory tests, > and that these tests do not define conformance. Sure, the tests are not mandatory. However, if you were purchasing an IPFIX device which did not claim to be compliant with this draft, you might rightly ask why not when all the IPFIX implementations we know of to date have been. > Related to this, please do not assert (in section 3) that passing this > test suite constitutes conformance to the IPFIX architecture and > protocol. (Among other things,test suite passage proves nothing about > architectural conformance.) OK. > Technical: > 2) In the terminology section, an Observation Point is defined simply as > a place where packets can be observed. An Observation Domain is a > collection of Observation points. Then, in the middle of the definition > of an Observation domain it say "In the IPFIX MEssage it generates..." > but up till now none of the things that have been defined generate IPFIX > messages. It is possible that the "it" in the quote is supposed to be > the "Metering Process" mentioned in passing earlier in the definition. Correct, it is. > But the English grammar does not lead the reader to such a conclusion. > Later in that same definition, it beings to appear that an Observation > Domain (which is a collection of points, not a process or entity) is > supposed to generate IPFIX messages, since it is supposed to include a > Domain ID in the messages it generates. This definition for an > Observation Domain needs to be reworked, to avoid confusing the Domain > with the Measurement Process which is running in / for / on the Domain. The Metering Process generates flow records which the Exporting Process makes into IPFIX messages. This whole section is lifted directly from RFC5101, as stated right at the top of section 2: The terminology used in this document is fully aligned with the terminology specified in [RFC5101] which is reproduced here for reference. > 3) The use of capital "MUST" in section 3.1 is almost certainly wrong. > Firstly, what I think that section is saying is that being able to > correctly perform the basic tests is a precondition for being able to > perform further test successfully. Thats a precondition, not a "MUST". These are basic connectivity tests. If they don't pass then there's no point in proceeding with the later tests, since you don't even have a basic connection. So yes, these initial tests are a precondition for the later ones. In effect they MUST pass before proceeding. > Of lesser significance, this document does not provide any description > of what it means by "MUST". Right above the TOC, as ever: Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. > We are usually careful about how such > language is used in informational RFCs. I think the meaning would be > clearer if the real intent were stated. I suspect that some readers of > this review may find my concern here pedantic. But the continual use of > MUST in the document really, really bothers me. (I hope the next comment > helps explain why it bothers me so much.) > > 4) Then, the test descriptions go on to keep using this language. This > is a test suite description document. Simply state how to run the test. > There is no need for "MUST". Section 3 should indicate that the test > descriptions describe the preconditions and steps that the tester goes > through. So section 3.1 would begin "The tester creates one Exporting > Process and one collection process, configures the Exporting Process to > ..." The -00 version of this draft didn't use any RFC 2119 language. eg, section 3.1 began: Set up one Exporting and one Collecting Process. Configure the Exporting Process to send to the Collecting Process. However, we received feedback that RFC 2119 language should be used so a tester could clearly see what needed done, and could tick off compliance with each point as he worked through. Reworking the document like this is not an insignificant task. > 5) It is not clear what test steps like ~The tester ensures that an SCTP > association is established.~ (Or worse, the actual text which reads "the > test MUST ensure that an SCTP association is established." are supposed > to do. Is this an instruction to the tester to use network management > tools or CLI to verify a connection on both devices? Is it an > instruction to perform additional configuration? How does the tester > "ensure". That would very much depend on the implementation, don't you think? > A test suite should tell a tester what steps to undertake, > and what observations to perform. "Ensure" is not either one of those. Testing and verifying SCTP are quite beyond the scope of this draft. However, ability to bring up an SCTP association is a necessary prerequisite for the following tests. > 5a) To elaborate on this issue, in the middle of the test step about > ensuring that Data Records are actually exported, we finally get a > testable instruction, to whit, use a packet sniffer and check that the > packets are coming by. Sadly, that was only a suggestion of how the tester might perform this task. > 6) I believe I understand how a tester would create templates, for the > template test. But how is the tester to create data sets. Particularly > data sets with specific properties, such as the padding in section 3.2.3 > and 3.2.4? Again, that would very much depend upon the implementation being tested. Some implementations may add padding by default, or may have a switch to allow padding to be optional. It certainly wasn't an issue at our IPFIX interops. > The best conclusion I can come to is that this is a > collector test, and that it assumes a packet generator which can > generate IPFIX packets. That's a good option for testing the Collecting Process - though it wouldn't verify the Exporting Process. Another possiblity would be for the tester to inject known data into the Metering Process, either directly or by passing known traffic through the Observation Point(s). > Having such a device in a test setup makes > sense. But the test description does not say "configure a packet > generator to generate an IPFIX packet with ..." (There are other ways > to say this, but there needs to be some description of how testers are > expected to create data sets.) Again, this seems to be quite implementation dependent. I expect what you'd do for a PC based implementation would be quite different from what you'd for for a router based implementation. > 6a) Related to this, I find reading this document rather odd. I have > read many test suites for protocols and implementations of protocols. > They generally focus on a Device (or implementation, or entity) Under > Test, and the framing around that Device. This suite appears to be > trying to test two interacting devices simultaneously. That is > extremely difficult, and extremely confusing. The IPFIX protocol connects an Exporting Process (source) to a Collecting Process (destination). One is needed in order to test the other - or at the very least, something that does a good job of pretending to be an Exporter or Collector. eg, an Exporting Process won't export anything until it's able to bring up an SCTP association. So if you're going to inject packets (rather than have an Exporting Process) then you'll first need to do some SCTP negotiation. All in, it's most straightforward to connect an Exporter to a Collector. > It is particularly hard > because then the tester doesn't have enough points of control to perform > the tests and observe the results meaningfully. It is possible that > this combined suite is right for this problem. But if so, a lot of > explanation of why it is done that way and how the tester is to > accomplish his goals is needed. > > Minor: > 7) The abstract is worded as if one could not perform interoperability > testing without first running the tests in this document. While having > run the tests in this document will presumably increase the chances of a > successful interoperability test, they are not an inherent requirement > for such testing. We had three IPFIX interops, with this document being drafted after the first. I believe the pre-requisite for the second and third interops was that these basic tests had been run, so as to ensure a common baseline and rule out basic issues which had already been covered in previous interops. > 8) I would probably be inclined to lighten up the Motivation section a > bit. Or even remove it. I don't think we need to explain why test > suites are useful. If we really need a motivation section, then it > should explain something about why it is particularly complex to test > IPFIX implementations (if it is) and thus why the IETF feels it is > particularly useful to publish a test suite ourselves in this case. OK. > 9) The definition of Transport Session is actually the definition of > various kinds of transport sessions, and how they are identified. Could > the definition start with an actual definition please. (I.e. the > communication over time used to carry X between Y and Z? Or something.) Again, the definition is copied directly from RFC 5101. > 10) As an editorial matter, most testers I have worked with strongly > prefer if every step in a test is explicitly separate and named / > numbered. That way, they can check off each step as it goes. So the > beginning of 3.1.1 would be > i) Create One Exporting Process > ii) Create One Collection Process > iii) Configure the Exporting Process ... In effect, each of our MUSTs is such a check. At least, that was the intention. > 11) It is particularly odd to see a set of Stress/Load tests that > simultaneously claim to be measuring conformance and to not specify the > level of Stress / Load. Having a description of how to perform load > tests is useful. But its relationship to the other tests is confusing. > (This obviously is helped once we no longer claim that this is a > conformance test.) These tests verify what IPFIX devices do when overloaded, rather than testing that they're able to handle a certain load level. It's clearly impossible for us to state specific traffic levels since a) the overload level may vary enormously from device to device, and b) we're not interested in the specific level, but in the device's ability to handle extremes gracefully. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Mar 14 09:40:33 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E09B28C47D; Fri, 14 Mar 2008 09:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.805 X-Spam-Level: X-Spam-Status: No, score=-100.805 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_64=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKLTwcB05+oE; Fri, 14 Mar 2008 09:40:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA6028C345; Fri, 14 Mar 2008 09:40:31 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464573A680B; Fri, 14 Mar 2008 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-DANWEb3d-P; Fri, 14 Mar 2008 09:40:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 553B628C345; Fri, 14 Mar 2008 09:40:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,502,1199660400"; d="scan'208";a="3524801" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2008 17:38:07 +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/8.12.11) with ESMTP id m2EGc789021057; Fri, 14 Mar 2008 17:38:07 +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 m2EGc6Ch016170; Fri, 14 Mar 2008 16:38:06 GMT Received: from [10.61.97.52] (dhcp-10-61-97-52.cisco.com [10.61.97.52]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2EGbwW06878; Fri, 14 Mar 2008 16:38:02 GMT Message-ID: <47DAA9FC.3000202@cisco.com> Date: Fri, 14 Mar 2008 16:38:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: "Joel M. Halpern" References: <47B61982.8040005@joelhalpern.com> In-Reply-To: <47B61982.8040005@joelhalpern.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12555; t=1205512687; x=1206376687; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20Gen-Art=20IETF=20LC=20review=3A=20draft -ietf-ipfix-testing-04.txt |Sender:=20; bh=rpuvXRzq5dc19SBgWlOxfwlGeWsc8h4rmKv/UXCgOxY=; b=VPkGL7Hln0sISRuiPeFIRcUj599nnsH0x/dpSICOed90I7GjGE++ZJlJ+Y EtYj93fjV4z0yhhwryteqs98RvKPZ2mTtXDGuFQNCuDCmLIydlWpU709vcHn ZrEiIw9r63; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Joel, Apologies for not responding sooner to your review, as it came right ahead of the -00 and -nn cutoffs. Please see some responses inline. > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: Guidelines for IP Flow Information eXport (IPFIX) Testing > Reviewer: Joel M. Halpern > Review Date: 15-Feb-2008 > IETF LC End Date: 26-Feb-2008 > IESG Telechat date: N/A > > Summary: This document needs some additional work before publication as > an informational RFC. > I would particularly recommend considering addressing at least the first > comment below prior to RFC publication. > I would also suggest that the test descriptions need some clarification > as described in the technical section below, particularly items 5 and 6. > > Comments: > > Conceptual: > 1) While the document is being published as an information RFC, the > wording of the abstract and introduction make it seem that this document > is actually defining conformance to the IPFIX RFCs. The IETF has > generally carefully steered clear of defining such conformance. > So, while publishing a useful test suite is probably a good idea, I > strongly recommend fixing the wording of at least the abstract and > introduction to make it quite clear that these are not mandatory tests, > and that these tests do not define conformance. Sure, the tests are not mandatory. However, if you were purchasing an IPFIX device which did not claim to be compliant with this draft, you might rightly ask why not when all the IPFIX implementations we know of to date have been. > Related to this, please do not assert (in section 3) that passing this > test suite constitutes conformance to the IPFIX architecture and > protocol. (Among other things,test suite passage proves nothing about > architectural conformance.) OK. > Technical: > 2) In the terminology section, an Observation Point is defined simply as > a place where packets can be observed. An Observation Domain is a > collection of Observation points. Then, in the middle of the definition > of an Observation domain it say "In the IPFIX MEssage it generates..." > but up till now none of the things that have been defined generate IPFIX > messages. It is possible that the "it" in the quote is supposed to be > the "Metering Process" mentioned in passing earlier in the definition. Correct, it is. > But the English grammar does not lead the reader to such a conclusion. > Later in that same definition, it beings to appear that an Observation > Domain (which is a collection of points, not a process or entity) is > supposed to generate IPFIX messages, since it is supposed to include a > Domain ID in the messages it generates. This definition for an > Observation Domain needs to be reworked, to avoid confusing the Domain > with the Measurement Process which is running in / for / on the Domain. The Metering Process generates flow records which the Exporting Process makes into IPFIX messages. This whole section is lifted directly from RFC5101, as stated right at the top of section 2: The terminology used in this document is fully aligned with the terminology specified in [RFC5101] which is reproduced here for reference. > 3) The use of capital "MUST" in section 3.1 is almost certainly wrong. > Firstly, what I think that section is saying is that being able to > correctly perform the basic tests is a precondition for being able to > perform further test successfully. Thats a precondition, not a "MUST". These are basic connectivity tests. If they don't pass then there's no point in proceeding with the later tests, since you don't even have a basic connection. So yes, these initial tests are a precondition for the later ones. In effect they MUST pass before proceeding. > Of lesser significance, this document does not provide any description > of what it means by "MUST". Right above the TOC, as ever: Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. > We are usually careful about how such > language is used in informational RFCs. I think the meaning would be > clearer if the real intent were stated. I suspect that some readers of > this review may find my concern here pedantic. But the continual use of > MUST in the document really, really bothers me. (I hope the next comment > helps explain why it bothers me so much.) > > 4) Then, the test descriptions go on to keep using this language. This > is a test suite description document. Simply state how to run the test. > There is no need for "MUST". Section 3 should indicate that the test > descriptions describe the preconditions and steps that the tester goes > through. So section 3.1 would begin "The tester creates one Exporting > Process and one collection process, configures the Exporting Process to > ..." The -00 version of this draft didn't use any RFC 2119 language. eg, section 3.1 began: Set up one Exporting and one Collecting Process. Configure the Exporting Process to send to the Collecting Process. However, we received feedback that RFC 2119 language should be used so a tester could clearly see what needed done, and could tick off compliance with each point as he worked through. Reworking the document like this is not an insignificant task. > 5) It is not clear what test steps like ~The tester ensures that an SCTP > association is established.~ (Or worse, the actual text which reads "the > test MUST ensure that an SCTP association is established." are supposed > to do. Is this an instruction to the tester to use network management > tools or CLI to verify a connection on both devices? Is it an > instruction to perform additional configuration? How does the tester > "ensure". That would very much depend on the implementation, don't you think? > A test suite should tell a tester what steps to undertake, > and what observations to perform. "Ensure" is not either one of those. Testing and verifying SCTP are quite beyond the scope of this draft. However, ability to bring up an SCTP association is a necessary prerequisite for the following tests. > 5a) To elaborate on this issue, in the middle of the test step about > ensuring that Data Records are actually exported, we finally get a > testable instruction, to whit, use a packet sniffer and check that the > packets are coming by. Sadly, that was only a suggestion of how the tester might perform this task. > 6) I believe I understand how a tester would create templates, for the > template test. But how is the tester to create data sets. Particularly > data sets with specific properties, such as the padding in section 3.2.3 > and 3.2.4? Again, that would very much depend upon the implementation being tested. Some implementations may add padding by default, or may have a switch to allow padding to be optional. It certainly wasn't an issue at our IPFIX interops. > The best conclusion I can come to is that this is a > collector test, and that it assumes a packet generator which can > generate IPFIX packets. That's a good option for testing the Collecting Process - though it wouldn't verify the Exporting Process. Another possiblity would be for the tester to inject known data into the Metering Process, either directly or by passing known traffic through the Observation Point(s). > Having such a device in a test setup makes > sense. But the test description does not say "configure a packet > generator to generate an IPFIX packet with ..." (There are other ways > to say this, but there needs to be some description of how testers are > expected to create data sets.) Again, this seems to be quite implementation dependent. I expect what you'd do for a PC based implementation would be quite different from what you'd for for a router based implementation. > 6a) Related to this, I find reading this document rather odd. I have > read many test suites for protocols and implementations of protocols. > They generally focus on a Device (or implementation, or entity) Under > Test, and the framing around that Device. This suite appears to be > trying to test two interacting devices simultaneously. That is > extremely difficult, and extremely confusing. The IPFIX protocol connects an Exporting Process (source) to a Collecting Process (destination). One is needed in order to test the other - or at the very least, something that does a good job of pretending to be an Exporter or Collector. eg, an Exporting Process won't export anything until it's able to bring up an SCTP association. So if you're going to inject packets (rather than have an Exporting Process) then you'll first need to do some SCTP negotiation. All in, it's most straightforward to connect an Exporter to a Collector. > It is particularly hard > because then the tester doesn't have enough points of control to perform > the tests and observe the results meaningfully. It is possible that > this combined suite is right for this problem. But if so, a lot of > explanation of why it is done that way and how the tester is to > accomplish his goals is needed. > > Minor: > 7) The abstract is worded as if one could not perform interoperability > testing without first running the tests in this document. While having > run the tests in this document will presumably increase the chances of a > successful interoperability test, they are not an inherent requirement > for such testing. We had three IPFIX interops, with this document being drafted after the first. I believe the pre-requisite for the second and third interops was that these basic tests had been run, so as to ensure a common baseline and rule out basic issues which had already been covered in previous interops. > 8) I would probably be inclined to lighten up the Motivation section a > bit. Or even remove it. I don't think we need to explain why test > suites are useful. If we really need a motivation section, then it > should explain something about why it is particularly complex to test > IPFIX implementations (if it is) and thus why the IETF feels it is > particularly useful to publish a test suite ourselves in this case. OK. > 9) The definition of Transport Session is actually the definition of > various kinds of transport sessions, and how they are identified. Could > the definition start with an actual definition please. (I.e. the > communication over time used to carry X between Y and Z? Or something.) Again, the definition is copied directly from RFC 5101. > 10) As an editorial matter, most testers I have worked with strongly > prefer if every step in a test is explicitly separate and named / > numbered. That way, they can check off each step as it goes. So the > beginning of 3.1.1 would be > i) Create One Exporting Process > ii) Create One Collection Process > iii) Configure the Exporting Process ... In effect, each of our MUSTs is such a check. At least, that was the intention. > 11) It is particularly odd to see a set of Stress/Load tests that > simultaneously claim to be measuring conformance and to not specify the > level of Stress / Load. Having a description of how to perform load > tests is useful. But its relationship to the other tests is confusing. > (This obviously is helped once we no longer claim that this is a > conformance test.) These tests verify what IPFIX devices do when overloaded, rather than testing that they're able to handle a certain load level. It's clearly impossible for us to state specific traffic levels since a) the overload level may vary enormously from device to device, and b) we're not interested in the specific level, but in the device's ability to handle extremes gracefully. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From nobody@cp.gomventshost.com Fri Mar 14 17:28:32 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCAF3A6ACD for ; Fri, 14 Mar 2008 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.532 X-Spam-Level: **** X-Spam-Status: No, score=4.532 tagged_above=-999 required=5 tests=[AV:HTML.Phishing.Auction-293=0.1, AWL=-0.034, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HEADER_CTYPE_ONLY=0.56, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, TVD_PH_SUBJ_META=0, URIBL_GREY=0.25, AV:HTML.Phishing.Auction-293=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ+gQN0w4u7l for ; Fri, 14 Mar 2008 17:28:32 -0700 (PDT) Received: from cp.gomventshost.com (mail.gomventshost.com [64.69.43.91]) by core3.amsl.com (Postfix) with ESMTP id D8A7E3A6A0B for ; Fri, 14 Mar 2008 17:28:32 -0700 (PDT) Received: from nobody by cp.gomventshost.com with local (Exim 4.63) (envelope-from ) id 1JaKDo-00089c-Tc for ipfix-archive@megatron.ietf.org; Fri, 14 Mar 2008 19:26:00 -0500 To: ipfix-archive@megatron.ietf.org Subject: Question from eBay Member From: member@ebay.com Content-Type: text/html; Message-Id: Date: Fri, 14 Mar 2008 19:26:00 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.gomventshost.com X-AntiAbuse: Original Domain - megatron.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - cp.gomventshost.com
eBay New Unpaid Item Message from gbgb004: #120070947123 -- response required


Dear eBay member,

eBay member gbgb004 has left you a message regarding item #120070947123.

View the dispute thread to respond.

Regards,

Customer Support (Trust aand Safety Department)
eBay International AG

 

Copyright  2006 eBay, Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc.

From ipfix-bounces@ietf.org Sat Mar 15 08:55:56 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750C028C2DD; Sat, 15 Mar 2008 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.283 X-Spam-Level: X-Spam-Status: No, score=-101.283 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psZxMf1hVUWy; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAC828C29B; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F9228C1B7 for ; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr24hALBJWDC for ; Sat, 15 Mar 2008 08:55:52 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 8452028C2DC for ; Sat, 15 Mar 2008 08:55:51 -0700 (PDT) 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 m2FFrSXJ028775 for ; Sat, 15 Mar 2008 11:53:28 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2FFpuk0028685 for ; Sat, 15 Mar 2008 11:51:56 -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 m2FFptTl028680; Sat, 15 Mar 2008 11:51:56 -0400 (EDT) Received: from [192.168.1.134] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2FFpseE004788; Sat, 15 Mar 2008 11:51:54 -0400 Message-Id: From: Brian Trammell To: Benoit Claise In-Reply-To: <47D5F8D7.2070103@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 15 Mar 2008 11:51:53 -0400 References: <47D5F8D7.2070103@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Arno Wagner , ipfix@ietf.org, Lutz Mark , Elisa Boschi Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1281240767==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============1281240767== Content-Type: multipart/alternative; boundary=Apple-Mail-3--344152605 --Apple-Mail-3--344152605 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Benoit, Thanks for the comments! Replies and, where appropriate, a summary of our 8am Friday meeting, inline. On Mar 10, 2008, at 11:13 PM, Benoit Claise wrote: > - during the last IETF meeting, I mentioned that it wouldFrom ipfix-bounces@ietf.org Sat Mar 15 08:55:56 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750C028C2DD; Sat, 15 Mar 2008 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.283 X-Spam-Level: X-Spam-Status: No, score=-101.283 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psZxMf1hVUWy; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAC828C29B; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F9228C1B7 for ; Sat, 15 Mar 2008 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr24hALBJWDC for ; Sat, 15 Mar 2008 08:55:52 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 8452028C2DC for ; Sat, 15 Mar 2008 08:55:51 -0700 (PDT) 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 m2FFrSXJ028775 for ; Sat, 15 Mar 2008 11:53:28 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2FFpuk0028685 for ; Sat, 15 Mar 2008 11:51:56 -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 m2FFptTl028680; Sat, 15 Mar 2008 11:51:56 -0400 (EDT) Received: from [192.168.1.134] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2FFpseE004788; Sat, 15 Mar 2008 11:51:54 -0400 Message-Id: From: Brian Trammell To: Benoit Claise In-Reply-To: <47D5F8D7.2070103@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 15 Mar 2008 11:51:53 -0400 References: <47D5F8D7.2070103@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Arno Wagner , ipfix@ietf.org, Lutz Mark , Elisa Boschi Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1281240767==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============1281240767== Content-Type: multipart/alternative; boundary=Apple-Mail-3--344152605 --Apple-Mail-3--344152605 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Benoit, Thanks for the comments! Replies and, where appropriate, a summary of our 8am Friday meeting, inline. On Mar 10, 2008, at 11:13 PM, Benoit Claise wrote: > - during the last IETF meeting, I mentioned that it would be nice to > have a delimiter, in order to get some diagnostics information. > Note: my (biased) view is the one from a router vendor, so I'm > thinking about router diagnostics. You mention "IPFIX files contain > only IPFIX messages". I would like to remove that restriction. There are two problems to address here, and since addressing them separately will not cause any interoperability problems, I think we should make an attempt to address both: 1. Embedding non-IPFIX information in an IPFIX message stream. The opaqueOctets IE as described in revision -01 addresses this, with the inherent limitations of the IPFIX message format itself (mainly, a maximum opaque chunk length of 65515 bytes, or 65513 for variable- length encoding). 2. Embedding an IPFIX file within a non-IPFIX file. On first glance, this seemed out of scope (which is why we proposed the opaqueOctets mechanism to address your comments in Vancouver) -- any process wanting to write a data stream embedding an IPFIX file could define its own external framing. Also, the simplest way to do this (end delimiter only; basically, a specification that File Readers MUST stop reading a file and assume no error if the first four bytes of the next message are not a valid IPFIX Version number; per 5101, 0x000A) conflicts with the compression and encryption error recovery strategies for long-term storage. However, the application you're trying to support here -- router diagnostics -- doesn't have compression or encryption error recovery as requirements, so there's no conflict; and opaqueOctets framing is a bit of a heavyweight thing to expect a router to handle during debugging or crash reporting. So, as per Friday, we'll attempt to come up with 1. a delimiter mechanism that's a bit less brittle than the simplest one and 2. language handling the conflict between this use case and compressed archival storage for -02. > You inserted the opaqueOctets. This is nice, but heavy compared to a > file delimiter > - I would like to have a few words about writing into a file > directly from a router, for example in section 6.4 Section 6 needs a bit of expansion, I think; the file format now has a set of mechanisms to meet each of the addressed requirements; however, there are not specific use-case guidelines for combining these requirements (and the associated mechanisms) for each area of applicability. Router (or IPFIX device) diagnostics is one we need to address; perhaps we should also address the file-based workflow issue we mention in the frontmatter, too... > - I think that you would benefit from the per-SCTP stream, as the > order is maintained. It might be worth stressing that, if the per- > SCTP stream is implemented, we would not have the timing issue > related to data records sent to multiple SCTP stream. Since each file is its own stream, the only way to implement per- stream storage for files is one file per stream. We'll add the required language. > - While I understand that you would like to have the Template(s) at > the beginning of the file, it will require huge buffers on a > router... unless the per-SCTP stream is supported. That's another > advantage of that draft. We probably need to give up recommending a single Template management strategy for every use case; we should expand template management specifications and guidelines in parallel with the applicability. > - how do we treat SCTP assocation and TCP connection reset? the file > must be ended? Not defined; nor am I sure it should be. There's a bit of a disconnect here. This draft addresses Files as first-class, as opposed to File Writers and Readers. We then added some language to clarify things for people building File Writers that happen to be pulling data directly from a Collecting Process; that's one use case... However, there has been it seems a _lot_ of confusion created by this choice. It seems like people are _expecting_ that the _only_ application for the format is to write collected IPFI be nice to > have a delimiter, in order to get some diagnostics information. > Note: my (biased) view is the one from a router vendor, so I'm > thinking about router diagnostics. You mention "IPFIX files contain > only IPFIX messages". I would like to remove that restriction. There are two problems to address here, and since addressing them separately will not cause any interoperability problems, I think we should make an attempt to address both: 1. Embedding non-IPFIX information in an IPFIX message stream. The opaqueOctets IE as described in revision -01 addresses this, with the inherent limitations of the IPFIX message format itself (mainly, a maximum opaque chunk length of 65515 bytes, or 65513 for variable- length encoding). 2. Embedding an IPFIX file within a non-IPFIX file. On first glance, this seemed out of scope (which is why we proposed the opaqueOctets mechanism to address your comments in Vancouver) -- any process wanting to write a data stream embedding an IPFIX file could define its own external framing. Also, the simplest way to do this (end delimiter only; basically, a specification that File Readers MUST stop reading a file and assume no error if the first four bytes of the next message are not a valid IPFIX Version number; per 5101, 0x000A) conflicts with the compression and encryption error recovery strategies for long-term storage. However, the application you're trying to support here -- router diagnostics -- doesn't have compression or encryption error recovery as requirements, so there's no conflict; and opaqueOctets framing is a bit of a heavyweight thing to expect a router to handle during debugging or crash reporting. So, as per Friday, we'll attempt to come up with 1. a delimiter mechanism that's a bit less brittle than the simplest one and 2. language handling the conflict between this use case and compressed archival storage for -02. > You inserted the opaqueOctets. This is nice, but heavy compared to a > file delimiter > - I would like to have a few words about writing into a file > directly from a router, for example in section 6.4 Section 6 needs a bit of expansion, I think; the file format now has a set of mechanisms to meet each of the addressed requirements; however, there are not specific use-case guidelines for combining these requirements (and the associated mechanisms) for each area of applicability. Router (or IPFIX device) diagnostics is one we need to address; perhaps we should also address the file-based workflow issue we mention in the frontmatter, too... > - I think that you would benefit from the per-SCTP stream, as the > order is maintained. It might be worth stressing that, if the per- > SCTP stream is implemented, we would not have the timing issue > related to data records sent to multiple SCTP stream. Since each file is its own stream, the only way to implement per- stream storage for files is one file per stream. We'll add the required language. > - While I understand that you would like to have the Template(s) at > the beginning of the file, it will require huge buffers on a > router... unless the per-SCTP stream is supported. That's another > advantage of that draft. We probably need to give up recommending a single Template management strategy for every use case; we should expand template management specifications and guidelines in parallel with the applicability. > - how do we treat SCTP assocation and TCP connection reset? the file > must be ended? Not defined; nor am I sure it should be. There's a bit of a disconnect here. This draft addresses Files as first-class, as opposed to File Writers and Readers. We then added some language to clarify things for people building File Writers that happen to be pulling data directly from a Collecting Process; that's one use case... However, there has been it seems a _lot_ of confusion created by this choice. It seems like people are _expecting_ that the _only_ application for the format is to write collected IPFIX data, and that this is the Writing Files from IPFIX Collectors draft. Perhaps we should expand the IPFIX Collection applicability section, to provide more detailed specifications for this specific case. > - informationElementAnonymized was in the previous version, but not > anymore in this draft. I see "The data described by this Template > contains anonymized source and destination IPv4 addresses.". How is > it possible without this I.E.? Btw, we should have an anomized I.E., > similar to the key IE. Yep. Typo. Will fix. > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, > why not have a "scope" IE with some values in there. Like in RFC3954: > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template (See the other thread, but...) Per our conversation Friday, we realized that doing things this way essentially uses IPFIX options to implement ever-so-slightly more flexible V9 options, which is not what we want. All architecture components can _already_ be scoped by emitting Options scoped to the given architecture component, explicitly identified. Transport Sessions and Messages are _not_ yet explicitly identifiable, and making them so is out of scope for the file draft. It's also not clear that we understand all the implications of making these explicitly identifiable OTHER than to refer to "this message" or "this session". So, while sessionScope and messageScope are perhaps not the most elegant or extensible way do to what they do, doing something else is perhaps less elegant, and I'm reasonably convinced we don't need to create any more than these other two. I'd recommend leaving them as they are. > - 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, > minExportSeconds, maxExportSeconds? Why not any of the time related > I.E.? Not to duplicate the I.Es? Basically, yes; the idea is that when you're using the first two IEs to attach time windows to files, second resolution is sufficient, and there's no need to get more precise than that. This may be an overly restrictive assumption. The export time window information, however, is explicitly in seconds, because it describes the IPFIX Export Time, which is also in seconds. > Some editorial feedback We've not yet made the following changes; we'll have to review them before editing -02: > - IPFIX file reader and writer: instead of "analogous to", what > about a "special case of" > - I don't understand what you mean in > "The IPFIX Message format has no direct support for indexing. > However, its template mechanism and the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the > contents of a file in a limited way." > - message -> IPFIX Message (a few instances) > - acronyms RAID, CBC The following are already changed in my -02 working copy: > - in Section 6.2, you have "MAY". This is a specification while this > is the applicability section. > - IPFIX Transport -> IPFIX transport > - "options record" is not a valid term according to RFC5101 > - As testing is certainly not the primary use, I would order the > section 6.x in this order > 6.1 storage of ipfix-collected flow data > 6.2 testing IPFIX collecting process > - section 5.1 is "record format flexibility" and you speak about > "extensibility" Other comments: > - section 3, why do you repeat the definition of the IPFIX file... > just after the section 2 "terminology" btw As an introduction to the design overview, for people who skip straight to the overview to see what this document is all about. (Also, that sentence used to be far lower in the document, where it seemed less repetitive. So I'll X data, and that this is the Writing Files from IPFIX Collectors draft. Perhaps we should expand the IPFIX Collection applicability section, to provide more detailed specifications for this specific case. > - informationElementAnonymized was in the previous version, but not > anymore in this draft. I see "The data described by this Template > contains anonymized source and destination IPv4 addresses.". How is > it possible without this I.E.? Btw, we should have an anomized I.E., > similar to the key IE. Yep. Typo. Will fix. > - messageScope, sessionScope, etc...: instead of multiplying the > information elements "...Scope", for which the content is ignored, > why not have a "scope" IE with some values in there. Like in RFC3954: > Scope 1 Field Type > The relevant portion of the Exporter/NetFlow process to which > the Options Template Record refers. > Currently defined values are: > 1 System > 2 Interface > 3 Line Card > 4 Cache > 5 Template (See the other thread, but...) Per our conversation Friday, we realized that doing things this way essentially uses IPFIX options to implement ever-so-slightly more flexible V9 options, which is not what we want. All architecture components can _already_ be scoped by emitting Options scoped to the given architecture component, explicitly identified. Transport Sessions and Messages are _not_ yet explicitly identifiable, and making them so is out of scope for the file draft. It's also not clear that we understand all the implications of making these explicitly identifiable OTHER than to refer to "this message" or "this session". So, while sessionScope and messageScope are perhaps not the most elegant or extensible way do to what they do, doing something else is perhaps less elegant, and I'm reasonably convinced we don't need to create any more than these other two. I'd recommend leaving them as they are. > - 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, > minExportSeconds, maxExportSeconds? Why not any of the time related > I.E.? Not to duplicate the I.Es? Basically, yes; the idea is that when you're using the first two IEs to attach time windows to files, second resolution is sufficient, and there's no need to get more precise than that. This may be an overly restrictive assumption. The export time window information, however, is explicitly in seconds, because it describes the IPFIX Export Time, which is also in seconds. > Some editorial feedback We've not yet made the following changes; we'll have to review them before editing -02: > - IPFIX file reader and writer: instead of "analogous to", what > about a "special case of" > - I don't understand what you mean in > "The IPFIX Message format has no direct support for indexing. > However, its template mechanism and the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the > contents of a file in a limited way." > - message -> IPFIX Message (a few instances) > - acronyms RAID, CBC The following are already changed in my -02 working copy: > - in Section 6.2, you have "MAY". This is a specification while this > is the applicability section. > - IPFIX Transport -> IPFIX transport > - "options record" is not a valid term according to RFC5101 > - As testing is certainly not the primary use, I would order the > section 6.x in this order > 6.1 storage of ipfix-collected flow data > 6.2 testing IPFIX collecting process > - section 5.1 is "record format flexibility" and you speak about > "extensibility" Other comments: > - section 3, why do you repeat the definition of the IPFIX file... > just after the section 2 "terminology" btw As an introduction to the design overview, for people who skip straight to the overview to see what this document is all about. (Also, that sentence used to be far lower in the document, where it seemed less repetitive. So I'll look into whether a change makes sense...) > - a couple of terms from RFC5101 are not capitalized. For example, > "flow" We reviewed these, as I recall, and I think we left all the lowercase "flows" there on purpose, as they were adjectives in generic phrases (i.e. flow analysis...) > - you mentioned a few times "flow data". Why not Flow Record? unless > you want to be generic? Usually, because we want to be generic. I'll review these again... > - I'm not sure 6.3 "storage of NetFlow version 9-collected flow > data" is an applicability of this draft. As we discussed in Philadelphia, will leave in. > - that would be good to explicitely show that the IPFIX header is > included. For example, in figure 1 indeed. will also add ipfix message headers where they belong in the example... That should about cover it. Thanks again! - Brian --Apple-Mail-3--344152605 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Benoit,

Thanks for the comments! = Replies and, where appropriate, a summary of our 8am Friday meeting, = inline.

On Mar 10, 2008, at 11:13 PM, = Benoit Claise wrote:

- during the last IETF meeting, I = mentioned that it would be nice to have a delimiter, in order to get = some diagnostics information. Note: my (biased) view is the one from a = router vendor, so I'm thinking about router diagnostics. You mention = "IPFIX files contain only IPFIX messages". I would like to remove that = restriction.

There are two = problems to address here, and since addressing them separately will not = cause any interoperability problems, I think we should make an attempt = to address both:

1. Embedding non-IPFIX = information in an IPFIX message stream. The opaqueOctets IE as described = in revision -01 addresses this, with the inherent limitations of the = IPFIX message format itself (mainly, a maximum opaque chunk length of = 65515 bytes, or 65513 for variable-length encoding).

2. Embedding an IPFIX file = within a non-IPFIX file. On first glance, this seemed out of scope = (which is why we proposed the opaqueOctets mechanism to address your = comments in Vancouver) -- any process wanting to write a data stream = embedding an IPFIX file could define its own external framing. Also, the = simplest way to do this (end delimiter only; basically, a specification = that File Readers MUST stop reading a file and assume no error if the = first four bytes of the next message are not a valid IPFIX Version = number; per 5101, 0x000A) conflicts with the compression and encryption = error recovery strategies for long-term storage.

However, the application = you're trying to support here -- router diagnostics -- doesn't have = compression or encryption error recovery as requirements, so there's no = conflict; and opaqueOctets framing is a bit of a heavyweight thing to = expect a router to handle during debugging or crash = reporting.

So,= as per Friday, we'll attempt to come up with 1. a delimiter mechanism = that's a bit less brittle than the simplest one and 2. language handling = the conflict between this use case and compressed archival storage for = -02.

You inserted the = opaqueOctets. This is nice, but heavy compared to a file delimiter
- = I would like to have a few words about writing into a file directly from = a router, for example in section = 6.4

Sectlook into whether a change makes sense...) > - a couple of terms from RFC5101 are not capitalized. For example, > "flow" We reviewed these, as I recall, and I think we left all the lowercase "flows" there on purpose, as they were adjectives in generic phrases (i.e. flow analysis...) > - you mentioned a few times "flow data". Why not Flow Record? unless > you want to be generic? Usually, because we want to be generic. I'll review these again... > - I'm not sure 6.3 "storage of NetFlow version 9-collected flow > data" is an applicability of this draft. As we discussed in Philadelphia, will leave in. > - that would be good to explicitely show that the IPFIX header is > included. For example, in figure 1 indeed. will also add ipfix message headers where they belong in the example... That should about cover it. Thanks again! - Brian --Apple-Mail-3--344152605 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Benoit,

Thanks for the comments! = Replies and, where appropriate, a summary of our 8am Friday meeting, = inline.

On Mar 10, 2008, at 11:13 PM, = Benoit Claise wrote:

- during the last IETF meeting, I = mentioned that it would be nice to have a delimiter, in order to get = some diagnostics information. Note: my (biased) view is the one from a = router vendor, so I'm thinking about router diagnostics. You mention = "IPFIX files contain only IPFIX messages". I would like to remove that = restriction.

There are two = problems to address here, and since addressing them separately will not = cause any interoperability problems, I think we should make an attempt = to address both:

1. Embedding non-IPFIX = information in an IPFIX message stream. The opaqueOctets IE as described = in revision -01 addresses this, with the inherent limitations of the = IPFIX message format itself (mainly, a maximum opaque chunk length of = 65515 bytes, or 65513 for variable-length encoding).

2. Embedding an IPFIX file = within a non-IPFIX file. On first glance, this seemed out of scope = (which is why we proposed the opaqueOctets mechanism to address your = comments in Vancouver) -- any process wanting to write a data stream = embedding an IPFIX file could define its own external framing. Also, the = simplest way to do this (end delimiter only; basically, a specification = that File Readers MUST stop reading a file and assume no error if the = first four bytes of the next message are not a valid IPFIX Version = number; per 5101, 0x000A) conflicts with the compression and encryption = error recovery strategies for long-term storage.

However, the application = you're trying to support here -- router diagnostics -- doesn't have = compression or encryption error recovery as requirements, so there's no = conflict; and opaqueOctets framing is a bit of a heavyweight thing to = expect a router to handle during debugging or crash = reporting.

So,= as per Friday, we'll attempt to come up with 1. a delimiter mechanism = that's a bit less brittle than the simplest one and 2. language handling = the conflict between this use case and compressed archival storage for = -02.

You inserted the = opaqueOctets. This is nice, but heavy compared to a file delimiter
- = I would like to have a few words about writing into a file directly from = a router, for example in section = 6.4

Section 6 needs a bit of = expansion, I think; the file format now has a set of mechanisms to meet = each of the addressed requirements; however, there are not specific = use-case guidelines for combining these requirements (and the associated = mechanisms) for each area of applicability. Router (or IPFIX device) = diagnostics is one we need to address; perhaps we should also address = the file-based workflow issue we mention in the frontmatter, = too...

- I think that = you would benefit from the per-SCTP stream, as the order is maintained. = It might be worth stressing that, if the per-SCTP stream is implemented, = we would not have the timing issue related to data records sent to = multiple SCTP stream.

Since each = file is its own stream, the only way to implement per-stream storage for = files is one file per stream. We'll add the required = language.

- While I understand that you would like to have the = Template(s) at the beginning of the file, it will require huge buffers = on a router... unless the per-SCTP stream is supported. That's another = advantage of that draft.

We probably need to give = up recommending a single Template management strategy for every use = case; we should expand template management specifications and guidelines = in parallel with the applicability.

- how do we treat SCTP assocation = and TCP connection reset? the file must be = ended?

Not defined; nor am I sure it = should be. There's a bit of a disconnect here. This draft addresses = Files as first-class, as opposed to File Writers and Readers. We then = added some language to clarify things for people building File Writers = that happen to be pulling data directly from a Collecting Process; = that's one use case...

However, there has been it = seems a _lot_ of confusion created by this choice. It seems like people = are _expecting_ that the _only_ application for the format is to write = collected IPFIX data, and that this is the Writing Files from IPFIX = Collectors draft.

Perhaps we should expand = the IPFIX Collection applicability section, to provide more detailed = specifications for this specific case.

- = informationElementAnonymized was in the previous version, but not = anymore in this draft. I see "The data described by this Template = contains anonymized source and destination IPv4 addresses.". How is it = possible without this I.E.? Btw, we should have an anomized I.E., = similar to the key IE.

Yep. Typo. Will = fix.

- messageScope, sessionScope, etc...: instead of = multiplying the information elements "...Scope", for which the content = is ignored, why not have a "scope" IE with some values in there. Like in = RFC3954:
 Scope 1 Field Type
         The relevant portion of the Exporter/NetFlow process to which
         the Options Template Record refers.
         Currently defined values are:
            1 System
            2 Interface
            3 Line Card
            4 Cache
            5 Template
(See the other = thread, but...)

Per our conversation = Friday, we realized that doing things this way essentially uses IPFIX = options to implement ever-so-slightly more flexiion 6 needs a bit of = expansion, I think; the file format now has a set of mechanisms to meet = each of the addressed requirements; however, there are not specific = use-case guidelines for combining these requirements (and the associated = mechanisms) for each area of applicability. Router (or IPFIX device) = diagnostics is one we need to address; perhaps we should also address = the file-based workflow issue we mention in the frontmatter, = too...

- I think that = you would benefit from the per-SCTP stream, as the order is maintained. = It might be worth stressing that, if the per-SCTP stream is implemented, = we would not have the timing issue related to data records sent to = multiple SCTP stream.

Since each = file is its own stream, the only way to implement per-stream storage for = files is one file per stream. We'll add the required = language.

- While I understand that you would like to have the = Template(s) at the beginning of the file, it will require huge buffers = on a router... unless the per-SCTP stream is supported. That's another = advantage of that draft.

We probably need to give = up recommending a single Template management strategy for every use = case; we should expand template management specifications and guidelines = in parallel with the applicability.

- how do we treat SCTP assocation = and TCP connection reset? the file must be = ended?

Not defined; nor am I sure it = should be. There's a bit of a disconnect here. This draft addresses = Files as first-class, as opposed to File Writers and Readers. We then = added some language to clarify things for people building File Writers = that happen to be pulling data directly from a Collecting Process; = that's one use case...

However, there has been it = seems a _lot_ of confusion created by this choice. It seems like people = are _expecting_ that the _only_ application for the format is to write = collected IPFIX data, and that this is the Writing Files from IPFIX = Collectors draft.

Perhaps we should expand = the IPFIX Collection applicability section, to provide more detailed = specifications for this specific case.

- = informationElementAnonymized was in the previous version, but not = anymore in this draft. I see "The data described by this Template = contains anonymized source and destination IPv4 addresses.". How is it = possible without this I.E.? Btw, we should have an anomized I.E., = similar to the key IE.

Yep. Typo. Will = fix.

- messageScope, sessionScope, etc...: instead of = multiplying the information elements "...Scope", for which the content = is ignored, why not have a "scope" IE with some values in there. Like in = RFC3954:
 Scope 1 Field Type
         The relevant portion of the Exporter/NetFlow process to which
         the Options Template Record refers.
         Currently defined values are:
            1 System
            2 Interface
            3 Line Card
            4 Cache
            5 Template
(See the other = thread, but...)

Per our conversation = Friday, we realized that doing things this way essentially uses IPFIX = options to implement ever-so-slightly more flexible V9 options, which is = not what we want. All architecture components can _already_ be scoped by = emitting Options scoped to the given architecture component, explicitly = identified. 

Transport Sessions and = Messages are _not_ yet explicitly identifiable, and making them so is = out of scope for the file draft. It's also not clear that we understand = all the implications of making these explicitly identifiable OTHER than = to refer to "this message" or "this session".

So, while sessionScope and = messageScope are perhaps not the most elegant or extensible way do to = what they do, doing something else is perhaps less elegant, and I'm = reasonably convinced we don't need to create any more than these other = two. I'd recommend leaving them as they are.

- 7.1.2 and 7.1.3. Why = minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, = maxExportSeconds? Why not any of the time related I.E.? Not to duplicate = the I.Es?

Basically, yes; the idea = is that when you're using the first two IEs to attach time windows to = files, second resolution is sufficient, and there's no need to get more = precise than that. This may be an overly restrictive = assumption. The export time window information, however, is = explicitly in seconds, because it describes the IPFIX Export Time, which = is also in seconds.

Some editorial = feedback

We've not yet made the = following changes; we'll have to review them before editing = -02:

- IPFIX file = reader and writer: instead of "analogous to", what about a "special case = of"
- I don't understand what you mean = in
      "The IPFIX Message format has no = direct support for indexing.
However, its template mechanism and the = technique described in
"Reducing Redundancy in IPFIX and PSAMP = Reports"
[I-D.ietf-ipfix-reducing-redundancy] can be used to describe = the
contents of a file in a limited way."
- message -> IPFIX Message (a few = instances)
- = acronyms RAID, CBC

The following are already changed in my -02 working = copy:

- in Section 6.2, you have "MAY". = This is a specification while this is the applicability = section.
- IPFIX Transport -> IPFIX = transport
- "options record" is not a valid = term according to RFC5101

Transport Sessions and = Messages are _not_ yet explicitly identifiable, and making them so is = out of scope for the file draft. It's also not clear that we understand = all the implications of making these explicitly identifiable OTHER than = to refer to "this message" or "this session".

So, while sessionScope and = messageScope are perhaps not the most elegant or extensible way do to = what they do, doing something else is perhaps less elegant, and I'm = reasonably convinced we don't need to create any more than these other = two. I'd recommend leaving them as they are.

- 7.1.2 and 7.1.3. Why = minFlowStartSeconds, maxFlowStartSeconds, minExportSeconds, = maxExportSeconds? Why not any of the time related I.E.? Not to duplicate = the I.Es?

Basically, yes; the idea = is that when you're using the first two IEs to attach time windows to = files, second resolution is sufficient, and there's no need to get more = precise than that. This may be an overly restrictive = assumption. The export time window information, however, is = explicitly in seconds, because it describes the IPFIX Export Time, which = is also in seconds.

Some editorial = feedback

We've not yet made the = following changes; we'll have to review them before editing = -02:

- IPFIX file = reader and writer: instead of "analogous to", what about a "special case = of"
- I don't understand what you mean = in
      "The IPFIX Message format has no = direct support for indexing.
However, its template mechanism and the = technique described in
"Reducing Redundancy in IPFIX and PSAMP = Reports"
[I-D.ietf-ipfix-reducing-redundancy] can be used to describe = the
contents of a file in a limited way."
- message -> IPFIX Message (a few = instances)
- = acronyms RAID, CBC

The following are already changed in my -02 working = copy:

- in Section 6.2, you have "MAY". = This is a specification while this is the applicability = section.
- IPFIX Transport -> IPFIX = transport
- "options record" is not a valid = term according to RFC5101
- As testing is = certainly not the primary use, I would order the section 6.x in this = order
     6.1 storage of ipfix-collected flow = data
     6.2 testing IPFIX collecting = process
- section 5.1 is "record format flexibility" and = you speak about "extensibility"

Other = comments:

- section 3, why do you repeat the = definition of the IPFIX file... just after the section 2 "terminology" = btw

As an introduction to the = design overview, for people who skip straight to the overview to see = what this document is all about.

(Also, that sentence used = to be far lower in the document, where it seemed less repetitive. So = I'll look into whether a change makes sense...)

- a couple of = terms from RFC5101 are not capitalized. For example, = "flow"

We reviewed these, as I = recall, and I think we left all the lowercase "flows" there on purpose, = as they were adjectives in generic phrases (i.e. flow = analysis...)

- you mentioned a few times "flow data". Why not Flow = Record? unless you want to be generic?

Usually, because we want = to be generic. I'll review these again...

- I'm not sure = 6.3 "storage of NetFlow version 9-collected flow data" is an = applicability of this draft.

As we discussed in = Philadelphia, will leave in.

- that would be good to explicitely = show that the IPFIX header is included. For example, in figure = 1

indeed. will also add = ipfix message headers where they belong in the = example...

That should about cover it. Thanks = again!

- = Brian

= --Apple-Mail-3--344152605-- --===============1281240767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1281240767==-- 3D"cite">
- As testing is = certainly not the primary use, I would order the section 6.x in this = order
     6.1 storage of ipfix-collected flow = data
     6.2 testing IPFIX collecting = process
- section 5.1 is "record format flexibility" and = you speak about "extensibility"

Other = comments:

- section 3, why do you repeat the = definition of the IPFIX file... just after the section 2 "terminology" = btw

As an introduction to the = design overview, for people who skip straight to the overview to see = what this document is all about.

(Also, that sentence used = to be far lower in the document, where it seemed less repetitive. So = I'll look into whether a change makes sense...)

- a couple of = terms from RFC5101 are not capitalized. For example, = "flow"

We reviewed these, as I = recall, and I think we left all the lowercase "flows" there on purpose, = as they were adjectives in generic phrases (i.e. flow = analysis...)

- you mentioned a few times "flow data". Why not Flow = Record? unless you want to be generic?

Usually, because we want = to be generic. I'll review these again...

- I'm not sure = 6.3 "storage of NetFlow version 9-collected flow data" is an = applicability of this draft.

As we discussed in = Philadelphia, will leave in.

- that would be good to explicitely = show that the IPFIX header is included. For example, in figure = 1

indeed. will also add = ipfix message headers where they belong in the = example...

That should about cover it. Thanks = again!

- = Brian

= --Apple-Mail-3--344152605-- --===============1281240767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1281240767==-- From facfoxylovecej@foxylove.net Sun Mar 16 04:17:11 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D210928C20F; Sun, 16 Mar 2008 04:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.536 X-Spam-Level: **** X-Spam-Status: No, score=4.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, INVALID_DATE=1.245, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOXlogyrrozO; Sun, 16 Mar 2008 04:17:11 -0700 (PDT) Received: from [195.128.252.106] (unknown [195.138.193.172]) by core3.amsl.com (Postfix) with ESMTP id AE18F28C321; Sun, 16 Mar 2008 04:17:05 -0700 (PDT) Received: from [195.128.252.106] by mail.foxylove.net; , 16 Mar 2008 13:14:49 +0200 Date: , 16 Mar 2008 13:14:49 +0200 From: "Fernando Mills" X-Mailer: The Bat! (v2.00.6) Personal Reply-To: facfoxylovecej@foxylove.net X-Priority: 3 (Normal) Message-ID: <710921366.41301819111540@foxylove.net> To: agentx-archive@lists.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D31FB25018FB2CD" ------------D31FB25018FB2CD Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Looking for the better pricein software discounts? Now you'll catch the opportunity to use the software equipment you want from long time. And the best thing for you is, all softs are awfully cheap. Check up by yourself and take the softwares for lowest rates ever seen! http://maryannlingardpp592.blogspot.com ------------D31FB25018FB2CD Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit
Looking for the better pricein software discounts?
Now you'll catch the opportunity to use the software equipment you want from long time.
And the best thing for you is, all softs are awfully cheap.
Check up by yourself and take the softwares for lowest rates ever seen!
http://maryannlingardpp592.blogspot.com ------------D31FB25018FB2CD-- From ipfix-bounces@ietf.org Sun Mar 16 10:12:35 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7D828C32B; Sun, 16 Mar 2008 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.571 X-Spam-Level: X-Spam-Status: No, score=-95.571 tagged_above=-999 required=5 tests=[AWL=1.666, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_64=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THtnKutKPHR8; Sun, 16 Mar 2008 10:12:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D50128C1B0; Sun, 16 Mar 2008 10:12:33 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA293A694A; Sat, 15 Mar 2008 17:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FapcHd2IbcQB; Sat, 15 Mar 2008 17:32:29 -0700 (PDT) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 644033A67F1; Sat, 15 Mar 2008 17:32:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id ABA1C7DD6; Sat, 15 Mar 2008 17:30:13 -0700 (PDT) Received: from [10.10.10.101] (pool-71-161-50-201.clppva.east.verizon.net [71.161.50.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id BB0B27DD8; Sat, 15 Mar 2008 17:30:09 -0700 (PDT) Message-ID: <47DC6A11.7010603@joelhalpern.com> Date: Sat, 15 Mar 2008 20:30:09 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47B61982.8040005@joelhalpern.com> <47DAA9FC.3000202@cisco.com> In-Reply-To: <47DAA9FC.3000202@cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Mailman-Approved-At: Sun, 16 Mar 2008 10:12:32 -0700 Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org I think I understand your answers, but I have to disagree with several of the concepts. First, to be clear, the idea of a document which spells out the things that various IPFix components need to be able to do in order to work well is a good idea. Firstly, I am sorry you were told to use 2119 language in describing your tests. As far as I can tell, the usage is wrong in two regards. It does not match the normal meaning of MUST for 2119, and it is confusing to the document reader. For example, if the document said explicitly, "The first set of tests are basic connectivity tests. It is not useful to proceed to more complex tests if these can not be passed." You would have gotten the point across without any MUST language. Note that if someone builds a test device, it should not attempt to enforce that sort of must, since users often perform tests in different orders for their own reasons. When you talk about the tests being a pre-requisite for interoperability, what you have got is that the basic tests are a good way to start interoperability testing. The tests are not actually a precondition for interoperability (although interoperable implementations will presumably pass the tests.) In the IETF, tests are not a precondition. They are useful information. (I have had to cope with the opposite. It does not work.) Secondly, after reading many of your responses about there being multiple ways to perform the various tests, and some cases where you can not specify how they would be performed, I am left with a semantic disconnect. The document is not a test suite. It is a description of things to test for. If that is your goal, it could be re-written to get at that point. As written, it is somewhere in between, and quite confusing. (And yes, I have been reviewing test suites of one sort or another for a VERY long time as it happens.) I listened to a nice description from a person from the BenchMark WorkingGroup (BMWG), which has been doing lots of testing definition at the IETF. If what you want is a test suite, I would suggest talking to them about how to approach it. They focus on concepts like having a single unit being tested for any test, etc. Also, with regard to the definitions, I am not going to second guess the underlying RFC. But as used here I sure found some of them confusing. (Particularly the distinction between a transport session and the identifying characteristics of a transport session.) Yours, Joel M. Halpern Paul Aitken wrote: > Joel, > > Apologies for not responding sooner to your review, as it came right > ahead of the -00 and -nn cutoffs. > > Please see some responses inline. > > >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: Guidelines for IP Flow Information eXport (IPFIX) Testing >> Reviewer: Joel M. Halpern >> Review Date: 15-Feb-2008 >> IETF LC End Date: 26-Feb-2008 >> IESG Telechat date: N/A >> >> Summary: This document needs some additional work before publication >> as an informational RFC. >> I would particularly recommend considering addressing at least the >> first comment below prior to RFC publication. >> I would also suggest that the test descriptions need some >> clarification as described in the technical section below, >> particularly items 5 and 6. >> >> Comments: >> >> Conceptual: >> 1) While the document is being published as an information RFC, the >> wording of the abstract and introduction make it seem that this >> document is actually defining conformance to the IPFIX RFCs. The IETF >> has generally carefully steered clear of defining such conformance. >> So, while publishing a useful test suite is probably a good idea, I >> strongly recommend fixing the wording of at least the abstract and >> introduction to make it quite clear that these are not mandatory >> tests, and that these tests do not define conformance. > > Sure, the tests are not mandatory. However, if you were purchasing an > IPFIX device which did not claim to be compliant with this draft, you > might rightly ask why not when all the IPFIX implementations we know of > to date have been. > > >> Related to this, please do not assert (in section 3) that passing this >> test suite constitutes conformance to the IPFIX architecture and >> protocol. (Among other things,test suite passage proves nothing about >> architectural conformance.) > > OK. > > >> Technical: >> 2) In the terminology section, an Observation Point is defined simply >> as a place where packets can be observed. An Observation Domain is a >> collection of Observation points. Then, in the middle of the >> definition of an Observation domain it say "In the IPFIX MEssage it >> generates..." but up till now none of the things that have been >> defined generate IPFIX messages. It is possible that the "it" in the >> quote is supposed to be the "Metering Process" mentioned in passing >> earlier in the definition. > > Correct, it is. > > >> But the English grammar does not lead the reader to such a conclusion. >> Later in that same definition, it beings to appear that an Observation >> Domain (which is a collection of points, not a process or entity) is >> supposed to generate IPFIX messages, since it is supposed to include a >> Domain ID in the messages it generates. This definition for an >> Observation Domain needs to be reworked, to avoid confusing the Domain >> with the Measurement Process which is running in / for / on the Domain. > > The Metering Process generates flow records which the Exporting Process > makes into IPFIX messages. > > This whole section is lifted directly from RFC5101, as stated right at > the top of section 2: > > The terminology used in this document is fully aligned with the > terminology specified in [RFC5101] which is reproduced here for > reference. > > >> 3) The use of capital "MUST" in section 3.1 is almost certainly wrong. >> Firstly, what I think that section is saying is that being able to >> correctly perform the basic tests is a precondition for being able to >> perform further test successfully. Thats a precondition, not a "MUST". > > These are basic connectivity tests. If they don't pass then there's no > point in proceeding with the later tests, since you don't even have a > basic connection. > > So yes, these initial tests are a precondition for the later ones. In > effect they MUST pass before proceeding. > > >> Of lesser significance, this document does not provide any description >> of what it means by "MUST". > > Right above the TOC, as ever: > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > >> We are usually careful about how such language is used in >> informational RFCs. I think the meaning would be clearer if the real >> intent were stated. I suspect that some readers of this review may >> find my concern here pedantic. But the continual use of MUST in the >> document really, really bothers me. (I hope the next comment helps >> explain why it bothers me so much.) >> >> 4) Then, the test descriptions go on to keep using this language. >> This is a test suite description document. Simply state how to run >> the test. There is no need for "MUST". Section 3 should indicate >> that the test descriptions describe the preconditions and steps that >> the tester goes through. So section 3.1 would begin "The tester >> creates one Exporting Process and one collection process, configures >> the Exporting Process to ..." > > The -00 version of this draft didn't use any RFC 2119 language. eg, > section 3.1 began: > > Set up one Exporting and one Collecting Process. Configure the > Exporting Process to send to the Collecting Process. > > However, we received feedback that RFC 2119 language should be used so a > tester could clearly see what needed done, and could tick off compliance > with each point as he worked through. > > Reworking the document like this is not an insignificant task. > > >> 5) It is not clear what test steps like ~The tester ensures that an >> SCTP association is established.~ (Or worse, the actual text which >> reads "the test MUST ensure that an SCTP association is established." >> are supposed to do. Is this an instruction to the tester to use >> network management tools or CLI to verify a connection on both >> devices? Is it an instruction to perform additional configuration? >> How does the tester "ensure". > > That would very much depend on the implementation, don't you think? > > >> A test suite should tell a tester what steps to undertake, and what >> observations to perform. "Ensure" is not either one of those. > > Testing and verifying SCTP are quite beyond the scope of this draft. > However, ability to bring up an SCTP association is a necessary > prerequisite for the following tests. > > >> 5a) To elaborate on this issue, in the middle of the test step about >> ensuring that Data Records are actually exported, we finally get a >> testable instruction, to whit, use a packet sniffer and check that the >> packets are coming by. > > Sadly, that was only a suggestion of how the tester might perform this > task. > > >> 6) I believe I understand how a tester would create templates, for the >> template test. But how is the tester to create data sets. >> Particularly data sets with specific properties, such as the padding >> in section 3.2.3 and 3.2.4? > > Again, that would very much depend upon the implementation being tested. > Some implementations may add padding by default, or may have a switch to > allow padding to be optional. It certainly wasn't an issue at our IPFIX > interops. > > >> The best conclusion I can come to is that this is a collector test, >> and that it assumes a packet generator which can generate IPFIX packets. > > That's a good option for testing the Collecting Process - though it > wouldn't verify the Exporting Process. Another possiblity would be for > the tester to inject known data into the Metering Process, either > directly or by passing known traffic through the Observation Point(s). > > >> Having such a device in a test setup makes sense. But the test >> description does not say "configure a packet generator to generate an >> IPFIX packet with ..." (There are other ways to say this, but there >> needs to be some description of how testers are expected to create >> data sets.) > > Again, this seems to be quite implementation dependent. I expect what > you'd do for a PC based implementation would be quite different from > what you'd for for a router based implementation. > > >> 6a) Related to this, I find reading this document rather odd. I have >> read many test suites for protocols and implementations of protocols. >> They generally focus on a Device (or implementation, or entity) Under >> Test, and the framing around that Device. This suite appears to be >> trying to test two interacting devices simultaneously. That is >> extremely difficult, and extremely confusing. > > The IPFIX protocol connects an Exporting Process (source) to a > Collecting Process (destination). One is needed in order to test the > other - or at the very least, something that does a good job of > pretending to be an Exporter or Collector. > > eg, an Exporting Process won't export anything until it's able to bring > up an SCTP association. So if you're going to inject packets (rather > than have an Exporting Process) then you'll first need to do some SCTP > negotiation. All in, it's most straightforward to connect an Exporter to > a Collector. > > >> It is particularly hard because then the tester doesn't have enough >> points of control to perform the tests and observe the results >> meaningfully. It is possible that this combined suite is right for >> this problem. But if so, a lot of explanation of why it is done that >> way and how the tester is to accomplish his goals is needed. >> >> Minor: >> 7) The abstract is worded as if one could not perform interoperability >> testing without first running the tests in this document. While >> having run the tests in this document will presumably increase the >> chances of a successful interoperability test, they are not an >> inherent requirement for such testing. > > We had three IPFIX interops, with this document being drafted after the > first. I believe the pre-requisite for the second and third interops was > that these basic tests had been run, so as to ensure a common baseline > and rule out basic issues which had already been covered in previous > interops. > > >> 8) I would probably be inclined to lighten up the Motivation section a >> bit. Or even remove it. I don't think we need to explain why test >> suites are useful. If we really need a motivation section, then it >> should explain something about why it is particularly complex to test >> IPFIX implementations (if it is) and thus why the IETF feels it is >> particularly useful to publish a test suite ourselves in this case. > > OK. > > >> 9) The definition of Transport Session is actually the definition of >> various kinds of transport sessions, and how they are identified. >> Could the definition start with an actual definition please. (I.e. the >> communication over time used to carry X between Y and Z? Or something.) > > Again, the definition is copied directly from RFC 5101. > > >> 10) As an editorial matter, most testers I have worked with strongly >> prefer if every step in a test is explicitly separate and named / >> numbered. That way, they can check off each step as it goes. So the >> beginning of 3.1.1 would be >> i) Create One Exporting Process >> ii) Create One Collection Process >> iii) Configure the Exporting Process ... > > In effect, each of our MUSTs is such a check. At least, that was the > intention. > > >> 11) It is particularly odd to see a set of Stress/Load tests that >> simultaneously claim to be measuring conformance and to not specify >> the level of Stress / Load. Having a description of how to perform >> load tests is useful. But its relationship to the other tests is >> confusing. (This obviously is helped once we no longer claim that >> this is a conformance test.) > > These tests verify what IPFIX devices do when overloaded, rather than > testing that they're able to handle a certain load level. It's clearly > impossible for us to state specific traffic levels since a) the overload > level may vary enormously from device to device, and b) we're not > interested in the specific level, but in the device's ability to handle > extremes gracefully. > > > Thanks. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 16 10:12:35 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7D828C32B; Sun, 16 Mar 2008 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.571 X-Spam-Level: X-Spam-Status: No, score=-95.571 tagged_above=-999 required=5 tests=[AWL=1.666, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_64=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THtnKutKPHR8; Sun, 16 Mar 2008 10:12:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D50128C1B0; Sun, 16 Mar 2008 10:12:33 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA293A694A; Sat, 15 Mar 2008 17:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FapcHd2IbcQB; Sat, 15 Mar 2008 17:32:29 -0700 (PDT) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 644033A67F1; Sat, 15 Mar 2008 17:32:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id ABA1C7DD6; Sat, 15 Mar 2008 17:30:13 -0700 (PDT) Received: from [10.10.10.101] (pool-71-161-50-201.clppva.east.verizon.net [71.161.50.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id BB0B27DD8; Sat, 15 Mar 2008 17:30:09 -0700 (PDT) Message-ID: <47DC6A11.7010603@joelhalpern.com> Date: Sat, 15 Mar 2008 20:30:09 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47B61982.8040005@joelhalpern.com> <47DAA9FC.3000202@cisco.com> In-Reply-To: <47DAA9FC.3000202@cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Mailman-Approved-At: Sun, 16 Mar 2008 10:12:32 -0700 Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org I think I understand your answers, but I have to disagree with several of the concepts. First, to be clear, the idea of a document which spells out the things that various IPFix components need to be able to do in order to work well is a good idea. Firstly, I am sorry you were told to use 2119 language in describing your tests. As far as I can tell, the usage is wrong in two regards. It does not match the normal meaning of MUST for 2119, and it is confusing to the document reader. For example, if the document said explicitly, "The first set of tests are basic connectivity tests. It is not useful to proceed to more complex tests if these can not be passed." You would have gotten the point across without any MUST language. Note that if someone builds a test device, it should not attempt to enforce that sort of must, since users often perform tests in different orders for their own reasons. When you talk about the tests being a pre-requisite for interoperability, what you have got is that the basic tests are a good way to start interoperability testing. The tests are not actually a precondition for interoperability (although interoperable implementations will presumably pass the tests.) In the IETF, tests are not a precondition. They are useful information. (I have had to cope with the opposite. It does not work.) Secondly, after reading many of your responses about there being multiple ways to perform the various tests, and some cases where you can not specify how they would be performed, I am left with a semantic disconnect. The document is not a test suite. It is a description of things to test for. If that is your goal, it could be re-written to get at that point. As written, it is somewhere in between, and quite confusing. (And yes, I have been reviewing test suites of one sort or another for a VERY long time as it happens.) I listened to a nice description from a person from the BenchMark WorkingGroup (BMWG), which has been doing lots of testing definition at the IETF. If what you want is a test suite, I would suggest talking to them about how to approach it. They focus on concepts like having a single unit being tested for any test, etc. Also, with regard to the definitions, I am not going to second guess the underlying RFC. But as used here I sure found some of them confusing. (Particularly the distinction between a transport session and the identifying characteristics of a transport session.) Yours, Joel M. Halpern Paul Aitken wrote: > Joel, > > Apologies for not responding sooner to your review, as it came right > ahead of the -00 and -nn cutoffs. > > Please see some responses inline. > > >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: Guidelines for IP Flow Information eXport (IPFIX) Testing >> Reviewer: Joel M. Halpern >> Review Date: 15-Feb-2008 >> IETF LC End Date: 26-Feb-2008 >> IESG Telechat date: N/A >> >> Summary: This document needs some additional work before publication >> as an informational RFC. >> I would particularly recommend considering addressing at least the >> first comment below prior to RFC publication. >> I would also suggest that the test descriptions need some >> clarification as described in the technical section below, >> particularly items 5 and 6. >> >> Comments: >> >> Conceptual: >> 1) While the document is being published as an information RFC, the >> wording of the abstract and introduction make it seem that this >> document is actually defining conformance to the IPFIX RFCs. The IETF >> has generally carefully steered clear of defining such conformance. >> So, while publishing a useful test suite is probably a good idea, I >> strongly recommend fixing the wording of at least the abstract and >> introduction to make it quite clear that these are not mandatory >> tests, and that these tests do not define conformance. > > Sure, the tests are not mandatory. However, if you were purchasing an > IPFIX device which did not claim to be compliant with this draft, you > might rightly ask why not when all the IPFIX implementations we know of > to date have been. > > >> Related to this, please do not assert (in section 3) that passing this >> test suite constitutes conformance to the IPFIX architecture and >> protocol. (Among other things,test suite passage proves nothing about >> architectural conformance.) > > OK. > > >> Technical: >> 2) In the terminology section, an Observation Point is defined simply >> as a place where packets can be observed. An Observation Domain is a >> collection of Observation points. Then, in the middle of the >> definition of an Observation domain it say "In the IPFIX MEssage it >> generates..." but up till now none of the things that have been >> defined generate IPFIX messages. It is possible that the "it" in the >> quote is supposed to be the "Metering Process" mentioned in passing >> earlier in the definition. > > Correct, it is. > > >> But the English grammar does not lead the reader to such a conclusion. >> Later in that same definition, it beings to appear that an Observation >> Domain (which is a collection of points, not a process or entity) is >> supposed to generate IPFIX messages, since it is supposed to include a >> Domain ID in the messages it generates. This definition for an >> Observation Domain needs to be reworked, to avoid confusing the Domain >> with the Measurement Process which is running in / for / on the Domain. > > The Metering Process generates flow records which the Exporting Process > makes into IPFIX messages. > > This whole section is lifted directly from RFC5101, as stated right at > the top of section 2: > > The terminology used in this document is fully aligned with the > terminology specified in [RFC5101] which is reproduced here for > reference. > > >> 3) The use of capital "MUST" in section 3.1 is almost certainly wrong. >> Firstly, what I think that section is saying is that being able to >> correctly perform the basic tests is a precondition for being able to >> perform further test successfully. Thats a precondition, not a "MUST". > > These are basic connectivity tests. If they don't pass then there's no > point in proceeding with the later tests, since you don't even have a > basic connection. > > So yes, these initial tests are a precondition for the later ones. In > effect they MUST pass before proceeding. > > >> Of lesser significance, this document does not provide any description >> of what it means by "MUST". > > Right above the TOC, as ever: > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > >> We are usually careful about how such language is used in >> informational RFCs. I think the meaning would be clearer if the real >> intent were stated. I suspect that some readers of this review may >> find my concern here pedantic. But the continual use of MUST in the >> document really, really bothers me. (I hope the next comment helps >> explain why it bothers me so much.) >> >> 4) Then, the test descriptions go on to keep using this language. >> This is a test suite description document. Simply state how to run >> the test. There is no need for "MUST". Section 3 should indicate >> that the test descriptions describe the preconditions and steps that >> the tester goes through. So section 3.1 would begin "The tester >> creates one Exporting Process and one collection process, configures >> the Exporting Process to ..." > > The -00 version of this draft didn't use any RFC 2119 language. eg, > section 3.1 began: > > Set up one Exporting and one Collecting Process. Configure the > Exporting Process to send to the Collecting Process. > > However, we received feedback that RFC 2119 language should be used so a > tester could clearly see what needed done, and could tick off compliance > with each point as he worked through. > > Reworking the document like this is not an insignificant task. > > >> 5) It is not clear what test steps like ~The tester ensures that an >> SCTP association is established.~ (Or worse, the actual text which >> reads "the test MUST ensure that an SCTP association is established." >> are supposed to do. Is this an instruction to the tester to use >> network management tools or CLI to verify a connection on both >> devices? Is it an instruction to perform additional configuration? >> How does the tester "ensure". > > That would very much depend on the implementation, don't you think? > > >> A test suite should tell a tester what steps to undertake, and what >> observations to perform. "Ensure" is not either one of those. > > Testing and verifying SCTP are quite beyond the scope of this draft. > However, ability to bring up an SCTP association is a necessary > prerequisite for the following tests. > > >> 5a) To elaborate on this issue, in the middle of the test step about >> ensuring that Data Records are actually exported, we finally get a >> testable instruction, to whit, use a packet sniffer and check that the >> packets are coming by. > > Sadly, that was only a suggestion of how the tester might perform this > task. > > >> 6) I believe I understand how a tester would create templates, for the >> template test. But how is the tester to create data sets. >> Particularly data sets with specific properties, such as the padding >> in section 3.2.3 and 3.2.4? > > Again, that would very much depend upon the implementation being tested. > Some implementations may add padding by default, or may have a switch to > allow padding to be optional. It certainly wasn't an issue at our IPFIX > interops. > > >> The best conclusion I can come to is that this is a collector test, >> and that it assumes a packet generator which can generate IPFIX packets. > > That's a good option for testing the Collecting Process - though it > wouldn't verify the Exporting Process. Another possiblity would be for > the tester to inject known data into the Metering Process, either > directly or by passing known traffic through the Observation Point(s). > > >> Having such a device in a test setup makes sense. But the test >> description does not say "configure a packet generator to generate an >> IPFIX packet with ..." (There are other ways to say this, but there >> needs to be some description of how testers are expected to create >> data sets.) > > Again, this seems to be quite implementation dependent. I expect what > you'd do for a PC based implementation would be quite different from > what you'd for for a router based implementation. > > >> 6a) Related to this, I find reading this document rather odd. I have >> read many test suites for protocols and implementations of protocols. >> They generally focus on a Device (or implementation, or entity) Under >> Test, and the framing around that Device. This suite appears to be >> trying to test two interacting devices simultaneously. That is >> extremely difficult, and extremely confusing. > > The IPFIX protocol connects an Exporting Process (source) to a > Collecting Process (destination). One is needed in order to test the > other - or at the very least, something that does a good job of > pretending to be an Exporter or Collector. > > eg, an Exporting Process won't export anything until it's able to bring > up an SCTP association. So if you're going to inject packets (rather > than have an Exporting Process) then you'll first need to do some SCTP > negotiation. All in, it's most straightforward to connect an Exporter to > a Collector. > > >> It is particularly hard because then the tester doesn't have enough >> points of control to perform the tests and observe the results >> meaningfully. It is possible that this combined suite is right for >> this problem. But if so, a lot of explanation of why it is done that >> way and how the tester is to accomplish his goals is needed. >> >> Minor: >> 7) The abstract is worded as if one could not perform interoperability >> testing without first running the tests in this document. While >> having run the tests in this document will presumably increase the >> chances of a successful interoperability test, they are not an >> inherent requirement for such testing. > > We had three IPFIX interops, with this document being drafted after the > first. I believe the pre-requisite for the second and third interops was > that these basic tests had been run, so as to ensure a common baseline > and rule out basic issues which had already been covered in previous > interops. > > >> 8) I would probably be inclined to lighten up the Motivation section a >> bit. Or even remove it. I don't think we need to explain why test >> suites are useful. If we really need a motivation section, then it >> should explain something about why it is particularly complex to test >> IPFIX implementations (if it is) and thus why the IETF feels it is >> particularly useful to publish a test suite ourselves in this case. > > OK. > > >> 9) The definition of Transport Session is actually the definition of >> various kinds of transport sessions, and how they are identified. >> Could the definition start with an actual definition please. (I.e. the >> communication over time used to carry X between Y and Z? Or something.) > > Again, the definition is copied directly from RFC 5101. > > >> 10) As an editorial matter, most testers I have worked with strongly >> prefer if every step in a test is explicitly separate and named / >> numbered. That way, they can check off each step as it goes. So the >> beginning of 3.1.1 would be >> i) Create One Exporting Process >> ii) Create One Collection Process >> iii) Configure the Exporting Process ... > > In effect, each of our MUSTs is such a check. At least, that was the > intention. > > >> 11) It is particularly odd to see a set of Stress/Load tests that >> simultaneously claim to be measuring conformance and to not specify >> the level of Stress / Load. Having a description of how to perform >> load tests is useful. But its relationship to the other tests is >> confusing. (This obviously is helped once we no longer claim that >> this is a conformance test.) > > These tests verify what IPFIX devices do when overloaded, rather than > testing that they're able to handle a certain load level. It's clearly > impossible for us to state specific traffic levels since a) the overload > level may vary enormously from device to device, and b) we're not > interested in the specific level, but in the device's ability to handle > extremes gracefully. > > > Thanks. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 16 15:46:57 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8453A6D77; Sun, 16 Mar 2008 15:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.282 X-Spam-Level: X-Spam-Status: No, score=-98.282 tagged_above=-999 required=5 tests=[AWL=2.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw-SwksQoVkn; Sun, 16 Mar 2008 15:46:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F3C3A699B; Sun, 16 Mar 2008 15:46:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95D23A685E; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y75lirEbK985; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 359363A6831; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 416D17DD8; Sun, 16 Mar 2008 15:44:38 -0700 (PDT) Received: from [10.10.10.101] (pool-71-161-50-201.clppva.east.verizon.net [71.161.50.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 50B9F7DD9; Sun, 16 Mar 2008 15:44:35 -0700 (PDT) Message-ID: <47DDA2D8.8050602@joelhalpern.com> Date: Sun, 16 Mar 2008 18:44:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47B61982.8040005@joelhalpern.com> <47DAA9FC.3000202@cisco.com> In-Reply-To: <47DAA9FC.3000202@cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org As I understand the gist of the comments, the document in question was driven by the observation that folks were having trobule achieving interoperability. Trying to fix that is clearly sensible and very much in the IETF and working group interest. Have you looked at things like the SIP torture tests? Those are codifications of specific messages to specific entities that tended to break implementations. It is much easier to define those than actual test suites. Yours, Joel _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 16 15:46:57 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8453A6D77; Sun, 16 Mar 2008 15:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.282 X-Spam-Level: X-Spam-Status: No, score=-98.282 tagged_above=-999 required=5 tests=[AWL=2.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw-SwksQoVkn; Sun, 16 Mar 2008 15:46:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F3C3A699B; Sun, 16 Mar 2008 15:46:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95D23A685E; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y75lirEbK985; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 359363A6831; Sun, 16 Mar 2008 15:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 416D17DD8; Sun, 16 Mar 2008 15:44:38 -0700 (PDT) Received: from [10.10.10.101] (pool-71-161-50-201.clppva.east.verizon.net [71.161.50.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 50B9F7DD9; Sun, 16 Mar 2008 15:44:35 -0700 (PDT) Message-ID: <47DDA2D8.8050602@joelhalpern.com> Date: Sun, 16 Mar 2008 18:44:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47B61982.8040005@joelhalpern.com> <47DAA9FC.3000202@cisco.com> In-Reply-To: <47DAA9FC.3000202@cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Cc: IETF discussion list , ipfix@ietf.org, gen-art@ietf.org Subject: Re: [IPFIX] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org As I understand the gist of the comments, the document in question was driven by the observation that folks were having trobule achieving interoperability. Trying to fix that is clearly sensible and very much in the IETF and working group interest. Have you looked at things like the SIP torture tests? Those are codifications of specific messages to specific entities that tended to break implementations. It is much easier to define those than actual test suites. Yours, Joel _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 16 15:50:33 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05333A6AF1; Sun, 16 Mar 2008 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoxgP8O62m+u; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CFB3A6947; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DD93A6947 for ; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFT15VcsPn+0 for ; Sun, 16 Mar 2008 15:50:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D00283A68B7 for ; Sun, 16 Mar 2008 15:50:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,510,1199660400"; d="scan'208";a="3607494" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2008 23:48:05 +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/8.12.11) with ESMTP id m2GMm5DT021715; Sun, 16 Mar 2008 23:48:05 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2GMm5Hl009803; Sun, 16 Mar 2008 22:48:05 GMT Received: from [10.61.64.55] (ams3-vpn-dhcp55.cisco.com [10.61.64.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2GMm0W20269; Sun, 16 Mar 2008 22:48:00 GMT Message-ID: <47DDA3C0.2040406@cisco.com> Date: Sun, 16 Mar 2008 22:48:32 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Brian Trammell References: <47D5F8D7.2070103@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1092; t=1205707685; x=1206571685; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20IPFIX-based=20file=0A=20format=3A=20 feedback |Sender:=20; bh=4eamAixV9qIPj/C2FmI262bzGPtuhK316n2EG/FXMc8=; b=MQA7yGYHOo3EuPu4i0KKRdlgeZcNIi2qmvTUrnE7Pae1UK6VvG4BuT1oju ryPJhI98QoITKB1+qkKmXQll4k0n6zFn10huw5wxMWJEHTgUugyr/a7/OdT0 zhAdFNyeQK; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Arno Wagner , Lutz Mark , ipfix@ietf.org, Elisa Boschi Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> - I think that you would benefit from the per-SCTP stream, as the >> order is maintained. It might be worth stressing that, if the >> per-SCTP stream is implemented, we would not have the timing issue >> related to data records sent to multiple SCTP stream. > > Since each file is its own stream Why do you say that? It'd be perfectly possible to record multiple streams into a single file, and to recreate multiple streams from a single file. > the only way to implement per-stream storage for files is one file > per stream. A single file with a stream indicator for each record would also suffice - though that isn't absolutely necessary unless you want the replayed data to be 100% faithful to the original. It'd be quite straightforward to save all the streams into a single file, and to rebuild individual streams from the file just as the original exporter does. However, without saving an "original stream" indicator, the new streams may not be quite the same as the originals. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Mar 16 15:50:33 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05333A6AF1; Sun, 16 Mar 2008 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoxgP8O62m+u; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CFB3A6947; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DD93A6947 for ; Sun, 16 Mar 2008 15:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFT15VcsPn+0 for ; Sun, 16 Mar 2008 15:50:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D00283A68B7 for ; Sun, 16 Mar 2008 15:50:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,510,1199660400"; d="scan'208";a="3607494" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2008 23:48:05 +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/8.12.11) with ESMTP id m2GMm5DT021715; Sun, 16 Mar 2008 23:48:05 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2GMm5Hl009803; Sun, 16 Mar 2008 22:48:05 GMT Received: from [10.61.64.55] (ams3-vpn-dhcp55.cisco.com [10.61.64.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2GMm0W20269; Sun, 16 Mar 2008 22:48:00 GMT Message-ID: <47DDA3C0.2040406@cisco.com> Date: Sun, 16 Mar 2008 22:48:32 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Brian Trammell References: <47D5F8D7.2070103@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1092; t=1205707685; x=1206571685; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20IPFIX-based=20file=0A=20format=3A=20 feedback |Sender:=20; bh=4eamAixV9qIPj/C2FmI262bzGPtuhK316n2EG/FXMc8=; b=MQA7yGYHOo3EuPu4i0KKRdlgeZcNIi2qmvTUrnE7Pae1UK6VvG4BuT1oju ryPJhI98QoITKB1+qkKmXQll4k0n6zFn10huw5wxMWJEHTgUugyr/a7/OdT0 zhAdFNyeQK; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Arno Wagner , Lutz Mark , ipfix@ietf.org, Elisa Boschi Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> - I think that you would benefit from the per-SCTP stream, as the >> order is maintained. It might be worth stressing that, if the >> per-SCTP stream is implemented, we would not have the timing issue >> related to data records sent to multiple SCTP stream. > > Since each file is its own stream Why do you say that? It'd be perfectly possible to record multiple streams into a single file, and to recreate multiple streams from a single file. > the only way to implement per-stream storage for files is one file > per stream. A single file with a stream indicator for each record would also suffice - though that isn't absolutely necessary unless you want the replayed data to be 100% faithful to the original. It'd be quite straightforward to save all the streams into a single file, and to rebuild individual streams from the file just as the original exporter does. However, without saving an "original stream" indicator, the new streams may not be quite the same as the originals. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 08:03:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A763A68B6; Mon, 17 Mar 2008 08:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-2.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZHAWtoV6krL; Mon, 17 Mar 2008 08:03:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A0928C252; Mon, 17 Mar 2008 08:03:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5003A68D7 for ; Mon, 17 Mar 2008 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o5UwmnmAC2i for ; Mon, 17 Mar 2008 08:03:10 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 5AD233A67DA for ; Mon, 17 Mar 2008 08:03:09 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m2HF0MC2020636; Mon, 17 Mar 2008 16:00:23 +0100 Message-ID: <47DE8786.7030207@informatik.uni-tuebingen.de> Date: Mon, 17 Mar 2008 16:00:22 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> In-Reply-To: <47DDA3C0.2040406@cisco.com> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.6.0.73; VDF: 7.0.3.39; host: mx06) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263344161==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0263344161== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020506020706060608030908" This is a cryptographically signed message in MIME format. --------------ms020506020706060608030908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Paul, Benoit, I have not read the current version of the draft, yet I have the impression that things are mixed up a little bit. Maybe I can help clarifying. >>> - I think that you would benefit from the per-SCTP stream, as the=20 >>> order is maintained. It might be worth stressing that, if the >>> per-SCTP stream is implemented, we would not have the timing issue >>> related to data records sent to multiple SCTP stream. >> >> Since each file is its own stream If I understood correctly, Benoit wanted to point out that the timing issue is solved if (1) IPFIX messages are delivered in order, (2) a Template aFrom ipfix-bounces@ietf.org Mon Mar 17 08:03:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A763A68B6; Mon, 17 Mar 2008 08:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-2.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZHAWtoV6krL; Mon, 17 Mar 2008 08:03:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A0928C252; Mon, 17 Mar 2008 08:03:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5003A68D7 for ; Mon, 17 Mar 2008 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o5UwmnmAC2i for ; Mon, 17 Mar 2008 08:03:10 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 5AD233A67DA for ; Mon, 17 Mar 2008 08:03:09 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m2HF0MC2020636; Mon, 17 Mar 2008 16:00:23 +0100 Message-ID: <47DE8786.7030207@informatik.uni-tuebingen.de> Date: Mon, 17 Mar 2008 16:00:22 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> In-Reply-To: <47DDA3C0.2040406@cisco.com> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.6.0.73; VDF: 7.0.3.39; host: mx06) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263344161==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0263344161== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020506020706060608030908" This is a cryptographically signed message in MIME format. --------------ms020506020706060608030908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Paul, Benoit, I have not read the current version of the draft, yet I have the impression that things are mixed up a little bit. Maybe I can help clarifying. >>> - I think that you would benefit from the per-SCTP stream, as the=20 >>> order is maintained. It might be worth stressing that, if the >>> per-SCTP stream is implemented, we would not have the timing issue >>> related to data records sent to multiple SCTP stream. >> >> Since each file is its own stream If I understood correctly, Benoit wanted to point out that the timing issue is solved if (1) IPFIX messages are delivered in order, (2) a Template and its associated Data Records and Withdrawal Message are sent over the same stream, and (3) Template IDs are not reused on different streams. These considerations are part of per-SCTP stream draft. They ensure that Templates arrive before Data Records, Template Withdrawal Messages before new Templates with same ID etc. You still can save everything in the same file if the purpose is to save the information without ambiguities. In this case, you can even forget the information on which streams you received the messages. > Why do you say that? It'd be perfectly possible to record multiple > streams into a single file, and to recreate multiple streams from a > single file. >=20 >=20 >> the only way to implement per-stream storage for files is one file >> per stream. >=20 > A single file with a stream indicator for each record would also suffic= e > - though that isn't absolutely necessary unless you want the replayed > data to be 100% faithful to the original. Exactly. You can drop the stream information unless you want to replay the Transport Session using the same streams as the original. > It'd be quite straightforward to save all the streams into a single > file, and to rebuild individual streams from the file just as the > original exporter does. However, without saving an "original stream" > indicator, the new streams may not be quite the same as the originals. Is there really a need to replay Transport Sessions as the original? If the goal is just to let a new Exporting Process export the saved data, we can leave the decision about the stream assignment to this Exporting Process. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020506020706060608030908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSnd its associated Data Records and Withdrawal Message are sent over the same stream, and (3) Template IDs are not reused on different streams. These considerations are part of per-SCTP stream draft. They ensure that Templates arrive before Data Records, Template Withdrawal Messages before new Templates with same ID etc. You still can save everything in the same file if the purpose is to save the information without ambiguities. In this case, you can even forget the information on which streams you received the messages. > Why do you say that? It'd be perfectly possible to record multiple > streams into a single file, and to recreate multiple streams from a > single file. >=20 >=20 >> the only way to implement per-stream storage for files is one file >> per stream. >=20 > A single file with a stream indicator for each record would also suffic= e > - though that isn't absolutely necessary unless you want the replayed > data to be 100% faithful to the original. Exactly. You can drop the stream information unless you want to replay the Transport Session using the same streams as the original. > It'd be quite straightforward to save all the streams into a single > file, and to rebuild individual streams from the file just as the > original exporter does. However, without saving an "original stream" > indicator, the new streams may not be quite the same as the originals. Is there really a need to replay Transport Sessions as the original? If the goal is just to let a new Exporting Process export the saved data, we can leave the decision about the stream assignment to this Exporting Process. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020506020706060608030908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDMxNzE1MDAyMlowIwYJKoZIhvcNAQkEMRYEFMjRsniHkWlB sld/qQmRAnwgUayzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCy+PbA9Q8V8z2KtrmKFqgXlitXlWzEyTfd/+lEi7NB7mQJiVx9THyLneCu 51mAQ7P0L/8rAc2UPVNDp5XFc8ncUXgYDZ/AsEjDMiNVFYS3tJnN6vjHiJZF0T8Yc5rS8nzR ahNDhucP2WhVXurt3y7aY37/TWAjSJh322a4mw/ZOysFgfaLsUpnwEtQyPmxEiGdkfZwX6pl bYxz94ZsyVDrkf6kpobUib/EziYzjWWet4e9XFMJiEeXbCRdIaCKUxJMi+BigUT2IkCqXpP7 9kir3apreTQoqPo7GfHdf0iygf9XvsHqiemxc1dqzVRP5khYOzife5SPL/9Ai49lGC/fAAAA AAAA --------------ms020506020706060608030908-- --===============0263344161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0263344161==-- IS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDMxNzE1MDAyMlowIwYJKoZIhvcNAQkEMRYEFMjRsniHkWlB sld/qQmRAnwgUayzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCy+PbA9Q8V8z2KtrmKFqgXlitXlWzEyTfd/+lEi7NB7mQJiVx9THyLneCu 51mAQ7P0L/8rAc2UPVNDp5XFc8ncUXgYDZ/AsEjDMiNVFYS3tJnN6vjHiJZF0T8Yc5rS8nzR ahNDhucP2WhVXurt3y7aY37/TWAjSJh322a4mw/ZOysFgfaLsUpnwEtQyPmxEiGdkfZwX6pl bYxz94ZsyVDrkf6kpobUib/EziYzjWWet4e9XFMJiEeXbCRdIaCKUxJMi+BigUT2IkCqXpP7 9kir3apreTQoqPo7GfHdf0iygf9XvsHqiemxc1dqzVRP5khYOzife5SPL/9Ai49lGC/fAAAA AAAA --------------ms020506020706060608030908-- --===============0263344161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0263344161==-- From ipfix-bounces@ietf.org Mon Mar 17 08:22:19 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2EB28C461; Mon, 17 Mar 2008 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkvLdlZZxS78; Mon, 17 Mar 2008 08:22:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D417D28C435; Mon, 17 Mar 2008 08:22:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA64028C420 for ; Mon, 17 Mar 2008 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY9dNLS2CauF for ; Mon, 17 Mar 2008 08:22:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8763E28C435 for ; Mon, 17 Mar 2008 08:22:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,512,1199660400"; d="scan'208";a="3723017" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2008 16:19:56 +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/8.12.11) with ESMTP id m2HFJuV0002680; Mon, 17 Mar 2008 16:19:56 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2HFJtPq015877; Mon, 17 Mar 2008 15:19:55 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2HFJrW14368; Mon, 17 Mar 2008 15:19:53 GMT Message-ID: <47DE8C3D.8070108@cisco.com> Date: Mon, 17 Mar 2008 15:20:29 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Gerhard Muenz References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> In-Reply-To: <47DE8786.7030207@informatik.uni-tuebingen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=665; t=1205767196; x=1206631196; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20IPFIX-based=20file=20format=3A=20feedba ck |Sender:=20; bh=PALblV/JTbhCH5QUEE4nPyLVf2CgnQ5kuu1DPaD3uTw=; b=vLG8gdGhokMhHyScDL9U61AbVByoXz7ajxPLM4rLaYgiQWQs/YkqSUdz1m 20fbaPqEXZQuYx0jCMc553xUxp/2PT0hPhVKVRtJI21HHKfMkj37NRbohEch l5iAybixT7; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, I quite agree with all your points. > Is there really a need to replay Transport Sessions as the original? There may be a need to transparently store and replay IPFIX information. Further, being able to specify which stream each template, option or data record is to be sent on allows the file format to recreate and test unusual bugs which may be difficult or impossible to create otherwise. > If the goal is just to let a new Exporting Process export the saved > data, we can leave the decision about the stream assignment to this > Exporting Process. Absolutely. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 08:22:19 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2EB28C461; Mon, 17 Mar 2008 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkvLdlZZxS78; Mon, 17 Mar 2008 08:22:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D417D28C435; Mon, 17 Mar 2008 08:22:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA64028C420 for ; Mon, 17 Mar 2008 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY9dNLS2CauF for ; Mon, 17 Mar 2008 08:22:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8763E28C435 for ; Mon, 17 Mar 2008 08:22:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,512,1199660400"; d="scan'208";a="3723017" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2008 16:19:56 +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/8.12.11) with ESMTP id m2HFJuV0002680; Mon, 17 Mar 2008 16:19:56 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2HFJtPq015877; Mon, 17 Mar 2008 15:19:55 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2HFJrW14368; Mon, 17 Mar 2008 15:19:53 GMT Message-ID: <47DE8C3D.8070108@cisco.com> Date: Mon, 17 Mar 2008 15:20:29 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Gerhard Muenz References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> In-Reply-To: <47DE8786.7030207@informatik.uni-tuebingen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=665; t=1205767196; x=1206631196; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20IPFIX-based=20file=20format=3A=20feedba ck |Sender:=20; bh=PALblV/JTbhCH5QUEE4nPyLVf2CgnQ5kuu1DPaD3uTw=; b=vLG8gdGhokMhHyScDL9U61AbVByoXz7ajxPLM4rLaYgiQWQs/YkqSUdz1m 20fbaPqEXZQuYx0jCMc553xUxp/2PT0hPhVKVRtJI21HHKfMkj37NRbohEch l5iAybixT7; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, I quite agree with all your points. > Is there really a need to replay Transport Sessions as the original? There may be a need to transparently store and replay IPFIX information. Further, being able to specify which stream each template, option or data record is to be sent on allows the file format to recreate and test unusual bugs which may be difficult or impossible to create otherwise. > If the goal is just to let a new Exporting Process export the saved > data, we can leave the decision about the stream assignment to this > Exporting Process. Absolutely. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 08:50:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714643A6E2B; Mon, 17 Mar 2008 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FivXwKoVWvI; Mon, 17 Mar 2008 08:50:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E54B28C169; Mon, 17 Mar 2008 08:50:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C14D3A6E11 for ; Mon, 17 Mar 2008 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm-oQqWWVHfg for ; Mon, 17 Mar 2008 08:50:12 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 2005A3A696D for ; Mon, 17 Mar 2008 08:50:12 -0700 (PDT) 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 m2HFlhWv026300 for ; Mon, 17 Mar 2008 11:47:49 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2HFl6AH026268 for ; Mon, 17 Mar 2008 11:47:06 -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 m2HFl62B026265; Mon, 17 Mar 2008 11:47:06 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (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.70) with ESMTP id m2HFl6vX032467; Mon, 17 Mar 2008 11:47:06 -0400 Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <47DE8C3D.8070108@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 11:47:06 -0400 References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> <47DE8C3D.8070108@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Paul, Agreed as well. I think what I'm reading here is that we can store multistream information interleaved, and provide an sctpStream IE for the Message Details Options Template to support replay, should it be necessary... yes? - Brian On Mar 17, 2008, at 11:20 AM, Paul Aitken wrote: > Gerhard, > > I quite agree with all your points. > > >> Is there really a need to replay Transport Sessions as the original? > > There may be a need to transparently store and replay IPFIX > information. > > Further, being able to specify which stream each template, option or > data record is to be sent on allows the file format to recreate and > test > unusual bugs which may be difficult or impossible to create otherwise. > > >> If the goal is just to let a new Exporting Process export the saved >> data, we can leave the decision about the stream assignment to this >> Exporting Process. > > Absolutely. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 08:50:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714643A6E2B; Mon, 17 Mar 2008 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FivXwKoVWvI; Mon, 17 Mar 2008 08:50:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E54B28C169; Mon, 17 Mar 2008 08:50:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C14D3A6E11 for ; Mon, 17 Mar 2008 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm-oQqWWVHfg for ; Mon, 17 Mar 2008 08:50:12 -0700 (PDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by core3.amsl.com (Postfix) with ESMTP id 2005A3A696D for ; Mon, 17 Mar 2008 08:50:12 -0700 (PDT) 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 m2HFlhWv026300 for ; Mon, 17 Mar 2008 11:47:49 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2HFl6AH026268 for ; Mon, 17 Mar 2008 11:47:06 -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 m2HFl62B026265; Mon, 17 Mar 2008 11:47:06 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (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.70) with ESMTP id m2HFl6vX032467; Mon, 17 Mar 2008 11:47:06 -0400 Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <47DE8C3D.8070108@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 11:47:06 -0400 References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> <47DE8C3D.8070108@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Paul, Agreed as well. I think what I'm reading here is that we can store multistream information interleaved, and provide an sctpStream IE for the Message Details Options Template to support replay, should it be necessary... yes? - Brian On Mar 17, 2008, at 11:20 AM, Paul Aitken wrote: > Gerhard, > > I quite agree with all your points. > > >> Is there really a need to replay Transport Sessions as the original? > > There may be a need to transparently store and replay IPFIX > information. > > Further, being able to specify which stream each template, option or > data record is to be sent on allows the file format to recreate and > test > unusual bugs which may be difficult or impossible to create otherwise. > > >> If the goal is just to let a new Exporting Process export the saved >> data, we can leave the decision about the stream assignment to this >> Exporting Process. > > Absolutely. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 09:12:19 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88C03A6E6B; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.122 X-Spam-Level: X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhhZT7WDxKhz; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147C33A6E4A; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542803A6C3E for ; Mon, 17 Mar 2008 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngU0Q-kqpjYE for ; Mon, 17 Mar 2008 09:12:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5AA8B3A6B88 for ; Mon, 17 Mar 2008 09:12:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,513,1199660400"; d="scan'208";a="3730405" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2008 17:09:51 +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/8.12.11) with ESMTP id m2HG9pjB014239; Mon, 17 Mar 2008 17:09:51 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2HG9pcj008780; Mon, 17 Mar 2008 16:09:51 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2HG9nW18601; Mon, 17 Mar 2008 16:09:49 GMT Message-ID: <47DE97F1.7050709@cisco.com> Date: Mon, 17 Mar 2008 16:10:25 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Brian Trammell References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> <47DE8C3D.8070108@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=446; t=1205770191; x=1206634191; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=If1pIUwR4of5B5nR7Q7RDLx6RzG8fh/Z81c10OntcWM=; b=bikVO7FLk+uB/nb0mJF5sIE3KJMCd45JjjkIVRSQAUCVt51t/inrvhvcoR h/1iopqyun7piCLmANbSEqZPP9Dw+W3S/h5dhzMP79rEQD564VbCCug4VKNJ gXun/ImWqu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > I think what I'm reading here is that we can store multistream > information interleaved, and provide an sctpStream IE for the Message > Details Options Template to support replay, should it be necessary... yes? Pretty much. You might need to store the stream IE with every received record, template and option - and not allow it to be transmitted on the wire. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 17 09:12:19 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88C03A6E6B; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.122 X-Spam-Level: X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhhZT7WDxKhz; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147C33A6E4A; Mon, 17 Mar 2008 09:12:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542803A6C3E for ; Mon, 17 Mar 2008 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngU0Q-kqpjYE for ; Mon, 17 Mar 2008 09:12:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5AA8B3A6B88 for ; Mon, 17 Mar 2008 09:12:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,513,1199660400"; d="scan'208";a="3730405" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2008 17:09:51 +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/8.12.11) with ESMTP id m2HG9pjB014239; Mon, 17 Mar 2008 17:09:51 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2HG9pcj008780; Mon, 17 Mar 2008 16:09:51 GMT Received: from [144.254.153.37] (dhcp-144-254-153-37.cisco.com [144.254.153.37]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m2HG9nW18601; Mon, 17 Mar 2008 16:09:49 GMT Message-ID: <47DE97F1.7050709@cisco.com> Date: Mon, 17 Mar 2008 16:10:25 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Brian Trammell References: <47D5F8D7.2070103@cisco.com> <47DDA3C0.2040406@cisco.com> <47DE8786.7030207@informatik.uni-tuebingen.de> <47DE8C3D.8070108@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=446; t=1205770191; x=1206634191; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX-based=20file=20format=3 A=20feedback |Sender:=20; bh=If1pIUwR4of5B5nR7Q7RDLx6RzG8fh/Z81c10OntcWM=; b=bikVO7FLk+uB/nb0mJF5sIE3KJMCd45JjjkIVRSQAUCVt51t/inrvhvcoR h/1iopqyun7piCLmANbSEqZPP9Dw+W3S/h5dhzMP79rEQD564VbCCug4VKNJ gXun/ImWqu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based file format: feedback X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > I think what I'm reading here is that we can store multistream > information interleaved, and provide an sctpStream IE for the Message > Details Options Template to support replay, should it be necessary... yes? Pretty much. You might need to store the stream IE with every received record, template and option - and not allow it to be transmitted on the wire. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From zifgiumarelloscop@giumarellos.com Tue Mar 18 14:04:45 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E55A3A67F2; Tue, 18 Mar 2008 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR5kNon6sywz; Tue, 18 Mar 2008 14:04:43 -0700 (PDT) Received: from coopcastilla.telesat.net.co (coopcastilla.telesat.net.co [66.128.40.249]) by core3.amsl.com (Postfix) with ESMTP id D689128C1DA; Tue, 18 Mar 2008 14:04:39 -0700 (PDT) Received: from [66.128.40.249] by mx4.mysuperpageshosting.com; Tue, 18 Mar 2008 16:02:22 -0500 Date: Tue, 18 Mar 2008 16:02:22 -0500 From: "Bernadette Caudill" X-Mailer: The Bat! (v3.51.10) Professional Reply-To: zifgiumarelloscop@giumarellos.com X-Priority: 3 (Normal) Message-ID: <577587542.62293792663114@giumarellos.com> To: agentx-archive@lists.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D38DABBB48DA4F21" X-Antivirus: avast! (VPS 080318-1, 18/03/2008), Outbound message X-Antivirus-Status: Clean ------------D38DABBB48DA4F21 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Are you searhing for the better prices in software discounts? Now you will get the chance to use the softs you dreamt of for a very long time. And the better thing for you is, all softs are of awfully low prices. Be sure by youself and take the softwares for cheapest rates ever seen! http://annmarierooneyn177.blogspot.com ------------D38DABBB48DA4F21 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit
Are you searhing for the better prices in software discounts?
Now you will get the chance to use the softs you dreamt of for a very long time.
And the better thing for you is, all softs are of awfully low prices.
Be sure by youself and take the softwares for cheapest rates ever seen!
http://annmarierooneyn177.blogspot.com ------------D38DABBB48DA4F21-- From ipfix-bounces@ietf.org Thu Mar 20 09:51:35 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B055528C6F8; Thu, 20 Mar 2008 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.281 X-Spam-Level: X-Spam-Status: No, score=-98.281 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHtzFgxS8DPT; Thu, 20 Mar 2008 09:51:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7187E28C321; Thu, 20 Mar 2008 09:51:10 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5106D28C7B2 for ; Thu, 20 Mar 2008 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUYAerSAHnuh for ; Thu, 20 Mar 2008 09:51:03 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 8109028C7D7 for ; Thu, 20 Mar 2008 09:48:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 300A94807EC for ; Fri, 21 Mar 2008 05:46:06 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee3sl2mMxWbD for ; Fri, 21 Mar 2008 05:46:06 +1300 (NZDT) Received: from [192.172.226.50] (dyn50.caida.org [192.172.226.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7AB7E4807DC for ; Fri, 21 Mar 2008 05:46:05 +1300 (NZDT) Message-ID: <47E294C6.2000901@auckland.ac.nz> Date: Fri, 21 Mar 2008 05:45:58 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: ipfix@ietf.org Subject: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: As discussed at our meet ing in Philadelphia, this is the start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. Please read the draft, and send any comments/suggestions to the IPFIX list. Beter still, write a brief review of it and email that to me before the WGLC ends. This WGLC will end on Friday, 4 April 08 Cheers, Nevil --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Mar 20 09:51:35 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B055528C6F8; Thu, 20 Mar 2008 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.281 X-Spam-Level: X-Spam-Status: No, score=-98.281 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHtzFgxS8DPT; Thu, 20 Mar 2008 09:51:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7187E28C321; Thu, 20 Mar 2008 09:51:10 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5106D28C7B2 for ; Thu, 20 Mar 2008 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUYAerSAHnuh for ; Thu, 20 Mar 2008 09:51:03 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 8109028C7D7 for ; Thu, 20 Mar 2008 09:48:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 300A94807EC for ; Fri, 21 Mar 2008 05:46:06 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee3sl2mMxWbD for ; Fri, 21 Mar 2008 05:46:06 +1300 (NZDT) Received: from [192.172.226.50] (dyn50.caida.org [192.172.226.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7AB7E4807DC for ; Fri, 21 Mar 2008 05:46:05 +1300 (NZDT) Message-ID: <47E294C6.2000901@auckland.ac.nz> Date: Fri, 21 Mar 2008 05:45:58 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: ipfix@ietf.org Subject: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: As discussed at our meet ing in Philadelphia, this is the start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. Please read the draft, and send any comments/suggestions to the IPFIX list. Beter still, write a brief review of it and email that to me before the WGLC ends. This WGLC will end on Friday, 4 April 08 Cheers, Nevil --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Mar 20 09:56:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C1028C3D8; Thu, 20 Mar 2008 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.145 X-Spam-Level: X-Spam-Status: No, score=-99.145 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHr5C54w4m54; Thu, 20 Mar 2008 09:56:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA3328C1A7; Thu, 20 Mar 2008 09:56:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF05E3A6D3A; Thu, 20 Mar 2008 09:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrDivvXPLwZh; Thu, 20 Mar 2008 09:56:12 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id ECE6A3A6774; Thu, 20 Mar 2008 09:56:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E18C9187A5; Fri, 21 Mar 2008 05:53:52 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU5DdkDcuS8T; Fri, 21 Mar 2008 05:53:52 +1300 (NZDT) Received: from [192.172.226.50] (dyn50.caida.org [192.172.226.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0AB4B18726; Fri, 21 Mar 2008 05:53:51 +1300 (NZDT) Message-ID: <47E2969E.8040204@auckland.ac.nz> Date: Fri, 21 Mar 2008 05:53:50 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: internet-drafts@ietf.org Cc: ipfix@ietf.org Subject: [IPFIX] Approval to post new IPFIX WG drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Internet-Drafts folks: At our IETF-71 meeting, the IPFIX WG adopted 4 drafts as new WG documents. When theyy're sent to you, please publish the following: 1. draft-ietf-ipfix-configuration-model-00.txt 2. draft-ietf-ipfix-per-stream-sctp-exporting-00.txt 3. draft-ietf-ipfix-mediators-problem-statement-00.txt 4. draft-ietf-ipfix-mediators-framework-00.txt Thanks, Nevil IPFIX Working Group co-chair --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Mar 20 09:56:15 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C1028C3D8; Thu, 20 Mar 2008 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.145 X-Spam-Level: X-Spam-Status: No, score=-99.145 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHr5C54w4m54; Thu, 20 Mar 2008 09:56:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA3328C1A7; Thu, 20 Mar 2008 09:56:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF05E3A6D3A; Thu, 20 Mar 2008 09:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrDivvXPLwZh; Thu, 20 Mar 2008 09:56:12 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id ECE6A3A6774; Thu, 20 Mar 2008 09:56:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E18C9187A5; Fri, 21 Mar 2008 05:53:52 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU5DdkDcuS8T; Fri, 21 Mar 2008 05:53:52 +1300 (NZDT) Received: from [192.172.226.50] (dyn50.caida.org [192.172.226.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0AB4B18726; Fri, 21 Mar 2008 05:53:51 +1300 (NZDT) Message-ID: <47E2969E.8040204@auckland.ac.nz> Date: Fri, 21 Mar 2008 05:53:50 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: internet-drafts@ietf.org Cc: ipfix@ietf.org Subject: [IPFIX] Approval to post new IPFIX WG drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Internet-Drafts folks: At our IETF-71 meeting, the IPFIX WG adopted 4 drafts as new WG documents. When theyy're sent to you, please publish the following: 1. draft-ietf-ipfix-configuration-model-00.txt 2. draft-ietf-ipfix-per-stream-sctp-exporting-00.txt 3. draft-ietf-ipfix-mediators-problem-statement-00.txt 4. draft-ietf-ipfix-mediators-framework-00.txt Thanks, Nevil IPFIX Working Group co-chair --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 24 06:33:43 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A443A6E79; Mon, 24 Mar 2008 06:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.241 X-Spam-Level: X-Spam-Status: No, score=-99.241 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyeNOJYksN-i; Mon, 24 Mar 2008 06:33:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85673A6E3F; Mon, 24 Mar 2008 06:33:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A363A6C96 for ; Mon, 24 Mar 2008 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgNbOyA12Tyh for ; Mon, 24 Mar 2008 06:33:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B9C043A6E3F for ; Mon, 24 Mar 2008 06:33:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,546,1199682000"; d="scan'208";a="99302405" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Mar 2008 09:31:11 -0400 X-IronPort-AV: E=Sophos;i="4.25,546,1199682000"; d="scan'208";a="172181523" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Mar 2008 09:31:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Mar 2008 14:31:15 +0100 Message-ID: In-Reply-To: <47E294C6.2000901@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WGLC starts for MIBl draft Thread-Index: AciKqn7UTfLsg2GhS1KPoqhcBsGiLQDCLm7Q References: <47E294C6.2000901@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , Subject: Re: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org I guess that what is meant here is actually draft-ietf-ipfix-mib-03.txt! Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] > On Behalf Of Nevil Brownlee > Sent: Thursday, March 20, 2008 6:46 PM > To: ipfix@ietf.org > Subject: [IPFIX] WGLC starts for MIBl draft > > > Hi all: > > As discussed at our meet ing in Philadelphia, this is the > start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. > > Please read the draft, and send any comments/suggestions to > the IPFIX list. Beter still, write a brief review of it and > email that to me before the WGLC ends. > > This WGLC will end on Friday, 4 April 08 > > Cheers, Nevil > > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 24 06:33:43 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A443A6E79; Mon, 24 Mar 2008 06:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.241 X-Spam-Level: X-Spam-Status: No, score=-99.241 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyeNOJYksN-i; Mon, 24 Mar 2008 06:33:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85673A6E3F; Mon, 24 Mar 2008 06:33:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A363A6C96 for ; Mon, 24 Mar 2008 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgNbOyA12Tyh for ; Mon, 24 Mar 2008 06:33:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B9C043A6E3F for ; Mon, 24 Mar 2008 06:33:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,546,1199682000"; d="scan'208";a="99302405" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Mar 2008 09:31:11 -0400 X-IronPort-AV: E=Sophos;i="4.25,546,1199682000"; d="scan'208";a="172181523" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Mar 2008 09:31:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Mar 2008 14:31:15 +0100 Message-ID: In-Reply-To: <47E294C6.2000901@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WGLC starts for MIBl draft Thread-Index: AciKqn7UTfLsg2GhS1KPoqhcBsGiLQDCLm7Q References: <47E294C6.2000901@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , Subject: Re: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org I guess that what is meant here is actually draft-ietf-ipfix-mib-03.txt! Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] > On Behalf Of Nevil Brownlee > Sent: Thursday, March 20, 2008 6:46 PM > To: ipfix@ietf.org > Subject: [IPFIX] WGLC starts for MIBl draft > > > Hi all: > > As discussed at our meet ing in Philadelphia, this is the > start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. > > Please read the draft, and send any comments/suggestions to > the IPFIX list. Beter still, write a brief review of it and > email that to me before the WGLC ends. > > This WGLC will end on Friday, 4 April 08 > > Cheers, Nevil > > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Mar 24 09:29:03 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082213A6E90; Mon, 24 Mar 2008 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.281 X-Spam-Level: X-Spam-Status: No, score=-98.281 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH0rob4zg6tt; Mon, 24 Mar 2008 09:29:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC013A6E14; Mon, 24 Mar 2008 09:29:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297A13A6D47 for ; Mon, 24 Mar 2008 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GYQt5wl2TWp for ; Mon, 24 Mar 2008 09:28:56 -0700 (PDT) Received: from caida.org (rommie.caida.org [192.172.226.78]) by core3.amsl.com (Postfix) with ESMTP id 69DD23A6810 for ; Mon, 24 Mar 2008 09:28:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by caida.org (Postfix) with ESMTP id 9A1F4C06C; Mon, 24 Mar 2008 09:26:37 -0700 (PDT) Date: Mon, 24 Mar 2008 09:26:37 -0700 (PDT) From: Nevil Brownlee To: "Romascanu, Dan (Dan)" In-Reply-To: Message-ID: <20080324092611.D93042@rommie.caida.org> References: <47E294C6.2000901@auckland.ac.nz> MIME-Version: 1.0 Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Dan: Oops, yes, draft-ietf-ipfix-mib-03.txt it is. Thanks, Nevil ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: +64 9 373 7599 x88941 CAIDA, San Diego On Mon, 24 Mar 2008, Romascanu, Dan (Dan) wrote: > I guess that what is meant here is actually draft-ietf-ipfix-mib-03.txt! > > Dan > > >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] >> On Behalf Of Nevil Brownlee >> Sent: Thursday, March 20, 2008 6:46 PM >> To: ipfix@ietf.org >> Subject: [IPFIX] WGLC starts for MIBl draft >> >> >> Hi all: >> >> As discussed at our meet ing in Philadelphia, this is the >> start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. >> >> Please read the draft, and send any comments/suggestions to >> the IPFIX list. Beter still, write a brief review of it and >> email that to me before the WGLC ends. >> >> This WGLC will end on Friday, 4 April 08 >> >> Cheers, Nevil >> >> -------------------------------------------From ipfix-bounces@ietf.org Mon Mar 24 09:29:03 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082213A6E90; Mon, 24 Mar 2008 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.281 X-Spam-Level: X-Spam-Status: No, score=-98.281 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH0rob4zg6tt; Mon, 24 Mar 2008 09:29:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC013A6E14; Mon, 24 Mar 2008 09:29:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297A13A6D47 for ; Mon, 24 Mar 2008 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GYQt5wl2TWp for ; Mon, 24 Mar 2008 09:28:56 -0700 (PDT) Received: from caida.org (rommie.caida.org [192.172.226.78]) by core3.amsl.com (Postfix) with ESMTP id 69DD23A6810 for ; Mon, 24 Mar 2008 09:28:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by caida.org (Postfix) with ESMTP id 9A1F4C06C; Mon, 24 Mar 2008 09:26:37 -0700 (PDT) Date: Mon, 24 Mar 2008 09:26:37 -0700 (PDT) From: Nevil Brownlee To: "Romascanu, Dan (Dan)" In-Reply-To: Message-ID: <20080324092611.D93042@rommie.caida.org> References: <47E294C6.2000901@auckland.ac.nz> MIME-Version: 1.0 Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] WGLC starts for MIBl draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Dan: Oops, yes, draft-ietf-ipfix-mib-03.txt it is. Thanks, Nevil ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: +64 9 373 7599 x88941 CAIDA, San Diego On Mon, 24 Mar 2008, Romascanu, Dan (Dan) wrote: > I guess that what is meant here is actually draft-ietf-ipfix-mib-03.txt! > > Dan > > >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] >> On Behalf Of Nevil Brownlee >> Sent: Thursday, March 20, 2008 6:46 PM >> To: ipfix@ietf.org >> Subject: [IPFIX] WGLC starts for MIBl draft >> >> >> Hi all: >> >> As discussed at our meet ing in Philadelphia, this is the >> start of the Working Group Las Call for draft-dietz-ipfix-mib-03.txt. >> >> Please read the draft, and send any comments/suggestions to >> the IPFIX list. Beter still, write a brief review of it and >> email that to me before the WGLC ends. >> >> This WGLC will end on Friday, 4 April 08 >> >> Cheers, Nevil >> >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix -------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Mar 28 11:21:03 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC363A7030; Fri, 28 Mar 2008 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.254 X-Spam-Level: X-Spam-Status: No, score=-100.254 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8m994BJInZB; Fri, 28 Mar 2008 11:21:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8263A3A6D3F; Fri, 28 Mar 2008 11:20:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343273A6C83 for ; Fri, 28 Mar 2008 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJL6AXc0tvaI for ; Fri, 28 Mar 2008 11:20:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 563FA3A6D84 for ; Fri, 28 Mar 2008 11:20:13 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 19:20:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 28 Mar 2008 19:20:00 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: missing notes on exporting type... thread-index: AciQcI5h96trXCZ/RImauSizFQyouAATgMmA References: From: To: X-OriginalArrivalTime: 28 Mar 2008 18:20:02.0455 (UTC) FILETIME=[56EE6270:01C89100] Cc: ipfix@ietf.org Subject: Re: [IPFIX] missing notes on exporting type... X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019705049==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1019705049== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89100.564C009A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89100.564C009A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, The way the draft-ietf-ipfix-exporting-type defines types prevents = adding new one in the future without updating the draft. There are = already potential candidates: Enumerated, email, DNS, URL ....=20 Adding these types to the IPFIX datamodel increases the scope of usage = of IPFIX and interoperability. It permits the usage of standard IE for = exporting specific information. It permits the collector to store this = information in an efficient way. It encourage enterprises to use = standard IE instead From ipfix-bounces@ietf.org Fri Mar 28 11:21:03 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC363A7030; Fri, 28 Mar 2008 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.254 X-Spam-Level: X-Spam-Status: No, score=-100.254 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8m994BJInZB; Fri, 28 Mar 2008 11:21:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8263A3A6D3F; Fri, 28 Mar 2008 11:20:18 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343273A6C83 for ; Fri, 28 Mar 2008 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJL6AXc0tvaI for ; Fri, 28 Mar 2008 11:20:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 563FA3A6D84 for ; Fri, 28 Mar 2008 11:20:13 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 19:20:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 28 Mar 2008 19:20:00 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: missing notes on exporting type... thread-index: AciQcI5h96trXCZ/RImauSizFQyouAATgMmA References: From: To: X-OriginalArrivalTime: 28 Mar 2008 18:20:02.0455 (UTC) FILETIME=[56EE6270:01C89100] Cc: ipfix@ietf.org Subject: Re: [IPFIX] missing notes on exporting type... X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019705049==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1019705049== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89100.564C009A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89100.564C009A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, The way the draft-ietf-ipfix-exporting-type defines types prevents = adding new one in the future without updating the draft. There are = already potential candidates: Enumerated, email, DNS, URL ....=20 Adding these types to the IPFIX datamodel increases the scope of usage = of IPFIX and interoperability. It permits the usage of standard IE for = exporting specific information. It permits the collector to store this = information in an efficient way. It encourage enterprises to use = standard IE instead of enterprises specific ones.=20 Therefore the draft has to define them as IEs and the IANA section have = to request IANA to add them the IPFIX datamodel registry. Regards Emile > -----Message d'origine----- > De : Brian Trammell [mailto:bht@cert.org] > Envoy=E9 : vendredi 28 mars 2008 02:11 > =C0 : STEPHAN Emile RD-CORE-LAN > Objet : missing notes on exporting type... >=20 > Emile, >=20 > As I recall, we had a conversation in Philadelphia about some specific > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > your question, and I was going to post a message to the list about > that... but, I can't seem to find my note on the subject, and it's > been a rather eventful couple of weeks, and I have consequently > _completely_ forgotten it. >=20 > So. >=20 > Would you happen to remember what we were talking about, so we could > perhaps start over on the subject? >=20 > Thanks, >=20 > Brian ------_=_NextPart_001_01C89100.564C009A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: missing notes on exporting type...

Hi = Brian,

The way the draft-ietf-ipfix-exporting-type defines types = prevents adding new one in = the future without = updating the draft. There are already potential candidates: Enumerated, email, DNS, = URL ....

Adding these types to the IPFIX datamodel increases -----Message d'origine----- > De : Brian Trammell [mailto:bht@cert.org] > Envoy=E9 : vendredi 28 mars 2008 02:11 > =C0 : STEPHAN Emile RD-CORE-LAN > Objet : missing notes on exporting type... >=20 > Emile, >=20 > As I recall, we had a conversation in Philadelphia about some specific > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > your question, and I was going to post a message to the list about > that... but, I can't seem to find my note on the subject, and it's > been a rather eventful couple of weeks, and I have consequently > _completely_ forgotten it. >=20 > So. >=20 > Would you happen to remember what we were talking about, so we could > perhaps start over on the subject? >=20 > Thanks, >=20 > Brian ------_=_NextPart_001_01C89100.564C009A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: missing notes on exporting type...

Hi = Brian,

The way the draft-ietf-ipfix-exporting-type defines types = prevents adding new one in = the future without = updating the draft. There are already potential candidates: Enumerated, email, DNS, = URL ....

Adding these types to the IPFIX datamodel increases the scope of usage = of IPFIX and interoperability. It permits the = usage of standard = IE for exporting specific information. It permits = the collector to store this information in an efficient = way. It encourage = enterprises to use standard IE instead of enterprises specific ones.

Therefore the draft = has to define them as IEs and the IANA section have = to request IANA to add them the IPFIX datamodel = registry.

Regards

Emile

> = -----Message = d'origine-----

> = De=/SPAN> the scope of usage = of IPFIX and interoperability. It permits the = usage of standard = IE for exporting specific information. It permits = the collector to store this information in an efficient = way. It encourage = enterprises to use standard IE instead of enterprises specific ones.

Therefore the draft = has to define them as IEs and the IANA section have = to request IANA to add them the IPFIX datamodel = registry.

Regards

Emile

> = -----Message = d'origine-----

> = De=A0: Brian Trammell [mailto:bht@cert.org]

> = Envoy=E9=A0: = vendredi 28 mars 2008 02:11

> = =C0=A0: = STEPHAN Emile = RD-CORE-LAN

> = Objet=A0: missing notes on exporting = type...

>

> Emile,

>

> As I recall, we had a conversation in Philadelphia = about some specific

> aspect of draft-ietf-ipfix-exporting-type, and I = had an answer for

> your question, and I was going to post a = message to the list = about

> that... but, I can't seem to find my note on the = subject, and it's

> been a rather eventful couple of weeks, and I have = consequently

> _completely_ forgotten it.

>

> So.

>

> Would you happen to remember what we were talking = about, so we could

> Brian Trammell [mailto:bht@cert.org]

> = Envoy=E9=A0: = vendredi 28 mars 2008 02:11

> = =C0=A0: = STEPHAN Emile = RD-CORE-LAN

> = Objet=A0: missing notes on exporting = type...

>

> Emile,

>

> As I recall, we had a conversation in Philadelphia = about some specific

> aspect of draft-ietf-ipfix-exporting-type, and I = had an answer for

> your question, and I was going to post a = message to the list = about

> that... but, I can't seem to find my note on the = subject, and it's

> been a rather eventful couple of weeks, and I have = consequently

> _completely_ forgotten it.

>

> So.

>

> Would you happen to remember what we were talking = about, so we could

> perhaps start over on the = subject?

>

> Thanks,

>

> Brian

------_=_NextPart_001_01C89100.564C009A-- --===============1019705049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1019705049==-- ANG=3D"en-us"> perhaps start over on the = subject?

>

> Thanks,

>

> Brian

------_=_NextPart_001_01C89100.564C009A-- --===============1019705049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1019705049==-- From ipfix-bounces@ietf.org Fri Mar 28 11:58:36 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7902A28C476; Fri, 28 Mar 2008 11:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-1.891, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSOqTwkVoQir; Fri, 28 Mar 2008 11:58:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC083A6E14; Fri, 28 Mar 2008 11:58:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C91B3A6E4D for ; Fri, 28 Mar 2008 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8iZf2CJjgTk for ; Fri, 28 Mar 2008 11:58:32 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id D275A3A6A6F for ; Fri, 28 Mar 2008 11:58:31 -0700 (PDT) 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 m2SIwMSI001759 for ; Fri, 28 Mar 2008 14:58:22 -0400 Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-21.remote.cert.org [10.25.4.21]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2SIwLSl011543 for ; Fri, 28 Mar 2008 14:58:21 -0400 Message-Id: From: Brian Trammell To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 14:58:21 -0400 X-Mailer: Apple Mail (2.919.2) Subject: [IPFIX] CFP: First ACM Workshop on Network Data Anonymization X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Greetings, Thought this might be of interest to many of you... The First ACM Workshop on Network Data Anonymization will be held in conjunction with CCS'08 in Alexandria, Virginia, 31 October 2008. We'd like to invite anyone doing work in this area to submit to the workshop; the call for papers appears below. Cheers, Brian CALL FOR PAPERS ------------------------------------------- Network Data Anonymization (NDA) Workshop An ACM CCS workshop October 31, 2008 Alexandria, VA, USA http://www.ics.forth.gr/~antonat/nda08.html -------------------------------------------- Over the last decade, the network security community (and the Internet measurement community in general) has suffered from two fundamental and related problems: (1) a lack of "real" network data for research studies and prototype testing, and (2) a lack of network data sharing among organizations, which impedes cooperation in network defense; as attacks typically cross organizational boundaries, effective prevention requires defenders to look beyond their own perimeter in cooperation with other organizations. Anonymization techniques are crucial for the safe sharing of network data. They are necessary to obscure certain identifying information (e.g., IP addresses) in order to protect the privacy of end users and the security of internal networks. While current network data anonymization techniques are generally acknowledged to be useful, it is difficult to ensure they are free from information leakage. Also, anonymization involves fundamental tradeoffs between the protection of user privacy and the utility of the resulting data, and these tradeoffs need to be better understood. This workshop seeks to focus on new and innovative solutions for anonymizing network data that will ensure appropriate protection of host identities, network configurations, and network security practices within enterprise networks. Topics may include, but are not limited to, the following: - data sharing via anonymization - privacy-preserving data mining - data anonymization tools - data anonymization policy creation/implementation - data anonymization case studies/best practices - streaming data anonymization - anonymization issues specific to network data - business services enabled by anonymization - data protection laws relevant to data anonymization Papers submitted documenting attacks on anonymized systems are strongly encouraged to propose a corresponding protection solution. While the focus of this workshop is on network data anonymization, applications of anonymization to other data domains ( e.g., medical data, homeland security, reputation systems, government records, transportation etc.) are welcome if the authors include a statement of relevance. ---------------- Important Dates: ---------------- Paper submissions due: Sunday, May 25, 2008 Author notification: Monday, July 7, 2008 Camera ready papers due: Sunday, August 10, 2008 Workshop at CCS '08: Friday, October 31, 2008 --------------------- Organizing Committee: --------------------- Bill Yurcik, University of Texas at Dallas (USA) [Program Chair] Spiros Antonatos, ICS-FORTH (Greece) Michele Bezzi, SAP Research (France) Elisa Boschi, Hitachi Europe (Switzerland) Brian Trammell, CERT/NetSA (USA) ---------------------------- Technical Program Committee: ---------------------------- Nikita Borisov, University of Illinois at Urbana-Champaign (USA) Matthias Bossardt, KPMG (Switzerland) Nevil Brownlee, CAIDA/University of Auckland (New Zealand) k claffy, CAIDA/University of California San Diego (USA) Michael Collins, CERT/NetSA (USA) Marco Cremonini, University of Milan (Italy) Michalis Foukarakis, ICS-FORTH (Greece) Carrie Gates, CA Labs (USA) David Maltz, Microsoft (USA) John McHugh, Dalhousie University (Canada) Ruoming Pang, Google (USA) Stefano Paraboschi, University of Bergamo (Italy) Dave Plonka, University of Wisconsin at Madison (USA) Carsten Schmoll, Fraunhofer FOKUS (Germany) Tim Shimeall, CERT/NetSA (USA) Panos Trimintzios, European Network and Information Security Agency (Greece) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Mar 28 11:58:36 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7902A28C476; Fri, 28 Mar 2008 11:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-1.891, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSOqTwkVoQir; Fri, 28 Mar 2008 11:58:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC083A6E14; Fri, 28 Mar 2008 11:58:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C91B3A6E4D for ; Fri, 28 Mar 2008 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8iZf2CJjgTk for ; Fri, 28 Mar 2008 11:58:32 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id D275A3A6A6F for ; Fri, 28 Mar 2008 11:58:31 -0700 (PDT) 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 m2SIwMSI001759 for ; Fri, 28 Mar 2008 14:58:22 -0400 Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-21.remote.cert.org [10.25.4.21]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2SIwLSl011543 for ; Fri, 28 Mar 2008 14:58:21 -0400 Message-Id: From: Brian Trammell To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 14:58:21 -0400 X-Mailer: Apple Mail (2.919.2) Subject: [IPFIX] CFP: First ACM Workshop on Network Data Anonymization X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Greetings, Thought this might be of interest to many of you... The First ACM Workshop on Network Data Anonymization will be held in conjunction with CCS'08 in Alexandria, Virginia, 31 October 2008. We'd like to invite anyone doing work in this area to submit to the workshop; the call for papers appears below. Cheers, Brian CALL FOR PAPERS ------------------------------------------- Network Data Anonymization (NDA) Workshop An ACM CCS workshop October 31, 2008 Alexandria, VA, USA http://www.ics.forth.gr/~antonat/nda08.html -------------------------------------------- Over the last decade, the network security community (and the Internet measurement community in general) has suffered from two fundamental and related problems: (1) a lack of "real" network data for research studies and prototype testing, and (2) a lack of network data sharing among organizations, which impedes cooperation in network defense; as attacks typically cross organizational boundaries, effective prevention requires defenders to look beyond their own perimeter in cooperation with other organizations. Anonymization techniques are crucial for the safe sharing of network data. They are necessary to obscure certain identifying information (e.g., IP addresses) in order to protect the privacy of end users and the security of internal networks. While current network data anonymization techniques are generally acknowledged to be useful, it is difficult to ensure they are free from information leakage. Also, anonymization involves fundamental tradeoffs between the protection of user privacy and the utility of the resulting data, and these tradeoffs need to be better understood. This workshop seeks to focus on new and innovative solutions for anonymizing network data that will ensure appropriate protection of host identities, network configurations, and network security practices within enterprise networks. Topics may include, but are not limited to, the following: - data sharing via anonymization - privacy-preserving data mining - data anonymization tools - data anonymization policy creation/implementation - data anonymization case studies/best practices - streaming data anonymization - anonymization issues specific to network data - business services enabled by anonymization - data protection laws relevant to data anonymization Papers submitted documenting attacks on anonymized systems are strongly encouraged to propose a corresponding protection solution. While the focus of this workshop is on network data anonymization, applications of anonymization to other data domains ( e.g., medical data, homeland security, reputation systems, government records, transportation etc.) are welcome if the authors include a statement of relevance. ---------------- Important Dates: ---------------- Paper submissions due: Sunday, May 25, 2008 Author notification: Monday, July 7, 2008 Camera ready papers due: Sunday, August 10, 2008 Workshop at CCS '08: Friday, October 31, 2008 --------------------- Organizing Committee: --------------------- Bill Yurcik, University of Texas at Dallas (USA) [Program Chair] Spiros Antonatos, ICS-FORTH (Greece) Michele Bezzi, SAP Research (France) Elisa Boschi, Hitachi Europe (Switzerland) Brian Trammell, CERT/NetSA (USA) ---------------------------- Technical Program Committee: ---------------------------- Nikita Borisov, University of Illinois at Urbana-Champaign (USA) Matthias Bossardt, KPMG (Switzerland) Nevil Brownlee, CAIDA/University of Auckland (New Zealand) k claffy, CAIDA/University of California San Diego (USA) Michael Collins, CERT/NetSA (USA) Marco Cremonini, University of Milan (Italy) Michalis Foukarakis, ICS-FORTH (Greece) Carrie Gates, CA Labs (USA) David Maltz, Microsoft (USA) John McHugh, Dalhousie University (Canada) Ruoming Pang, Google (USA) Stefano Paraboschi, University of Bergamo (Italy) Dave Plonka, University of Wisconsin at Madison (USA) Carsten Schmoll, Fraunhofer FOKUS (Germany) Tim Shimeall, CERT/NetSA (USA) Panos Trimintzios, European Network and Information Security Agency (Greece) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Mar 28 14:57:43 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BD33A6EAC; Fri, 28 Mar 2008 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.545 X-Spam-Level: X-Spam-Status: No, score=-101.545 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJXuZvF+6BDG; Fri, 28 Mar 2008 14:57:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275B93A6D4A; Fri, 28 Mar 2008 14:57:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACCF3A6D44 for ; Fri, 28 Mar 2008 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKg3w2v60V62 for ; Fri, 28 Mar 2008 14:57:39 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 89AE33A6831 for ; Fri, 28 Mar 2008 14:57:38 -0700 (PDT) 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 m2SLvGA2021990 for ; Fri, 28 Mar 2008 17:57:16 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2SLuW57021867 for ; Fri, 28 Mar 2008 17:56:32 -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 m2SLuVOv021865; Fri, 28 Mar 2008 17:56:31 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-21.remote.cert.org [10.25.4.21]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2SLuV4t018545; Fri, 28 Mar 2008 17:56:31 -0400 Message-Id: From: Brian Trammell To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 17:56:31 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile, Ah, yes. Thanks. I remember now. My short, short answer on this was = "no, but..." Here's why: The data type and semantics registries are taken directly from RFC = 5102. This document doesn't seek to expand the types or semantics, it = only seeks to create formal IANA registries for a list of types = _already_ defined on the standards track. The reason behind creating = those registries is to map the types themselves to numeric cFrom ipfix-bounces@ietf.org Fri Mar 28 14:57:43 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BD33A6EAC; Fri, 28 Mar 2008 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.545 X-Spam-Level: X-Spam-Status: No, score=-101.545 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJXuZvF+6BDG; Fri, 28 Mar 2008 14:57:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275B93A6D4A; Fri, 28 Mar 2008 14:57:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACCF3A6D44 for ; Fri, 28 Mar 2008 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKg3w2v60V62 for ; Fri, 28 Mar 2008 14:57:39 -0700 (PDT) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by core3.amsl.com (Postfix) with ESMTP id 89AE33A6831 for ; Fri, 28 Mar 2008 14:57:38 -0700 (PDT) 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 m2SLvGA2021990 for ; Fri, 28 Mar 2008 17:57:16 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m2SLuW57021867 for ; Fri, 28 Mar 2008 17:56:32 -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 m2SLuVOv021865; Fri, 28 Mar 2008 17:56:31 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-21.remote.cert.org [10.25.4.21]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m2SLuV4t018545; Fri, 28 Mar 2008 17:56:31 -0400 Message-Id: From: Brian Trammell To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 17:56:31 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile, Ah, yes. Thanks. I remember now. My short, short answer on this was = "no, but..." Here's why: The data type and semantics registries are taken directly from RFC = 5102. This document doesn't seek to expand the types or semantics, it = only seeks to create formal IANA registries for a list of types = _already_ defined on the standards track. The reason behind creating = those registries is to map the types themselves to numeric codes used = to represent them in the informationElementDataType and = informationElementSemantics IEs. The reason behind declaring their = modification to be subject to a Standards Action as per RFC 2434 is to = ensure that Adding a new data type to IPFIX is not simply a matter of sticking a = new name and number into the data type registry -- specific = information on the definition (as in section 3.1 of RFC 5102) and = encoding (as in section 6.1 of RFC 5101) of the data type must be = provided to allow the Exporting Process to properly encode and the = Collecting Process to properly decode and recognize data of that type. = Even if it's just a reference to an external standard (as 5101's = sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), = it's still absolutely necessary to have some document extending the = set of types for IPFIX to ensure interoperability of those new types. = And that's out of scope for _this_ document, which, as chartered, only = provides a _mechanism_ for describing the types already supported. That said, you have a very good point. There are quite a few types that could be immediately useful; and yes, = additional network-identifiers such as URL, email, and FQDN are = obvious first choices, which can only be implemented as Strings at the = moment. Enumerations are another issue, and can already be partially = implemented using the Reducing Redundancy mechanism. My suggestion, however, would be a new document, to be considered for = a future WG charter, to _explicitly_ extend the set of types supported = by IPFIX, and adding those types to the registry created in exporting- = type. Cheers, Brian On Mar 28, 2008, at 2:20 PM, wrote: > Hi Brian, > > The way the draft-ietf-ipfix-exporting-type defines types prevents = > adding new one in the future without updating the draft. There are = > already potential candidates: Enumerated, email, DNS, URL .... > > Adding these types to the IPFIX datamodel increases the scope of = > usage of IPFIX and interoperability. It permits the usage of = > standard IE for exporting specific information. It permits the = > collector to store this information in an efficient way. It = > encourage enterprises to use standard IE instead of enterprises = > specific ones. > > > Therefore the draft has to define them as IEs and the IANA section = > have to request IANA to add them the IPFIX datamodel registry. > > > Regards > > Emile > > > > -----Message d'origine----- > > > De : Brian Trammell [mailto:bht@cert.org] > > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > =C0 : STEPHAN Emile RD-CORE-LAN > > > Objet : missing notes on exporting type... > > > > > > Emile, > > > > > > As I recall, we had a conversation in Philadelphia about some = > specific > > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > > > your question, and I was going to post a message to the list about > > > that... but, I can't seem to find my note on the subject, and it's > > > been a rather eventful couple of weeks, and I have consequently > > > _completely_ forgotten it. > > > > > > So. > > > > > > Would you happen to remember what we were talking about, so we could > > > perhaps start over on the subject? > > > > > > Thanks, > > > > > > Brian > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix odes used = to represent them in the informationElementDataType and = informationElementSemantics IEs. The reason behind declaring their = modification to be subject to a Standards Action as per RFC 2434 is to = ensure that Adding a new data type to IPFIX is not simply a matter of sticking a = new name and number into the data type registry -- specific = information on the definition (as in section 3.1 of RFC 5102) and = encoding (as in section 6.1 of RFC 5101) of the data type must be = provided to allow the Exporting Process to properly encode and the = Collecting Process to properly decode and recognize data of that type. = Even if it's just a reference to an external standard (as 5101's = sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), = it's still absolutely necessary to have some document extending the = set of types for IPFIX to ensure interoperability of those new types. = And that's out of scope for _this_ document, which, as chartered, only = provides a _mechanism_ for describing the types already supported. That said, you have a very good point. There are quite a few types that could be immediately useful; and yes, = additional network-identifiers such as URL, email, and FQDN are = obvious first choices, which can only be implemented as Strings at the = moment. Enumerations are another issue, and can already be partially = implemented using the Reducing Redundancy mechanism. My suggestion, however, would be a new document, to be considered for = a future WG charter, to _explicitly_ extend the set of types supported = by IPFIX, and adding those types to the registry created in exporting- = type. Cheers, Brian On Mar 28, 2008, at 2:20 PM, wrote: > Hi Brian, > > The way the draft-ietf-ipfix-exporting-type defines types prevents = > adding new one in the future without updating the draft. There are = > already potential candidates: Enumerated, email, DNS, URL .... > > Adding these types to the IPFIX datamodel increases the scope of = > usage of IPFIX and interoperability. It permits the usage of = > standard IE for exporting specific information. It permits the = > collector to store this information in an efficient way. It = > encourage enterprises to use standard IE instead of enterprises = > specific ones. > > > Therefore the draft has to define them as IEs and the IANA section = > have to request IANA to add them the IPFIX datamodel registry. > > > Regards > > Emile > > > > -----Message d'origine----- > > > De : Brian Trammell [mailto:bht@cert.org] > > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > =C0 : STEPHAN Emile RD-CORE-LAN > > > Objet : missing notes on exporting type... > > > > > > Emile, > > > > > > As I recall, we had a conversation in Philadelphia about some = > specific > > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > > > your question, and I was going to post a message to the list about > > > that... but, I can't seem to find my note on the subject, and it's > > > been a rather eventful couple of weeks, and I have consequently > > > _completely_ forgotten it. > > > > > > So. > > > > > > Would you happen to remember what we were talking about, so we could > > > perhaps start over on the subject? > > > > > > Thanks, > > > > > > Brian > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix