From paitken@cisco.com Wed Aug 1 04:18:07 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7594221F86D5 for ; Wed, 1 Aug 2012 04:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.496 X-Spam-Level: X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnMnUbT1u-2a for ; Wed, 1 Aug 2012 04:18:06 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E921F86D6 for ; Wed, 1 Aug 2012 04:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3014; q=dns/txt; s=iport; t=1343819886; x=1345029486; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q4A6PXj9wLmPwomCVIM4OPvC+BfxbIczZ19jPyv1bxI=; b=hQwrdF/JQF4bE4QonwBPLs+Kq80aaPaXVeFzQ7SsKlfdqcxqKnGcGFuq hvPApIPNmXQyFVfxgm+/ZN4D60pTrq5CPit6Y7srKv+15UyUF7fXxOWbm RQriRg5orR+rKgM/zDFEVlPwUL0sAQkQOt3BHKiJmrXVWiEcBBOBekYdJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMQACcQGVCQ/khL/2dsb2JhbABFsVyDfYNCgQeCIAEBAQQSASVAARALGAkWDwkDAgECAUUGDQEHAQEXB4drnDGgTYtJJ4ZiA5VHhVuITIFmgmCBVw X-IronPort-AV: E=Sophos;i="4.77,693,1336348800"; d="scan'208";a="7055740" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 01 Aug 2012 11:18:05 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71BI5fo004336; Wed, 1 Aug 2012 11:18:05 GMT Message-ID: <5019106C.9080905@cisco.com> Date: Wed, 01 Aug 2012 12:18:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian Trammell References: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> <5007FA93.2090004@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IE-doctors: transitioning IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 11:18:07 -0000 Brian, What is the conclusion to this? ie, do you want to rework ie-doctors, and I'll polish and publish my -00 for IE equivalence? P. On 19/07/12 13:45, Brian Trammell wrote: > Hi, Paul, > > I'm not much of a fan of sticking enterprise-specific references in the registry, actually. It was suggested that this is a problem (indeed, I believe it is), and this is indeed a solution to it -- but it seems like a much cleaner mechanism for doing this would be to allow the actual devices doing the exporting to annotate the output data with an IE map (much like type information export as in RFC 5610). > > One clarifying point: the Collecting Process, of course, needs to be updated too, in order to understand the Options providing the IE map. But this only happens once, as opposed to the registry-based solution which requires the CP to be regularly updated (or to automatically query) the IANA registry. > > Removing a whole column and subset of sections from the ie-doctors at this late date may be a little problematic procedurally; I'm not sure of the right thing to do, and would turn to our chairs and AD for guidance... > > Cheers, > > Brian > > > On Jul 19, 2012, at 2:16 PM, Paul Aitken wrote: > >> Brian, >> >> In my IE-doctors reviews, I expressed some reservation about recording Enterprise-Specific information in IANA's IPFIX registry as specified in this text: >> >> In order to support transition from experimental registration to IANA >> registration, the IANA registry provides an optional "enterprise- >> specific IE reference" column for each Information Element. In cases >> of promoted enterprise-specific Information Elements, this column in >> the registry SHOULD contain the private enterprise and Information >> Element numbers of the enterprise-specific version of the Information >> Element. >> >> >> I've had a similar, but automated, idea in the back of my mind to for some years: an upgraded device could export a table mapping oldIE to newIE, where either of these IEs can be IANA standard or Enterprise Specific. >> >> The table would be interpreted as "(if) I used to export oldIE, now I export newIE", so the Collecting Process can readily re-map exported data over the Exporting Process software change boundary. If the Collecting Process never received any oldIE elements, it can disregard the information. >> >> With the IE doctors / IANA registry idea, the information has to be in the registry and the Collecting Process has to have read the new registry. So both the Exporting Process and Collecting Process must be updated. >> >> With my idea, only the Exporting Process is updated, and it informs the Collecting Process. >> >> I drafted a -00 on this last year which requires a little more work, so I've not published it yet. >> >> Of course the two mechanisms are complementary rather than mutually exclusive. It's a question of which issues we're trying to solve. >> >> P. >> >> From paitken@cisco.com Wed Aug 1 04:19:30 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C121F86D9 for ; Wed, 1 Aug 2012 04:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZBziexXmpdq for ; Wed, 1 Aug 2012 04:19:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7B21F86D5 for ; Wed, 1 Aug 2012 04:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2457; q=dns/txt; s=iport; t=1343819969; x=1345029569; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0WvkVHh+wjYu8LYPsuE/yB2rSG53jpdpUTvcDWjy0+c=; b=aBFcHRZjPNe8rJaBsaoambiFerPMocJqjB7CNZNdUN+YQGoKorg6UP2m 2DK/dIQiwVWKMcFX0wBnnFDRnHzQmrvljqob/p1E1/NFhFYb5vE0VqmLy uV6hayJsHJ0qELYxw+KQs9q/Ox4r0AULwsS2y3oTwExTUcKOaD/bTEVvG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYQAN4PGVCQ/khL/2dsb2JhbABFsVyHP4EHgiABAQEEAQEBDwElMwMKARALGAkMCg8JAwIBAgEVMAYNAQUCAQEVCYdrC5wmoEsEi0mDYYMoA5VHhVuITIFmgmCBVQc X-IronPort-AV: E=Sophos;i="4.77,693,1336348800"; d="scan'208";a="75713136" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Aug 2012 11:19:28 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71BJSVo004655; Wed, 1 Aug 2012 11:19:28 GMT Message-ID: <501910BF.4050508@cisco.com> Date: Wed, 01 Aug 2012 12:19:27 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian Trammell References: <5005D329.8060509@cisco.com> <87A0FD38-83A1-464E-8898-65FFEC9B12FA@tik.ee.ethz.ch> <50081B48.7030704@plixer.com> <0AB730D8-6F83-4E95-8E17-0301FA317564@tik.ee.ethz.ch> In-Reply-To: <0AB730D8-6F83-4E95-8E17-0301FA317564@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 11:19:30 -0000 Brian, Andrew, What was the conclusion here? Please get some time to discuss this in the WG meeting. Thanks, P. On 19/07/12 15:45, Brian Trammell wrote: > Hi, Andrew, > > Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error. > > Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status? > > Cheers, > > Brian > > On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: > >> On 07/19/2012 05:01 AM, Brian Trammell wrote: >> >> [ snip ] >>>>> After a period of time determined in the eyes >>>>> of the IE-DOCTORS experts to be reasonable in order to allow deployed >>>>> Exporting Processes to be updated to account for the deprecation, a >>>>> deprecated Information Element may be made obsolete. Obsolete >>>>> Information Elements MUST NOT be supported by either Exporting or >>>>> Collecting Processes. The receipt of obsolete Information Elements >>>> ** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so. >>> "MUST NOT be supported by new implementations of either Exporting or Collecting Processes"? >>> >>> The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs. >>> >>> >> I have to side with Paul on this one. Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle. An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much. >> >> To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks. >> >> -Andrew >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Aug 1 05:19:25 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B0721F8BE2 for ; Wed, 1 Aug 2012 05:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMAXintfMU8M for ; Wed, 1 Aug 2012 05:19:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id EEAF921F8B4F for ; Wed, 1 Aug 2012 05:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2222; q=dns/txt; s=iport; t=1343823564; x=1345033164; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=vQYO5HBp2M8uX4JOVb1fpoktod8IxTBsq51wdfxh8xk=; b=eNg2K6uaidC2CikhwVlRSDOpYZ5vAUf8PtfsD/LILA/tPCGIgQdnAxIo smTgs4WpPAQFp8xWl18qeEQP7wi5WoazRawQloILbd5FZvGJcmeVU2HD6 af/UKu16qxrLysjBbpwUGnwafuv0BIYxOqn7ytVhI0UPBizRvZWoTLHoH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALAdGVCQ/khL/2dsb2JhbABFuRuBB4I5AR8BBS8EDT0WGAMCAQIBSw0IAQEeh2ubB4EooFCCQpAQA5VHhVuITIFmgmA X-IronPort-AV: E=Sophos;i="4.77,693,1336348800"; d="scan'208";a="141883573" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2012 12:19:22 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71CJMZr016638 for ; Wed, 1 Aug 2012 12:19:22 GMT Message-ID: <50191ECA.9050301@cisco.com> Date: Wed, 01 Aug 2012 13:19:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [IPFIX] sectionOffset and sectionObservedOctets X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:19:25 -0000 Dear IPFIX experts, draft-ietf-ipfix-data-link-layer-monitoring-00 defines two new Information Elements: sectionOffset This Information Element specifies the offset of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and mplsPayloadPacketSection). If this Information Element is omitted, it defaults to zero. sectionObservedOctets This Information Element specifies the observed length of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and mplsPayloadPacketSection) when padding is used. The packet section may be of a fixed size larger than the sectionObservedOctets. In this case, octets in the packet section beyond the sectionObservedOctets MUST follow the [RFC5101] rules for padding (ie, be composed of zero (0) valued octets). These are intended for use in conjunction with the new "dataLinkFrameSection" Information Element: dataLinkFrameSection This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame. The sectionObservedOctets expresses how much data was observed, while the remainder is padding. Clearly sectionOffset and sectionObservedOctets can apply to all kinds of packet section, not just dataLinkFrameSection. ie, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection. So I'm looking for WG feedback on the best way forward: 1: modify the existing packet section Information Elements Descriptions (in a backwards compatible way) to include sectionOffset and sectionObservedOctets. 2: deprecate the existing packet section Information Elements and create new Information Elements which include sectionOffset and sectionObservedOctets. 3: sectionOffset and sectionObservedOctets don’t apply to existing packet section Information Elements. I'll raise this issue while discussing the draft in the WG meeting Thanks, P. From trammell@tik.ee.ethz.ch Wed Aug 1 14:17:46 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EABC11E832B for ; Wed, 1 Aug 2012 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMwoC0S+YxQj for ; Wed, 1 Aug 2012 14:17:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FD11E8314 for ; Wed, 1 Aug 2012 14:17:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0BACAD930A; Wed, 1 Aug 2012 23:17:34 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zVMzrc0tWlyR; Wed, 1 Aug 2012 23:17:33 +0200 (MEST) Received: from dhcp-90b1.meeting.ietf.org (dhcp-90b1.meeting.ietf.org [130.129.8.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4FD10D9300; Wed, 1 Aug 2012 23:17:33 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <50191ECA.9050301@cisco.com> Date: Wed, 1 Aug 2012 14:17:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <498BD65A-DE3A-4DC6-B3D7-906981DD407B@tik.ee.ethz.ch> References: <50191ECA.9050301@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] sectionOffset and sectionObservedOctets X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:17:47 -0000 Hi, Paul, all, To start the discussion: Actually, these make so much sense that I had to check the registry to = make sure they weren't already there, and was surprised to find they're = not.=20 As for the sectionObservedOctets, it would be nice if it was made = clearer that the observed octets reported is regardless of the offset... I'd be in favor of option 1 -- I think the changes to = ipHeaderPacketSection can be made backward-compatible. Best regards, Brian On Aug 1, 2012, at 5:19 AM, Paul Aitken wrote: > Dear IPFIX experts, >=20 > draft-ietf-ipfix-data-link-layer-monitoring-00 defines two new = Information Elements: >=20 > sectionOffset >=20 > This Information Element specifies the offset of the packet > section (e.g., dataLinkFrameSection, ipHeaderPacketSection, > ipPayloadPacketSection, mplsLabelStackSection and > mplsPayloadPacketSection). If this Information Element is > omitted, it defaults to zero. >=20 >=20 > sectionObservedOctets >=20 > This Information Element specifies the observed length of the > packet section (e.g., dataLinkFrameSection, = ipHeaderPacketSection, > ipPayloadPacketSection, mplsLabelStackSection and > mplsPayloadPacketSection) when padding is used. >=20 > The packet section may be of a fixed size larger than the > sectionObservedOctets. In this case, octets in the packet = section > beyond the sectionObservedOctets MUST follow the [RFC5101] rules > for padding (ie, be composed of zero (0) valued octets). >=20 >=20 > These are intended for use in conjunction with the new = "dataLinkFrameSection" Information Element: >=20 > dataLinkFrameSection >=20 > This Information Element carries n octets from the data link = frame > of a selected frame, starting sectionOffset octets into the = frame. >=20 > The sectionObservedOctets expresses how much data was observed, > while the remainder is padding. >=20 >=20 > Clearly sectionOffset and sectionObservedOctets can apply to all kinds = of packet section, not just dataLinkFrameSection. >=20 > ie, ipHeaderPacketSection, ipPayloadPacketSection, = mplsLabelStackSection, mplsPayloadPacketSection. >=20 >=20 > So I'm looking for WG feedback on the best way forward: >=20 > 1: modify the existing packet section Information Elements = Descriptions (in a backwards compatible way) to include sectionOffset = and sectionObservedOctets. >=20 > 2: deprecate the existing packet section Information Elements and = create new Information Elements which include sectionOffset and = sectionObservedOctets. >=20 > 3: sectionOffset and sectionObservedOctets don=92t apply to existing = packet section Information Elements. >=20 >=20 > I'll raise this issue while discussing the draft in the WG meeting >=20 > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Aug 1 14:26:17 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385C21F8A11 for ; Wed, 1 Aug 2012 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmLDyHLpQHaX for ; Wed, 1 Aug 2012 14:26:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 17BB521F8A10 for ; Wed, 1 Aug 2012 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3109; q=dns/txt; s=iport; t=1343856376; x=1345065976; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ra3BTenOAQC9V4RovK6h9f0wYxThqW5G//uWGw1UaGs=; b=QxKJaExCa9tTRr4v0LdcE8Jdi7m0p4/ZPN3l/LN0gCRLMFc22gBFLsja GxdH2003YS2icIBTnZKcOUPX47C/k1HPxCZzd9TXpI94pzE9NQxMdKBAH pT2fzagPhj459SCl2MJhYxAj513vWKH5TLP3om/2g94r6e6OrT48GTG1k k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMWdGVCQ/khL/2dsb2JhbABFuRGBB4IgAQEBAwEBAQEPAR8BBS8EAwoBBQsLGAkWDwkDAgECARUwBg0BBQIBAR6HZQYLnHqgPgSCQokHhwkDlUeFW4hMgWaCYA X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="141907843" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2012 21:26:14 +0000 Received: from [10.55.81.152] (dhcp-10-55-81-152.cisco.com [10.55.81.152]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71LQEJG023098; Wed, 1 Aug 2012 21:26:14 GMT Message-ID: <50199EF6.2090503@cisco.com> Date: Wed, 01 Aug 2012 22:26:14 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian Trammell References: <50191ECA.9050301@cisco.com> <498BD65A-DE3A-4DC6-B3D7-906981DD407B@tik.ee.ethz.ch> In-Reply-To: <498BD65A-DE3A-4DC6-B3D7-906981DD407B@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] sectionOffset and sectionObservedOctets X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:26:17 -0000 Brian, > Hi, Paul, all, > > To start the discussion: > > Actually, these make so much sense that I had to check the registry to make sure they weren't already there, and was surprised to find they're not. :-) > As for the sectionObservedOctets, it would be nice if it was made clearer that the observed octets reported is regardless of the offset... Great point, will do. > I'd be in favor of option 1 -- I think the changes to ipHeaderPacketSection can be made backward-compatible. Great. I'll propose some example text in one of my slides. Thanks, P. > On Aug 1, 2012, at 5:19 AM, Paul Aitken wrote: > >> Dear IPFIX experts, >> >> draft-ietf-ipfix-data-link-layer-monitoring-00 defines two new Information Elements: >> >> sectionOffset >> >> This Information Element specifies the offset of the packet >> section (e.g., dataLinkFrameSection, ipHeaderPacketSection, >> ipPayloadPacketSection, mplsLabelStackSection and >> mplsPayloadPacketSection). If this Information Element is >> omitted, it defaults to zero. >> >> >> sectionObservedOctets >> >> This Information Element specifies the observed length of the >> packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, >> ipPayloadPacketSection, mplsLabelStackSection and >> mplsPayloadPacketSection) when padding is used. >> >> The packet section may be of a fixed size larger than the >> sectionObservedOctets. In this case, octets in the packet section >> beyond the sectionObservedOctets MUST follow the [RFC5101] rules >> for padding (ie, be composed of zero (0) valued octets). >> >> >> These are intended for use in conjunction with the new "dataLinkFrameSection" Information Element: >> >> dataLinkFrameSection >> >> This Information Element carries n octets from the data link frame >> of a selected frame, starting sectionOffset octets into the frame. >> >> The sectionObservedOctets expresses how much data was observed, >> while the remainder is padding. >> >> >> Clearly sectionOffset and sectionObservedOctets can apply to all kinds of packet section, not just dataLinkFrameSection. >> >> ie, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection. >> >> >> So I'm looking for WG feedback on the best way forward: >> >> 1: modify the existing packet section Information Elements Descriptions (in a backwards compatible way) to include sectionOffset and sectionObservedOctets. >> >> 2: deprecate the existing packet section Information Elements and create new Information Elements which include sectionOffset and sectionObservedOctets. >> >> 3: sectionOffset and sectionObservedOctets don’t apply to existing packet section Information Elements. >> >> >> I'll raise this issue while discussing the draft in the WG meeting >> >> Thanks, >> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Wed Aug 1 23:12:40 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89A11E8122 for ; Wed, 1 Aug 2012 23:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydjc4PchXPlq for ; Wed, 1 Aug 2012 23:12:39 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC5FA11E811E for ; Wed, 1 Aug 2012 23:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1343887957; x=1375423957; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=VoYCloxCqGhGTuiOsLhOYMpSQ6LW/mH1SUmKEepHqos=; b=I+5Z1EHolhywLW9M1te2lJLS95swSRic3tJfnCY5soll04CxbYCXJJP7 NFjlzuzvBhchjoG9NfV1itt6Rs/Kz1EVMMH+aq7TNhEZVEn+Ic0eUFUVE 5CWIIhrQq1U6Fp8KjaGecZfhf1QAOApMtAAh4dwVFlh7+va6hVhRynRhe Y=; X-IronPort-AV: E=Sophos;i="4.77,698,1336305600"; d="scan'208";a="136399588" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 02 Aug 2012 18:12:33 +1200 Message-ID: <501A1A4F.807@auckland.ac.nz> Date: Thu, 02 Aug 2012 18:12:31 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for Vancouver meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 06:12:40 -0000 Hi all: Herewith the agenda for our meeting at IETF-84 in Vancouver on Thursday. This, together with all the slides for the meeting, are now on the meting materials page. Please note that the order has changed slightly! See you tomorow, Nevil =========================================== IP Flow Information Export WG (ipfix) Agenda for IETF 84, Paris (agenda-03) Thursday, 2 August, 1300-1500, Regency A =========================================== Chairs: (Juergen Quittek ) Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min IPFIX MIB RFC 6615 (Obsoletes 5815) published June 2012 IPFIX Configuration Model draft-ietf-ipfix-configuration-model-10, 18 Jul 11 Waiting on PSAMP MIB PSAMP MIB draft-ietf-ipfix-psamp-mib-06.txt, 10 Jul 12 Approved Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-11, 23 Apr 12 Authors working on new draft IPFIX Aggregation (Brian Trammell) draft-ietf-ipfix-a9n-05, 6 Jul 12 <<< Nevil to do write-up draft-claise-export-application-info-in-ipfix-09 has been sent to IESG as an Individual submission, currently has one DISCUSS 3. Current charter work items = 70 min a) IEs for Data Link Layer Traffic Measurement (Paul Aitken) draft-ipfix-data-link-layer-monitoring-00, 6 Jul 12 b) Exporting MIB objects (Paul Aitken) draft-ipfix-mib-variable-export-00, 6 Jul 12 c) Guidelines for Information Elements (Brian Trammell) draft-ietf-ipfix-ie-doctors-03, needs new version c) Information Model for IP Flow Information eXport (IPFIX) (Brian Trammell) draft-ietf-ipfix-information-model-rfc5102bis-03, 13 Jul 12 d) Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Brian Trammell) draft-ietf-ipfix-protocol-rfc5101bis-02, 28 Jun 12 e) Protocol for PFIX Mediation (Brian Trammell) draft-ietf-ipfix-mediation-protocol-02, 6 Jul 12 4. Other drafts (if time allows) = 20 min a) Reporting Unobserved Fields in IPFIX (Paul Aitken) draft-aitken-ipfix-unobserved-fields-01, 16 Jul 12 b) VoIP Information Elements in IPFIX (Hendrik Scholtz & Aamer Akhter) draft-akhter-opsawg-perfmon-ipfix-02, 27 Mar 12 draft-scholz-ipfix-rtp-audio-quality-00, 9 Jul 12 6. Any Other Business = 5 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=84 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org and via Meetecho, http://ietf84.conf.meetecho.com/index.php/Web_Client -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From andrewf@plixer.com Thu Aug 2 07:15:51 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5F11E80B8 for ; Thu, 2 Aug 2012 07:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcGqdLF5nDGH for ; Thu, 2 Aug 2012 07:15:50 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id DC20611E80AE for ; Thu, 2 Aug 2012 07:15:49 -0700 (PDT) Received: from [192.168.1.40] ([64.222.180.153]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 10:15:46 -0400 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 02 Aug 2012 09:56:07 -0400 From: Andrew Feren To: Paul Aitken Message-ID: Thread-Topic: [Sender: ipfix-bounces@ietf.org] Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3426747346_263181" X-OriginalArrivalTime: 02 Aug 2012 14:15:48.0767 (UTC) FILETIME=[50A20AF0:01CD70B9] Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:15:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3426747346_263181 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Paul, I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever). Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative). Exporter implementers should favour the more appropriate choice. Collector implementers may choose to support or not deprecated IEs. -Andrew On 08/01/2012 07:19 AM, Paul Aitken wrote: > Brian, Andrew, > > What was the conclusion here? > > Please get some time to discuss this in the WG meeting. > > Thanks, > P. > > > On 19/07/12 15:45, Brian Trammell wrote: > >> Hi, Andrew, >> >> Essentially, if this is the argument (which I'm not saying I disagree with), >> then we should drop obsolete as a status, and just stay with deprecated -- >> there's no point in distinguishing "don't use it" from "REALLY don't use it" >> unless we specify that use of deprecated IEs is a warning and use of obsolete >> IEs is an error. >> >> Especially since we'll never reclaim number or namespace anyway, why not >> just collapse to one "dead" status? >> >> Cheers, >> >> Brian >> >> On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: >> >> >>> On 07/19/2012 05:01 AM, Brian Trammell wrote: >>> >>> [ snip ] >>> >>>> >>>>> >>>>>> After a period of time determined in the eyes >>>>>> of the IE-DOCTORS experts to be reasonable in order to allow >>>>>> deployed >>>>>> Exporting Processes to be updated to account for the deprecation, a >>>>>> deprecated Information Element may be made obsolete. Obsolete >>>>>> Information Elements MUST NOT be supported by either Exporting or >>>>>> Collecting Processes. The receipt of obsolete Information Elements >>>>>> >>>>> ** ** Nope, not happening. I can't force my customers to upgrade just >>>>> because some 3rd party says so. >>>>> >>>> "MUST NOT be supported by new implementations of either Exporting or >>>> Collecting Processes"? >>>> >>>> The point here is that if we're going to support deprecation (which was >>>> clearly the intent of the WG, given its inclusion in 5102), there may be a >>>> mismatch between the deployed and specified environment WRT supported IEs. >>>> >>>> >>>> >>> I have to side with Paul on this one. Saying that a collecting process >>> MUST NOT support obsoleted IEs seems to me to violate the robustness >>> principle. An argument can be made that new exporters SHOULD / MUST NOT >>> send deprecated IEs, but I think more than that is too much. >>> >>> To give a specific example of the shelf life of the obsolete. Wikipedia >>> tells me that NetFlow v1 is obsolete (and it has been for years), but I >>> still see NetFlow v1 exports on some customer networks. >>> >>> -Andrew >>> _______________________________________________ >>> 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 >> > > > --B_3426747346_263181 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Paul,

I'm not sure there was a consensus, but my personal conclusion curren= tly is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a = bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collect= or implementers may choose to support or not deprecated IEs.

-Andrew

On 08/01/2012 07:19 AM, Paul Aitken wrote:
Brian, Andrew,

What was the conclusion here?

Please get some time to discuss this in the WG meeting.

Thanks,
P.


On 19/07/12 15:45, Brian Trammell wrote:
Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

On 07/19/2012 05:01 AM, Brian Trammell wrote:

[ snip ]
    After a period of = time determined in the eyes
    of the IE-DOCTORS experts to be reasonab= le in order to allow deployed
    Exporting Processes to be updated to acc= ount for the deprecation, a
    deprecated Information Element may be ma= de obsolete.  Obsolete
    Information Elements MUST NOT be support= ed by either Exporting or
    Collecting Processes.  The receipt = of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.


I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can be mad= e that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.

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



--B_3426747346_263181-- From paitken@cisco.com Thu Aug 2 07:52:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30511E8072 for ; Thu, 2 Aug 2012 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww8LVAcLc9aS for ; Thu, 2 Aug 2012 07:52:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 51BA821F86B7 for ; Thu, 2 Aug 2012 07:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=10506; q=dns/txt; s=iport; t=1343919116; x=1345128716; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+V7UFeq5Is2M1PYoot6Rnd3UNyH/jdy3CbXXYr1SQqA=; b=XxpX1cPBZxfYjLFzKOvsP6HBOREstpByi1PLlDcTrWaynxSdjNYl6tuo lYRrDRXIYcUtdMYHcodCKHWbfWuzTMAlAVfmRv2CU0Zj5BQaYd5kH0bGF YinMzP7m6+PyC3xeyaYsTCW28/sim8rKfaqvoEHV9aVZWp5wbcYpHRk+U g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIQAAiTGlCQ/khM/2dsb2JhbABFsV6HLoEHgiABAQEEAQEBDwFYAwoBEAsYCQwKDwkDAgECARUwBg0BBQIBARUJh2sLnG+gPgSLSYNcgygDlUeFW4hMgWaCYIFVBw X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208,217";a="141939791" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2012 14:51:55 +0000 Received: from [10.55.81.152] (dhcp-10-55-81-152.cisco.com [10.55.81.152]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72EprEv005245; Thu, 2 Aug 2012 14:51:53 GMT Message-ID: <501A940B.9060207@cisco.com> Date: Thu, 02 Aug 2012 15:51:55 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrew Feren References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060106040104010708060901" Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:52:04 -0000 This is a multi-part message in MIME format. --------------060106040104010708060901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you. Else you'll suddenly be unable to decode exports from all the un-updated devices in the field. There are many reasons why exporting devices might not be updated. P. On 02/08/12 14:56, Andrew Feren wrote: > Hi Paul, > > I'm not sure there was a consensus, but my personal conclusion > currently is that there should be a single bad state for IEs that > should be avoided (call it deprecated, obsolete, historical, > whatever). Ideally the description for any deprecated IEs will point > implementers in a more appropriate direction (or explain why it is a > bad idea and there is no alternative). Exporter implementers should > favour the more appropriate choice. Collector implementers may choose > to support or not deprecated IEs. > > -Andrew > > On 08/01/2012 07:19 AM, Paul Aitken wrote: >> Brian, Andrew, >> >> What was the conclusion here? >> >> Please get some time to discuss this in the WG meeting. >> >> Thanks, >> P. >> >> >> On 19/07/12 15:45, Brian Trammell wrote: >>> Hi, Andrew, >>> >>> Essentially, if this is the argument (which I'm not saying I >>> disagree with), then we should drop obsolete as a status, and just >>> stay with deprecated -- there's no point in distinguishing "don't >>> use it" from "REALLY don't use it" unless we specify that use of >>> deprecated IEs is a warning and use of obsolete IEs is an error. >>> >>> Especially since we'll never reclaim number or namespace anyway, why >>> not just collapse to one "dead" status? >>> >>> Cheers, >>> >>> Brian >>> >>> On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: >>> >>>> On 07/19/2012 05:01 AM, Brian Trammell wrote: >>>> >>>> [ snip ] >>>>>>> After a period of time determined in the eyes >>>>>>> of the IE-DOCTORS experts to be reasonable in order to allow >>>>>>> deployed >>>>>>> Exporting Processes to be updated to account for the >>>>>>> deprecation, a >>>>>>> deprecated Information Element may be made obsolete. Obsolete >>>>>>> Information Elements MUST NOT be supported by either >>>>>>> Exporting or >>>>>>> Collecting Processes. The receipt of obsolete Information >>>>>>> Elements >>>>>> ** ** Nope, not happening. I can't force my customers to upgrade >>>>>> just because some 3rd party says so. >>>>> "MUST NOT be supported by new implementations of either Exporting >>>>> or Collecting Processes"? >>>>> >>>>> The point here is that if we're going to support deprecation >>>>> (which was clearly the intent of the WG, given its inclusion in >>>>> 5102), there may be a mismatch between the deployed and specified >>>>> environment WRT supported IEs. >>>>> >>>>> >>>> I have to side with Paul on this one. Saying that a collecting >>>> process MUST NOT support obsoleted IEs seems to me to violate the >>>> robustness principle. An argument can be made that new exporters >>>> SHOULD / MUST NOT send deprecated IEs, but I think more than that >>>> is too much. >>>> >>>> To give a specific example of the shelf life of the obsolete. >>>> Wikipedia tells me that NetFlow v1 is obsolete (and it has been for >>>> years), but I still see NetFlow v1 exports on some customer networks. >>>> >>>> -Andrew >>>> _______________________________________________ >>>> 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 >> >> > --------------060106040104010708060901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated devices in the field.

There are many reasons why exporting devices might not be updated.

P.


On 02/08/12 14:56, Andrew Feren wrote:
Hi Paul,

I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

-Andrew

On 08/01/2012 07:19 AM, Paul Aitken wrote:
Brian, Andrew,

What was the conclusion here?

Please get some time to discuss this in the WG meeting.

Thanks,
P.


On 19/07/12 15:45, Brian Trammell wrote:
Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

On 07/19/2012 05:01 AM, Brian Trammell wrote:

[ snip ]
    After a period of time determined in the eyes
    of the IE-DOCTORS experts to be reasonable in order to allow deployed
    Exporting Processes to be updated to account for the deprecation, a
    deprecated Information Element may be made obsolete.  Obsolete
    Information Elements MUST NOT be supported by either Exporting or
    Collecting Processes.  The receipt of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.


I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.

-Andrew
_______________________________________________
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





--------------060106040104010708060901-- From andrewf@plixer.com Thu Aug 2 08:16:52 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6011E80A4 for ; Thu, 2 Aug 2012 08:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxQiexeP6Hjp for ; Thu, 2 Aug 2012 08:16:49 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D571D11E808E for ; Thu, 2 Aug 2012 08:16:48 -0700 (PDT) Received: from [192.168.1.40] ([64.222.180.153]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 11:16:47 -0400 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 02 Aug 2012 11:16:43 -0400 From: Andrew Feren To: Paul Aitken Message-ID: Thread-Topic: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review In-Reply-To: <501A940B.9060207@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3426751006_538304" X-OriginalArrivalTime: 02 Aug 2012 15:16:48.0356 (UTC) FILETIME=[D5EB0240:01CD70C1] Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:16:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3426751006_538304 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Paul, In theory I agree. In practice I don't. I said "may" because it may not be practical or desirable for a collector t= o implement deprecated IEs. You can say a collector MUST implement all IEs there will be cases when they don't. There are already cases when non deprecated IEs are not supported (if the IE didn=B9t exist when a collector was last updated for example). I don't see this being all that different. I think saying collectors MUST support deprecated IE values is as pointless as saying that deprecated IEs MUST NOT be supported by exporters. -Andrew From: Paul Aitken Date: Thursday, August 2, 2012 10:51 AM To: Andrew Feren Cc: Brian Trammell , Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review =20 =20 Andrew, =20 I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you. =20 Else you'll suddenly be unable to decode exports from all the un-updated devices in the field. =20 There are many reasons why exporting devices might not be updated. =20 P. =20 =20 On 02/08/12 14:56, Andrew Feren wrote: =20 =20 > =20 > =20 > =20 > Hi Paul, > =20 > I'm not sure there was a consensus, but my personal conclusion currently= is > that there should be a single bad state for IEs that should be avoided (c= all > it deprecated, obsolete, historical, whatever). Ideally the description = for > any deprecated IEs will point implementers in a more appropriate directio= n (or > explain why it is a bad idea and there is no alternative). Exporter > implementers should favour the more appropriate choice. Collector > implementers may choose to support or not deprecated IEs. > =20 > -Andrew > =20 > On 08/01/2012 07:19 AM, Paul Aitken wrote: > =20 > =20 >> Brian, Andrew,=20 >> =20 >> What was the conclusion here? >> =20 >> Please get some time to discuss this in the WG meeting. >> =20 >> Thanks,=20 >> P.=20 >> =20 >> =20 >> On 19/07/12 15:45, Brian Trammell wrote: >> =20 >>> Hi, Andrew,=20 >>> =20 >>> Essentially, if this is the argument (which I'm not saying I disagree >>> with), then we should drop obsolete as a status, and just stay with >>> deprecated -- there's no point in distinguishing "don't use it" from "R= EALLY >>> don't use it" unless we specify that use of deprecated IEs is a warning= and >>> use of obsolete IEs is an error. >>> =20 >>> Especially since we'll never reclaim number or namespace anyway, why n= ot >>> just collapse to one "dead" status? >>> =20 >>> Cheers,=20 >>> =20 >>> Brian=20 >>> =20 >>> On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: >>> =20 >>> =20 >>>> On 07/19/2012 05:01 AM, Brian Trammell wrote: >>>> =20 >>>> [ snip ]=20 >>>> =20 >>>>> =20 >>>>>> =20 >>>>>>> After a period of time determined in the eyes >>>>>>> of the IE-DOCTORS experts to be reasonable in order to allow >>>>>>> deployed=20 >>>>>>> Exporting Processes to be updated to account for the deprecati= on, a >>>>>>> deprecated Information Element may be made obsolete. Obsolete >>>>>>> Information Elements MUST NOT be supported by either Exporting= or >>>>>>> Collecting Processes. The receipt of obsolete Information Ele= ments >>>>>>> =20 >>>>>> ** ** Nope, not happening. I can't force my customers to upgrade ju= st >>>>>> because some 3rd party says so. >>>>>> =20 >>>>> "MUST NOT be supported by new implementations of either Exporting or >>>>> Collecting Processes"? >>>>> =20 >>>>> The point here is that if we're going to support deprecation (which = was >>>>> clearly the intent of the WG, given its inclusion in 5102), there may= be a >>>>> mismatch between the deployed and specified environment WRT supported= IEs. >>>>> =20 >>>>> =20 >>>>> =20 >>>> I have to side with Paul on this one. Saying that a collecting proce= ss >>>> MUST NOT support obsoleted IEs seems to me to violate the robustness >>>> principle. An argument can be made that new exporters SHOULD / MUST N= OT >>>> send deprecated IEs, but I think more than that is too much. >>>> =20 >>>> To give a specific example of the shelf life of the obsolete. Wikiped= ia >>>> tells me that NetFlow v1 is obsolete (and it has been for years), but = I >>>> still see NetFlow v1 exports on some customer networks. >>>> =20 >>>> -Andrew=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> =20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> =20 >> =20 >> =20 >> =20 > =20 > =20 =20 =20 =20 --B_3426751006_538304 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Paul,

In theory I agree.  In practice I don't.

I said "may" because it may not be practical or desirable for a collector t= o implement deprecated IEs.  You can say a collector MUST implement all= IEs there will be cases when they don't.  There are already cases when= non deprecated IEs are not supported (if the IE didn’t exist when a c= ollector was last updated for example).  I don't see this being all tha= t different.  I think saying collectors MUST support deprecated IE valu= es is as pointless as saying that deprecated IEs MUST NOT be supported = by exporters. 

-Andrew

From: Paul Aitken <paitken@cisco.com>
Da= te: Thursday, August 2, 2012 10:51 AM
To: Andrew Feren <andrewf= @plixer.com>
Cc: Brian Tram= mell <trammell@tik.ee.ethz.ch>, <ipfix@ietf.org>
Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doc= tors-02 review

Andrew,

I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated devices in the field.

There are many reasons why exporting devices might not be updated.
P.


On 02/08/12 14:56, Andrew Feren wrote:
Hi Paul,

I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

-Andrew

On 08/01/2012 07:19 AM, Paul Aitken wrote:
Brian, Andrew,

What was the conclusion here?

Please get some time to discuss this in the WG meeting.

Thanks,
P.


On 19/07/12 15:45, Brian Trammell wrote:
Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

On 07/19/2012 05:01 AM, Brian Trammell wrote:

[ snip ]
    After a period o= f time determined in the eyes
    of the IE-DOCTORS experts to be reason= able in order to allow deployed
    Exporting Processes to be updated to a= ccount for the deprecation, a
    deprecated Information Element may be = made obsolete.  Obsolete
    Information Elements MUST NOT be suppo= rted by either Exporting or
    Collecting Processes.  The receip= t of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.


I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can b= e made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.

-Andrew
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/lis= tinfo/ipfix
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listi= nfo/ipfix





--B_3426751006_538304-- From paitken@cisco.com Thu Aug 2 09:01:41 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF1421E8034 for ; Thu, 2 Aug 2012 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG-ydmj1Por0 for ; Thu, 2 Aug 2012 09:01:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8E11E80A6 for ; Thu, 2 Aug 2012 09:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=23795; q=dns/txt; s=iport; t=1343923298; x=1345132898; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qv3O6Yyyk9hSKu1YFA+EnVEWv7DzrNAQclZAyWfMtGY=; b=kZRQCm3ECXHk30HNaFgop8LVSC3wBahSR3v4HU/ZqLxtBEPNd9bGHoe5 M5zrl/Du5ikuzAUoFc57WwZwFpZAU7xokAFJjW9QyhCpIVRZYIXeBOqVg 5/EveQAdD2vW8GkJQwNOxPlSaR8JY8ZmfjZNkSZtY47fyn2qiWBPNpz1I 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkQALqjGlCQ/khN/2dsb2JhbABFgkqvFIcugQeCIAEBAQMBAQEBDwFYAwoBEAsRAwECAQkMCgEHBwkDAgECARUfCQgGAQwBBQIBARUJh2UGC5xfoEwEi0mDXIMoA5VHhVuITIFmgmCBVQc X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208,217";a="141943513" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2012 16:01:36 +0000 Received: from [10.55.81.152] (dhcp-10-55-81-152.cisco.com [10.55.81.152]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72G1Ztk008081; Thu, 2 Aug 2012 16:01:35 GMT Message-ID: <501AA460.7030400@cisco.com> Date: Thu, 02 Aug 2012 17:01:36 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steven Campbell , Andrew Feren References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000501010804040407020105" Cc: "" Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:01:41 -0000 This is a multi-part message in MIME format. --------------000501010804040407020105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Andrew, Steven, Fair point. Obviously there are some limitations in which fields each EP and CP can support. However that could lead to an interop failure where a 3rd party believes that IPFIX exporter X should work with IPFIX collector Y because they both claim IPFIX compliance. Yet this turns out not to be the case since X exports some too-new or too-old IEs which Y doesn't accept. So our customers would be obliged to evaluate X against Y in their labs prior to deployment, and repeat for every new X' and Y'. Or X and Y do the testing, and self-certify that version X interops correctly with version Y. I have an idea. Let me unicast you. P. On 02/08/12 16:44, Steven Campbell wrote: > I agree with Andrew's synopsis as stated below: >>> I'm not sure there was a consensus, but my personal conclusion >>> currently is that there should be a single bad state for IEs that >>> should be avoided (call it deprecated, obsolete, historical, >>> whatever). Ideally the description for any deprecated IEs will >>> point implementers in a more appropriate direction (or explain why >>> it is a bad idea and there is no alternative). Exporter >>> implementers should favour the more appropriate choice. Collector >>> implementers may choose to support or not deprecated IEs. > > We can look at a collector as simply a reporting device for IE's, but > in fact, many of the implementations do much more than simply > represent what they receive thus a collector may or may not derive > value from a deprecated IE thus might choose not to support it. > Best regards, > Steve > > On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote: > >> Hi Paul, >> >> In theory I agree. In practice I don't. >> >> I said "may" because it may not be practical or desirable for a >> collector to implement deprecated IEs. You can say a collector MUST >> implement all IEs there will be cases when they don't. There are >> already cases when non deprecated IEs are not supported (if the IE >> didn’t exist when a collector was last updated for example). I don't >> see this being all that different. I think saying collectors MUST >> support deprecated IE values is as pointless as saying that >> deprecated IEs MUST NOT be supported by exporters. >> >> -Andrew >> >> From: Paul Aitken > >> Date: Thursday, August 2, 2012 10:51 AM >> To: Andrew Feren > >> Cc: Brian Trammell > >, > > >> Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review >> >> Andrew, >> >> I mostly agree, except that collector implementers must support all >> the information elements that ever were, regardless of their current >> state, because you cannot know what an exporting process might send you. >> >> Else you'll suddenly be unable to decode exports from all the >> un-updated devices in the field. >> >> There are many reasons why exporting devices might not be updated. >> >> P. >> >> >> On 02/08/12 14:56, Andrew Feren wrote: >>> Hi Paul, >>> >>> I'm not sure there was a consensus, but my personal conclusion >>> currently is that there should be a single bad state for IEs that >>> should be avoided (call it deprecated, obsolete, historical, >>> whatever). Ideally the description for any deprecated IEs will >>> point implementers in a more appropriate direction (or explain why >>> it is a bad idea and there is no alternative). Exporter implementers >>> should favour the more appropriate choice. Collector implementers >>> may choose to support or not deprecated IEs. >>> >>> -Andrew >>> >>> On 08/01/2012 07:19 AM, Paul Aitken wrote: >>>> Brian, Andrew, >>>> >>>> What was the conclusion here? >>>> >>>> Please get some time to discuss this in the WG meeting. >>>> >>>> Thanks, >>>> P. >>>> >>>> >>>> On 19/07/12 15:45, Brian Trammell wrote: >>>>> Hi, Andrew, >>>>> >>>>> Essentially, if this is the argument (which I'm not saying I >>>>> disagree with), then we should drop obsolete as a status, and just >>>>> stay with deprecated -- there's no point in distinguishing "don't >>>>> use it" from "REALLY don't use it" unless we specify that use of >>>>> deprecated IEs is a warning and use of obsolete IEs is an error. >>>>> >>>>> Especially since we'll never reclaim number or namespace anyway, >>>>> why not just collapse to one "dead" status? >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>>> On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: >>>>> >>>>>> On 07/19/2012 05:01 AM, Brian Trammell wrote: >>>>>> >>>>>> [ snip ] >>>>>>>>> After a period of time determined in the eyes >>>>>>>>> of the IE-DOCTORS experts to be reasonable in order to >>>>>>>>> allow deployed >>>>>>>>> Exporting Processes to be updated to account for the >>>>>>>>> deprecation, a >>>>>>>>> deprecated Information Element may be made obsolete. >>>>>>>>> Obsolete >>>>>>>>> Information Elements MUST NOT be supported by either >>>>>>>>> Exporting or >>>>>>>>> Collecting Processes. The receipt of obsolete Information >>>>>>>>> Elements >>>>>>>> ** ** Nope, not happening. I can't force my customers to >>>>>>>> upgrade just because some 3rd party says so. >>>>>>> "MUST NOT be supported by new implementations of either >>>>>>> Exporting or Collecting Processes"? >>>>>>> >>>>>>> The point here is that if we're going to support deprecation >>>>>>> (which was clearly the intent of the WG, given its inclusion in >>>>>>> 5102), there may be a mismatch between the deployed and >>>>>>> specified environment WRT supported IEs. >>>>>>> >>>>>>> >>>>>> I have to side with Paul on this one. Saying that a collecting >>>>>> process MUST NOT support obsoleted IEs seems to me to violate the >>>>>> robustness principle. An argument can be made that new exporters >>>>>> SHOULD / MUST NOT send deprecated IEs, but I think more than that >>>>>> is too much. >>>>>> >>>>>> To give a specific example of the shelf life of the obsolete. >>>>>> Wikipedia tells me that NetFlow v1 is obsolete (and it has been >>>>>> for years), but I still see NetFlow v1 exports on some customer >>>>>> networks. >>>>>> >>>>>> -Andrew >>>>>> _______________________________________________ >>>>>> 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 > --------------000501010804040407020105 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Andrew, Steven,

Fair point. Obviously there are some limitations in which fields each EP and CP can support.

However that could lead to an interop failure where a 3rd party believes that IPFIX exporter X should work with IPFIX collector Y because they both claim IPFIX compliance. Yet this turns out not to be the case since X exports some too-new or too-old IEs which Y doesn't accept.

So our customers would be obliged to evaluate X against Y in their labs prior to deployment, and repeat for every new X' and Y'.

Or X and Y do the testing, and self-certify that version X interops correctly with version Y.

I have an idea. Let me unicast you.

P.


On 02/08/12 16:44, Steven Campbell wrote:
I agree with Andrew's synopsis as stated below:
I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete,         historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

We can look at a collector as simply a reporting device for IE's, but in fact, many of the implementations do much more than simply represent what they receive thus a collector may or may not derive value from a deprecated IE thus might choose not to support it.  
Best regards,
Steve

On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote:

Hi Paul,

In theory I agree.  In practice I don't.

I said "may" because it may not be practical or desirable for a collector to implement deprecated IEs.  You can say a collector MUST implement all IEs there will be cases when they don't.  There are already cases when non deprecated IEs are not supported (if the IE didn’t exist when a collector was last updated for example).  I don't see this being all that different.  I think saying collectors MUST support deprecated IE values is as pointless as saying that deprecated IEs MUST NOT be supported by exporters. 

-Andrew

From: Paul Aitken <paitken@cisco.com>
Date: Thursday, August 2, 2012 10:51 AM
To: Andrew Feren <andrewf@plixer.com>
Cc: Brian Trammell <trammell@tik.ee.ethz.ch>, <ipfix@ietf.org>
Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review

Andrew,

I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated devices in the field.

There are many reasons why exporting devices might not be updated.

P.


On 02/08/12 14:56, Andrew Feren wrote:
Hi Paul,

I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

-Andrew

On 08/01/2012 07:19 AM, Paul Aitken wrote:
Brian, Andrew,

What was the conclusion here?

Please get some time to discuss this in the WG meeting.

Thanks,
P.


On 19/07/12 15:45, Brian Trammell wrote:
Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

On 07/19/2012 05:01 AM, Brian Trammell wrote:

[ snip ]
    After a period of time determined in the eyes
    of the IE-DOCTORS experts to be reasonable in order to allow deployed
    Exporting Processes to be updated to account for the deprecation, a
    deprecated Information Element may be made obsolete.  Obsolete
    Information Elements MUST NOT be supported by either Exporting or
    Collecting Processes.  The receipt of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.


I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.

-Andrew
_______________________________________________
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



--------------000501010804040407020105-- From Steven.Campbell@riverbed.com Thu Aug 2 08:44:14 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B1F21F8433 for ; Thu, 2 Aug 2012 08:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xD9aq8OEawr for ; Thu, 2 Aug 2012 08:44:12 -0700 (PDT) Received: from smtp2.riverbed.com (smtp2.riverbed.com [208.70.196.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDA9D21F86A2 for ; Thu, 2 Aug 2012 08:44:12 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 02 Aug 2012 08:44:12 -0700 Received: from 365EXCH-MBX-P5.nbttech.com ([fe80::7b:394b:243e:83b6]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 08:44:12 -0700 From: Steven Campbell To: Andrew Feren Thread-Topic: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review Thread-Index: AQHNcL5k7DIpB5jF50OJzJNKtLD78pdHF4GAgAAHrIA= Date: Thu, 2 Aug 2012 15:44:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.249] Content-Type: multipart/alternative; boundary="_000_AD739EEE6F5B42519C56A3982AC7BBFAriverbedcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Aug 2012 09:11:30 -0700 Cc: "" Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:45:55 -0000 --_000_AD739EEE6F5B42519C56A3982AC7BBFAriverbedcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Andrew's synopsis as stated below: I'm not sure there was a consensus, but my personal conclusion currently is= that there should be a single bad state for IEs that should be avoided (ca= ll it deprecated, obsolete, historical, whatever). Ideally the des= cription for any deprecated IEs will point implementers in a more appropria= te direction (or explain why it is a bad idea and there is no alternative).= Exporter implementers should favour the more appropriate choice. Collect= or implementers may choose to support or not deprecated IEs. We can look at a collector as simply a reporting device for IE's, but in fa= ct, many of the implementations do much more than simply represent what the= y receive thus a collector may or may not derive value from a deprecated IE= thus might choose not to support it. Best regards, Steve On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote: Hi Paul, In theory I agree. In practice I don't. I said "may" because it may not be practical or desirable for a collector t= o implement deprecated IEs. You can say a collector MUST implement all IEs= there will be cases when they don't. There are already cases when non dep= recated IEs are not supported (if the IE didn=92t exist when a collector wa= s last updated for example). I don't see this being all that different. I= think saying collectors MUST support deprecated IE values is as pointless = as saying that deprecated IEs MUST NOT be supported by exporters. -Andrew From: Paul Aitken > Date: Thursday, August 2, 2012 10:51 AM To: Andrew Feren > Cc: Brian Trammell = >, > Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review Andrew, I mostly agree, except that collector implementers must support all the inf= ormation elements that ever were, regardless of their current state, becaus= e you cannot know what an exporting process might send you. Else you'll suddenly be unable to decode exports from all the un-updated de= vices in the field. There are many reasons why exporting devices might not be updated. P. On 02/08/12 14:56, Andrew Feren wrote: Hi Paul, I'm not sure there was a consensus, but my personal conclusion currently is= that there should be a single bad state for IEs that should be avoided (ca= ll it deprecated, obsolete, historical, whatever). Ideally the description= for any deprecated IEs will point implementers in a more appropriate direc= tion (or explain why it is a bad idea and there is no alternative). Export= er implementers should favour the more appropriate choice. Collector imple= menters may choose to support or not deprecated IEs. -Andrew On 08/01/2012 07:19 AM, Paul Aitken wrote: Brian, Andrew, What was the conclusion here? Please get some time to discuss this in the WG meeting. Thanks, P. On 19/07/12 15:45, Brian Trammell wrote: Hi, Andrew, Essentially, if this is the argument (which I'm not saying I disagree with)= , then we should drop obsolete as a status, and just stay with deprecated -= - there's no point in distinguishing "don't use it" from "REALLY don't use = it" unless we specify that use of deprecated IEs is a warning and use of ob= solete IEs is an error. Especially since we'll never reclaim number or namespace anyway, why not ju= st collapse to one "dead" status? Cheers, Brian On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: On 07/19/2012 05:01 AM, Brian Trammell wrote: [ snip ] After a period of time determined in the eyes of the IE-DOCTORS experts to be reasonable in order to allow deployed Exporting Processes to be updated to account for the deprecation, a deprecated Information Element may be made obsolete. Obsolete Information Elements MUST NOT be supported by either Exporting or Collecting Processes. The receipt of obsolete Information Elements ** ** Nope, not happening. I can't force my customers to upgrade just becau= se some 3rd party says so. "MUST NOT be supported by new implementations of either Exporting or Collec= ting Processes"? The point here is that if we're going to support deprecation (which was cle= arly the intent of the WG, given its inclusion in 5102), there may be a mis= match between the deployed and specified environment WRT supported IEs. I have to side with Paul on this one. Saying that a collecting process MUS= T NOT support obsoleted IEs seems to me to violate the robustness principle= . An argument can be made that new exporters SHOULD / MUST NOT send deprec= ated IEs, but I think more than that is too much. To give a specific example of the shelf life of the obsolete. Wikipedia tel= ls me that NetFlow v1 is obsolete (and it has been for years), but I still = see NetFlow v1 exports on some customer networks. -Andrew _______________________________________________ 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 --_000_AD739EEE6F5B42519C56A3982AC7BBFAriverbedcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I agree with Andrew's synopsis as stated below:
I'm not sure there was a consensus, but my p= ersonal conclusion currently is that there should be a single bad state for= IEs that should be avoided (call it deprecated, obsolete,   &nbs= p;     historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direc= tion (or explain why it is a bad idea and there is no alternative).  E= xporter implementers should favour the more appropriate choice.  Colle= ctor implementers may choose to support or not deprecated IEs.

We can look at a collector as simply a reporting device for IE's, but in fa= ct, many of the implementations do much more than simply represent what the= y receive thus a collector may or may not derive value from a deprecated IE= thus might choose not to support it.  
Best regards,
Steve

On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote:

Hi Paul,

In theory I agree.  In practice I don't.

I said "may" because it may not be practical or desirable fo= r a collector to implement deprecated IEs.  You can say a collector MU= ST implement all IEs there will be cases when they don't.  There are a= lready cases when non deprecated IEs are not supported (if the IE didn=92t exist when a collector was last updated for example). =  I don't see this being all that different.  I think saying colle= ctors MUST support deprecated IE values is as pointless as saying that depr= ecated IEs MUST NOT be supported by exporters. 

-Andrew

From: Paul Aitken <paitken@cisco.com>
Date: Thursday, August 2, 2012 10:5= 1 AM
To: Andrew Feren <andrewf@plixer.com>
Cc: Brian Trammell <trammell@tik.ee.ethz.ch>, <ipfix@ietf.org>
Subject: Re: [IPFIX] draft-ietf-ipf= ix-ie-doctors-02 review

Andrew,

I mostly agree, except that collector implementers must support all the inf= ormation elements that ever were, regardless of their current state, becaus= e you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated de= vices in the field.

There are many reasons why exporting devices might not be updated.

P.


On 02/08/12 14:56, Andrew Feren wrote:
Hi Paul,

I'm not sure there was a consensus, but my personal conclusion currently is= that there should be a single bad state for IEs that should be avoided (ca= ll it deprecated, obsolete, historical, whatever).  Ideally the descri= ption for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad i= dea and there is no alternative).  Exporter implementers should favour= the more appropriate choice.  Collector implementers may choose to su= pport or not deprecated IEs.

-Andrew

On 08/01/2012 07:19 AM, Paul Aitken wrote:
Brian, An= drew,

What was the conclusion here?

Please get some time to discuss this in the WG meeting.

Thanks,
P.


On 19/07/12 15:45, Brian Trammell wrote:
Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with)= , then we should drop obsolete as a status, and just stay with deprecated -= - there's no point in distinguishing "don't use it" from "RE= ALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not ju= st collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

On 07/19/2012 05:01 AM, Brian Trammell wrote:
[ snip ]
    After a period of time determi= ned in the eyes
    of the IE-DOCTORS experts to be reasonable in order to a= llow deployed
    Exporting Processes to be updated to account for the dep= recation, a
    deprecated Information Element may be made obsolete.&nbs= p; Obsolete
    Information Elements MUST NOT be supported by either Exp= orting or
    Collecting Processes.  The receipt of obsolete Info= rmation Elements
** ** Nope, not happening. I can't force my customers to upgrade just becau= se some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or C= ollecting Processes"?

The point here is that if we're going to support deprecation (which was cle= arly the intent of the WG, given its inclusion in 5102), there may be a mis= match between the deployed and specified environment WRT supported IEs.


I have to side with Paul on this one.  Saying that a collecting proces= s MUST NOT support obsoleted IEs seems to me to violate the robustness prin= ciple.  An argument can be made that new exporters SHOULD / MUST NOT s= end deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tel= ls me that NetFlow v1 is obsolete (and it has been for years), but I still = see NetFlow v1 exports on some customer networks.

-Andrew
_______________________________________________
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

--_000_AD739EEE6F5B42519C56A3982AC7BBFAriverbedcom_-- From bclaise@cisco.com Thu Aug 2 10:00:28 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E819A21E8042 for ; Thu, 2 Aug 2012 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smMEXvIoIVAR for ; Thu, 2 Aug 2012 10:00:27 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE721E803C for ; Thu, 2 Aug 2012 10:00:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q72H0Q9Q001338; Thu, 2 Aug 2012 10:00:26 -0700 (PDT) Received: from [10.21.73.253] ([10.21.73.253]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q72H0Lvg018992; Thu, 2 Aug 2012 10:00:21 -0700 (PDT) Message-ID: <501AB225.4060509@cisco.com> Date: Thu, 02 Aug 2012 10:00:21 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Paul Aitken References: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> <5007FA93.2090004@cisco.com> <5019106C.9080905@cisco.com> In-Reply-To: <5019106C.9080905@cisco.com> Content-Type: multipart/alternative; boundary="------------020907070100070505000101" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IE-doctors: transitioning IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:00:28 -0000 This is a multi-part message in MIME format. --------------020907070100070505000101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, I'm wondering if this equivalent Options Template is not an overkill. Let me explain: _All _the exporters should export this IE equivalent Options Template to help the collector deduce the mapping between old/new IEs If one of the exporters doesn't export the equivalent Options Template, the collector should anyway maintain its own mapping. Mapping that could be find in IANA. Isn't it a good practice anyway that the collectors should insert the latest IANA info on regular basis? So which problem does this equivalent Options Template really solve? Regards, Benoit (as a contributor) > Brian, > > What is the conclusion to this? > > ie, do you want to rework ie-doctors, and I'll polish and publish my > -00 for IE equivalence? > > P. > > > On 19/07/12 13:45, Brian Trammell wrote: >> Hi, Paul, >> >> I'm not much of a fan of sticking enterprise-specific references in >> the registry, actually. It was suggested that this is a problem >> (indeed, I believe it is), and this is indeed a solution to it -- but >> it seems like a much cleaner mechanism for doing this would be to >> allow the actual devices doing the exporting to annotate the output >> data with an IE map (much like type information export as in RFC 5610). >> >> One clarifying point: the Collecting Process, of course, needs to be >> updated too, in order to understand the Options providing the IE map. >> But this only happens once, as opposed to the registry-based solution >> which requires the CP to be regularly updated (or to automatically >> query) the IANA registry. >> >> Removing a whole column and subset of sections from the ie-doctors at >> this late date may be a little problematic procedurally; I'm not sure >> of the right thing to do, and would turn to our chairs and AD for >> guidance... >> >> Cheers, >> >> Brian >> >> >> On Jul 19, 2012, at 2:16 PM, Paul Aitken wrote: >> >>> Brian, >>> >>> In my IE-doctors reviews, I expressed some reservation about >>> recording Enterprise-Specific information in IANA's IPFIX registry >>> as specified in this text: >>> >>> In order to support transition from experimental registration to >>> IANA >>> registration, the IANA registry provides an optional "enterprise- >>> specific IE reference" column for each Information Element. In >>> cases >>> of promoted enterprise-specific Information Elements, this >>> column in >>> the registry SHOULD contain the private enterprise and Information >>> Element numbers of the enterprise-specific version of the >>> Information >>> Element. >>> >>> >>> I've had a similar, but automated, idea in the back of my mind to >>> for some years: an upgraded device could export a table mapping >>> oldIE to newIE, where either of these IEs can be IANA standard or >>> Enterprise Specific. >>> >>> The table would be interpreted as "(if) I used to export oldIE, now >>> I export newIE", so the Collecting Process can readily re-map >>> exported data over the Exporting Process software change boundary. >>> If the Collecting Process never received any oldIE elements, it can >>> disregard the information. >>> >>> With the IE doctors / IANA registry idea, the information has to be >>> in the registry and the Collecting Process has to have read the new >>> registry. So both the Exporting Process and Collecting Process must >>> be updated. >>> >>> With my idea, only the Exporting Process is updated, and it informs >>> the Collecting Process. >>> >>> I drafted a -00 on this last year which requires a little more work, >>> so I've not published it yet. >>> >>> Of course the two mechanisms are complementary rather than mutually >>> exclusive. It's a question of which issues we're trying to solve. >>> >>> P. >>> >>> > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > --------------020907070100070505000101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Paul,

I'm wondering if this equivalent Options Template is not an overkill.

Let me explain:
All the exporters should export this IE equivalent Options Template to help the collector deduce the mapping between old/new IEs
If one of the exporters doesn't export the equivalent Options Template, the collector should anyway maintain its own mapping. Mapping that could be find in IANA. Isn't it a good practice anyway that the collectors should insert the latest IANA info on regular basis?

So which problem does this equivalent Options Template really solve?

Regards, Benoit (as a contributor)

Brian,

What is the conclusion to this?

ie, do you want to rework ie-doctors, and I'll polish and publish my -00 for IE equivalence?

P.


On 19/07/12 13:45, Brian Trammell wrote:
Hi, Paul,

I'm not much of a fan of sticking enterprise-specific references in the registry, actually. It was suggested that this is a problem (indeed, I believe it is), and this is indeed a solution to it -- but it seems like a much cleaner mechanism for doing this would be to allow the actual devices doing the exporting to annotate the output data with an IE map (much like type information export as in RFC 5610).

One clarifying point: the Collecting Process, of course, needs to be updated too, in order to understand the Options providing the IE map. But this only happens once, as opposed to the registry-based solution which requires the CP to be regularly updated (or to automatically query) the IANA registry.

Removing a whole column and subset of sections from the ie-doctors at this late date may be a little problematic procedurally; I'm not sure of the right thing to do, and would turn to our chairs and AD for guidance...

Cheers,

Brian


On Jul 19, 2012, at 2:16 PM, Paul Aitken wrote:

Brian,

In my IE-doctors reviews, I expressed some reservation about recording Enterprise-Specific information in IANA's IPFIX registry as specified in this text:

    In order to support transition from experimental registration to IANA
    registration, the IANA registry provides an optional "enterprise-
    specific IE reference" column for each Information Element.  In cases
    of promoted enterprise-specific Information Elements, this column in
    the registry SHOULD contain the private enterprise and Information
    Element numbers of the enterprise-specific version of the Information
    Element.


I've had a similar, but automated, idea in the back of my mind to for some years: an upgraded device could export a table mapping oldIE to newIE, where either of these IEs can be IANA standard or Enterprise Specific.

The table would be interpreted as "(if) I used to export oldIE, now I export newIE", so the Collecting Process can readily re-map exported data over the Exporting Process software change boundary. If the Collecting Process never received any oldIE elements, it can disregard the information.

With the IE doctors / IANA registry idea, the information has to be in the registry and the Collecting Process has to have read the new registry. So both the Exporting Process and Collecting Process must be updated.

With my idea, only the Exporting Process is updated, and it informs the Collecting Process.

I drafted a -00 on this last year which requires a little more work, so I've not published it yet.

Of course the two mechanisms are complementary rather than mutually exclusive. It's a question of which issues we're trying to solve.

P.




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



--------------020907070100070505000101-- From paitken@cisco.com Thu Aug 2 10:23:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B701711E8180 for ; Thu, 2 Aug 2012 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27VbmGw8RLqe for ; Thu, 2 Aug 2012 10:23:04 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8531311E817C for ; Thu, 2 Aug 2012 10:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4981; q=dns/txt; s=iport; t=1343928183; x=1345137783; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qXuEeO1IjesirlAj5nXS2SO7J9OUV52leMe67oir1M0=; b=iqZPW2FlfR07cDySd39SDtTOtYVloAHsA7uPFkegsZxnA/t4FGylhyl6 PyhQ/Ze2TdlNcWrmKE8/GwjP9hBQvtF08p9ni3/oMEmKCHtKoBtSLqkVf EXvbWwQQF7qlqMGDL0TeLAnJnShQXn5G77+IGjsyghisJmavpWSbVO2PK 0=; X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208,217";a="7084005" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 02 Aug 2012 17:23:01 +0000 Received: from [10.55.81.152] (dhcp-10-55-81-152.cisco.com [10.55.81.152]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72HN0tL020829; Thu, 2 Aug 2012 17:23:01 GMT Message-ID: <501AB776.4010505@cisco.com> Date: Thu, 02 Aug 2012 18:23:02 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Benoit Claise References: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> <5007FA93.2090004@cisco.com> <5019106C.9080905@cisco.com> <501AB225.4060509@cisco.com> In-Reply-To: <501AB225.4060509@cisco.com> Content-Type: multipart/alternative; boundary="------------060301090307040107080306" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IE-doctors: transitioning IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:23:04 -0000 This is a multi-part message in MIME format. --------------060301090307040107080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, > I'm wondering if this equivalent Options Template is not an overkill. > > Let me explain: > _All _the exporters should export this IE equivalent Options Template > to help the collector deduce the mapping between old/new IEs If the exporter begins to use different IEs, yes. > If one of the exporters doesn't export the equivalent Options > Template, the collector should anyway maintain its own mapping. > Mapping that could be find in IANA. This requires the collector to be able to query IANA - which isn't always possible. Or the collector manufacturer queries IANA and issues an updated collector (ie, new software version). The proposed idea requires no enterprise-specific information to be recorded in IANA - because it simply does not belong there! And it provides a mechanism where collectors are immediately aware of the equivalence of old and new IEs without requiring any software update. > Isn't it a good practice anyway that the collectors should insert the > latest IANA info on regular basis? Perhaps. However, we know that some customers can test equipment in their labs for months or years before putting new versions into production. It's unlikely that they'd allow their collector to query IANA since this opens a potential attack vector if someone can inject incorrect information via the IANA registry lookup (eg, by DNS spoofing). > So which problem does this equivalent Options Template really solve? When an exporter begins to use a new IE (eg, IANA versus enterprise-specific), it enables a collector to process data received before the change with data received after the change without any software update being required. P. --------------060301090307040107080306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit,

I'm wondering if this equivalent Options Template is not an overkill.

Let me explain:
All the exporters should export this IE equivalent Options Template to help the collector deduce the mapping between old/new IEs

If the exporter begins to use different IEs, yes.


If one of the exporters doesn't export the equivalent Options Template, the collector should anyway maintain its own mapping. Mapping that could be find in IANA.

This requires the collector to be able to query IANA - which isn't always possible. Or the collector manufacturer queries IANA and issues an updated collector (ie, new software version).

The proposed idea requires no enterprise-specific information to be recorded in IANA - because it simply does not belong there! And it provides a mechanism where collectors are immediately aware of the equivalence of old and new IEs without requiring any software update.


Isn't it a good practice anyway that the collectors should insert the latest IANA info on regular basis?

Perhaps. However, we know that some customers can test equipment in their labs for months or years before putting new versions into production. It's unlikely that they'd allow their collector to query IANA since this opens a potential attack vector if someone can inject incorrect information via the IANA registry lookup (eg, by DNS spoofing).


So which problem does this equivalent Options Template really solve?

When an exporter begins to use a new IE (eg, IANA versus enterprise-specific), it enables a collector to process data received before the change with data received after the change without any software update being required.

P.
--------------060301090307040107080306-- From janovak@cisco.com Fri Aug 3 07:40:03 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CD21F8463; Fri, 3 Aug 2012 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmnRDfU6EUlo; Fri, 3 Aug 2012 07:40:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9321F8DC0; Fri, 3 Aug 2012 07:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2875; q=dns/txt; s=iport; t=1344004802; x=1345214402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2rmf9ehrhIvQCY5pWkaFFgCw2ZQio0fkGCwU+3yA/G8=; b=PYJVWlupLrS3IJfDa9JBoxh6nbosJ/OV64piO4RdJO1cRqxpxTvX084M +2sQSXTCw63PoXGyJ2nu4wJ5BH8W++YJhNSU5StbBnhzfq/e8QWItIL1I Uk9VzMrYnwkd+4sDIpFeyc0c2KanIQmXT8gZGM0LreD69dSvZv3Cx8dSX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB7iG1CtJXG8/2dsb2JhbABFuRyBB4IgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgBAQQBDQUIGodrnESgKotIhiRgA6NxgWaCXw X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208";a="108211278" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2012 14:40:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q73Ee15L003563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 14:40:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 09:40:01 -0500 From: "Jan Novak (janovak)" To: "Aamer Akhter (aakhter)" , "'ipfix@ietf.org'" , "'opsawg@ietf.org'" Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQDYLiRuAA4E6qQA== Date: Fri, 3 Aug 2012 14:40:00 +0000 Message-ID: References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> In-Reply-To: <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.89.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--42.180200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Al Morton' , "'pmol@ietf.org'" Subject: Re: [IPFIX] Comments on draft-akhter-opsawg-perfmon-ipfix-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:40:03 -0000 Hi again, Thanks for applying the comments. AA> Jan, can you look again ? Is there still a problem? No, sorry missed the TBD or its significance. AA> We're open to adding scope (as defined as which set of packets would th= is be applicable to). AA> Would you agree that this is more of a methodology item than a IE item? Yes, indeed, whichever of Observation domain/Scope it is, it is not the pro= perty of the IE. Jan The climate of Edinburgh is such that the weak succumb young, and the strong envy them .... Dr. Johnson -----Original Message----- From: Aamer Akhter (aakhter)=20 Sent: 30 July 2012 16:50 To: Jan Novak (janovak); 'ipfix@ietf.org'; 'opsawg@ietf.org' Cc: 'Al Morton'; 'pmol@ietf.org'; Hendrik Scholz Subject: RE: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Jan, Thank-you for the review. Please find my comments below. We Hendrik and I w= ill be publishing -03 shortly.=20 -----Original Message----- From: Jan Novak (janovak)=20 Sent: Tuesday, May 22, 2012 4:58 AM To: Aamer Akhter (aakhter); ipfix@ietf.org; opsawg@ietf.org Cc: Al Morton; pmol@ietf.org Subject: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - se= ction 1,3, 4 could probably be abbreviated or omitted leaving the document = just with raw IPFIX IE specifications or just add the IE specification as s= ub-sections or a new section into the first document ??=20 AA> I agree that there is overlap, but it was retained for readability. But= I see your point regarding keeping the focus on the IEs in the IPFIX versi= on of the draft. Will strip some of the detail in the IPFIX version. Section 2 uses definitions from RFC5610 - I think those you use there are d= efined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are de= fining the IE itself so you should use the definitions from RFC5102 AA> I think I had used RFC5610 as it seemed to be a bit more specific about= it (eg rangeBegin and rangeEnd rather than just range). But we are fine e= ither way depending on feedback. Also the methodology documents already speaks in terms of IPFIX IEs while y= ou are trying to specify some performance metrics - the methodology could h= ave names and an exact definitions of the metric and then a reference which= IE represents the particular metric AA> will update the methodology doc with exact definitions and reference th= e IEs.=20 RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST en= tries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. From paitken@cisco.com Fri Aug 3 09:15:07 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A8F21F8D45 for ; Fri, 3 Aug 2012 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.841 X-Spam-Level: X-Spam-Status: No, score=-8.841 tagged_above=-999 required=5 tests=[AWL=-1.608, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ezONtwY2SY for ; Fri, 3 Aug 2012 09:15:04 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 63B4621F8E47 for ; Fri, 3 Aug 2012 09:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=18770; q=dns/txt; s=iport; t=1344010501; x=1345220101; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=bORH8g9RT41VSXJiEdyXTEOouWbKGdeGvuvRO4HYHRs=; b=d6kSPw2xxi3syXlI6ecY/M9D5ai/dq+8VcKI4CY+sGikMexsukkqnoPK 0hq9GpUE+8/VZoAL+HnG49dCP6LafALRi7Gxa4SPRWUipERbM5xuJ2o6l nY9T5uBsFOz73csFRYDjhnamx4pqaK+M/ZZjWVICyUr++yQAYyFedfO+1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB34G1CQ/khL/2dsb2JhbAA/BrklgQeCIAEBAQMTASUPIBEBBQkUGhYYAwIBAgEJTwEFAgEBHodlBgucUpEFjx0Ei0Qmhl4DlUqBFIRHiEyBZoJggVcHHA X-IronPort-AV: E=Sophos;i="4.77,707,1336348800"; d="scan'208";a="7105302" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 03 Aug 2012 16:14:59 +0000 Received: from [10.55.81.154] (dhcp-10-55-81-154.cisco.com [10.55.81.154]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q73GExmG018580; Fri, 3 Aug 2012 16:14:59 GMT Message-ID: <501BF904.6090401@cisco.com> Date: Fri, 03 Aug 2012 17:15:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: hscholz@voipfuture.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:15:07 -0000 Hendrik, > > Network Working Group H. Scholz > Internet-Draft VOIPFUTURE GmbH > Intended status: Informational July 9, 2012 > Expires: January 10, 2013 > > > RTP Stream Quality Information Export using IPFIX > draft-scholz-ipfix-rtp-audio-quality-00 > > Abstract > > This draft defines a set of Information Elements and matching Remove "matching" > Templates to convey RTP media stream quality information in IPFIX > packets. The Information Elements describe the RTP quality using the > R-factor and Mean Opinion score (MOS) for the entire duration of a > monitored stream or for a smaller time slice thereof. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on January 10, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Scholz Expires January 10, 2013 [Page 1] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1.1. Quality of Service (QoS) Monitoring . . . . . . . . . 3 > 1.1.2. Service Level Agreement (SLA) . . . . . . . . . . . . 3 > 1.1.3. Troubleshooting . . . . . . . . . . . . . . . . . . . 3 > 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. MOS measurement . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. rtpMOSCAlg . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.2. rtpMOSClass1 . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.3. rtpMOSClass2 . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.4. rtpMOSClass3 . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.5. rtpMOSClass4 . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.6. rtpMOSClass5 . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.7. rtpMinMOS . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.8. rtpAvgMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 > 3.9. rtpMaxMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 > 3.10. rtpMinRFactor . . . . . . . . . . . . . . . . . . . . . . 7 > 3.11. rtpAvgRFactor . . . . . . . . . . . . . . . . . . . . . . 7 > 3.12. rtpMaxRFactor . . . . . . . . . . . . . . . . . . . . . . 8 > 4. Recommended Templates . . . . . . . . . . . . . . . . . . . . 8 > 4.1. Entire stream . . . . . . . . . . . . . . . . . . . . . . 8 > 4.2. Time slice . . . . . . . . . . . . . . . . . . . . . . . . 8 > 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 > > > > > > > Scholz Expires January 10, 2013 [Page 2] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > 1. Introduction > > IPFIX [RFC5101] and [RFC5102] define a framework allowing to export NB these references will need to be updated to -bis. "the export of arbitrary data". > arbitrary data from so called IPFIX exporters. One type of IPFIX Why "so called"? They *are* IPFIX exporters! > exporter may be co-located with Session Initiation Protocol (SIP) At least, the IPFIX Device's Metering Process is co-located with the SIP devices / calls. The Exporting Process may be remote; you don't care. > [RFC3261] based VoIP entities or passively observe SIP based VoIP > calls. The signaling messages can be exported using > [I-D.trammell-ipfix-sip-msg] and Real Time Protocol (RTP) [RFC3550] > media streams are covered in [I-D.akhter-ipfix-perfmon]. Media > quality is out of the scope of both these documents. This document > defines a set of additional IPFIX Information Elements (IEs) to > describe RTP audio stream quality. > > 1.1. Use Cases > > RTP stream flow information contained in IPFIX flow records can be > used for various tasks such as Quality of Service (QoS) monitoring, > Service Level Agreement (SLA) validation and general troubleshooting > of VoIP networks. > > 1.1.1. Quality of Service (QoS) Monitoring > > Aggregated to higher-level metrics the in-depth information provided > by the RTP (and optionally SIP) flow records allow service providers > to gauge the overall quality of their network in terms of the quality > of experience (QoE). On this level an individual call is less > important but the overall quality (e.g. amount of minutes meeting > certain quality standards) can be used to get a quick overview on the > network and service performance. > > 1.1.2. Service Level Agreement (SLA) > > SLAs are typically used as part of contracts between two network > operators. The requirements on the reliability of the data may be > higher compared to QoS Monitoring as the failure to meet > contractually agreed quality standards often has a direct commercial > impact. > > 1.1.3. Troubleshooting > > An active network component (SIP proxy, B2BUA, media server) may not > have the capabilities to store session related information for a long > time to facilitate troubleshooting capabilities (e.g. due to missing > hard-disk). Such a system or a group of systems may run the metering > process and export the data to a collector for processing or say "run a Metering Process and export IPFIX to a Collecting Process for ...", since MP and CP are 5101 terms. > troubleshooting purposes. You might want to have a terminology section here, if only to refer readers to 5101. See how the other IPFIX drafts do this. > > > > > > Scholz Expires January 10, 2013 [Page 3] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > 2. Conventions > > 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 RFC 2119 [RFC2119]. > > > 3. MOS measurement > > A multitude of Mean Opinion Score (MOS) assessment algorithms have > been defined of which only one or few may be available to an IPFIX > Metering Process. The quality (i.e. accuracy) of these algorithms Technically it's not an "IPFIX Metering Process" - it's a SIP Metering Process connected to an IPFIX Exporting Process. For simplicity, just say "available to the Metering Process". > varies and has to be noted when transporting MOS values. > > An IPFIX Metering Process may use these Information Elements to > convey information on the duration of the stream in which the quality > fell into the respective category as well as the measurement > algorithm used to obtain the information. > > 3.1. rtpMOSCAlg > > The values carried in this IE are taken from the "RTCP XR QoE metric > block - Calculation Algorithm" sub-registry of the "RTP Control > Protocol Extended Reports (RTCP XR) Block Type Registry" as defined > in [I-D.wu-xrblock-rtcp-xr-quality-monitoring]. > > Even when an algorithm other than G.107 is used the rtpMOSClassN > Information Elements use the R-Factor based classes as defined in the > G.107 documentation. > > Description: The calculation algorithm (CAlg) used by the Metering > Process to calculate the MOS value. > > 0: undefined: The algorithm is not known/specified. > > 1: ITU-T P.564 > > 2: G.107 > > 3: G.107 / ETSI TS 101 329-5 Annex E > > 4: ITU-T P.NAMS > > 5: ITU-T P.NBAMS > > > > > > > > Scholz Expires January 10, 2013 [Page 4] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > 6: RTCP - Real Time Control Protocol (not fefined in registry!) Typo: "defined". > > Data Type: unsigned8 > > Data Type Semantics: identifier > > PEN (provisional): tbd Don't specify PEN numbers. > > ElementId (provisional): tbd You might want to number these, eg TBD1, TBD2, ... > > The MOS values calculated are separated into MOS classes based on the > ITU-T G.107 classes. > > 3.2. rtpMOSClass1 > > Description: Number of seconds the monitored stream had a MOS > quality lower than 3.10 > > Data Type: float32 It's unusual to represent time as a float in IPFIX. Could you pick a suitable resolution (eg, milliseconds or microseconds) and export an integer? > > Data Type Semantics: deltaCounter > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.3. rtpMOSClass2 > > Description: Number of seconds the monitored stream had a MOS > quality larger than or equal 3.10 and lower than 3.60 > > Data Type: float32 > > Data Type Semantics: deltaCounter > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.4. rtpMOSClass3 > > Description: Number of seconds the monitored stream had a MOS > quality larger than or equal 3.60 and lower than 4.03 > > Data Type: float32 > > > > > > > Scholz Expires January 10, 2013 [Page 5] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > Data Type Semantics: deltaCounter > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.5. rtpMOSClass4 > > Description: Number of seconds the monitored stream had a MOS > quality larger than or equal 4.03 and lower than 4.34 > > Data Type: float32 > > Data Type Semantics: deltaCounter > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.6. rtpMOSClass5 > > Description: Number of seconds the monitored stream had a MOS > quality larger than or equal 4.34 > > Data Type: float32 > > Data Type Semantics: deltaCounter > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.7. rtpMinMOS > > Description: Minimum MOS value measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > ElementId (provisional): tbd > > > > > > > > > Scholz Expires January 10, 2013 [Page 6] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > 3.8. rtpAvgMOS > > Description: Average MOS value measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.9. rtpMaxMOS > > Description: Maximum MOS value measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.10. rtpMinRFactor > > Description: Minimum R-Factor measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > ElementId (provisional): tbd > > 3.11. rtpAvgRFactor > > Description: Average R-Factor measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > > > > > > Scholz Expires January 10, 2013 [Page 7] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > ElementId (provisional): tbd > > 3.12. rtpMaxRFactor > > Description: Maximum R-Factor measured in the monitoring interval. > > Data Type: float32 > > Data Type Semantics: quantity > > PEN (provisional): tbd > > ElementId (provisional): tbd > > > 4. Recommended Templates > > The defined RTP stream IPFIX templates must support both IPv4 and > IPv6 transport. They need to carry either flow information regarding > the entire duration of an RTP stream or specific to a shorter > observation interval. > > The template incorporates IEs from [I-D.akhter-ipfix-perfmon] to > describe the RTP stream. > > In order to correlate the RTP quality information with signaling > information (e.g. subscriber IDs) a correlation ID may be added to > the template. Note that this ID has yet to be defined and is outside > the scope of this document. Lots of TBD's from here on... P. > 4.1. Entire stream > > tbd > > 4.2. Time slice > > tbd, based on previous template. Split a single RTP stream in three > flow records as example including (empty) 'RTP stream ended' flow > record. > > > 5. Examples > > tbd > > > > > > > > Scholz Expires January 10, 2013 [Page 8] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > 6. Acknowledgements > > tbd > > > 7. IANA Considerations > > tbd > > > 8. Security Considerations > > tbd > > > 9. References > > 9.1. Normative References > > [I-D.wu-xrblock-rtcp-xr-quality-monitoring] > Hunt, G., Clark, A., Wu, W., Schott, R., and G. Zorn, > "RTCP XR Blocks for QoE metric reporting", > draft-wu-xrblock-rtcp-xr-quality-monitoring-06 (work in > progress), December 2011. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > 9.2. Informative References > > [I-D.akhter-ipfix-perfmon] > Akhter, A., "Information Elements for Flow Performance > Measurement", draft-akhter-ipfix-perfmon-00 (work in > progress), October 2010. > > [I-D.trammell-ipfix-sip-msg] > Claise, B., Trammell, B., Kaplan, H., and S. Niccolini, > "SIP Message Information Export using IPFIX", > draft-trammell-ipfix-sip-msg-02 (work in progress), > October 2011. > > > > Scholz Expires January 10, 2013 [Page 9] > > Internet-Draft RTP Streams in IPFIX July 2012 > > > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, > A., Peterson, J., Sparks, R., Handley, M., and E. > Schooler, "SIP: Session Initiation Protocol", RFC 3261, > June 2002. > > [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. > Jacobson, "RTP: A Transport Protocol for Real-Time > Applications", STD 64, RFC 3550, July 2003. > > > Author's Address > > Hendrik Scholz > VOIPFUTURE GmbH > Wendenstrasse 4 > Hamburg 20097 > Germany > > Phone: +49 40 688 900 100 > Email: hscholz@voipfuture.com > URI: http://www.voipfuture.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scholz Expires January 10, 2013 [Page 10] > From n.brownlee@auckland.ac.nz Fri Aug 3 10:27:31 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C16821F8D09 for ; Fri, 3 Aug 2012 10:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLtuyYJl6acM for ; Fri, 3 Aug 2012 10:27:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id F133D21F8D30 for ; Fri, 3 Aug 2012 10:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1344014850; x=1375550850; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=JFL9gNt5pwmGaPvsBfSEgUUAea/tBM72h1Pnj9gWxKc=; b=rkYf8uwdWq+A5RsVsDR88/JlFZJseIHliwMTp4zJSkO1fFfuP4y3ym6k 2mNv1F+fqABYg26jE6gCNoVTx1zgk+ix/aGAMrdy6leTuI5xb0KR8+E5X LadCwlq07xWGQ/d/E4FN8CkETZ4Df1QInuX4prM/S7WJJzw5+gL4Y8qmT Y=; X-IronPort-AV: E=Sophos;i="4.77,707,1336305600"; d="scan'208";a="136711956" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 04 Aug 2012 05:27:27 +1200 Message-ID: <501C09F3.7010801@auckland.ac.nz> Date: Sat, 04 Aug 2012 05:27:15 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT minutes for Vancouver meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:27:31 -0000 Hi all: Here are my DRAFT minutes for yesterday's meeting. Please email me any corrections, extra detail, etc. Cheers, Nevil DRAFT-00 Minutes of the IPFIX meeting at IETF 84 in Vancouver About 34 people present Scribes: Chris Innacio Meeting chair: Nevil Brownlee Nevil opened the meeting, pointing out that - IPFIX MIB is now RFC 6515. - PSAMP MIB has been approved, that will clear IPFIX Config Model - Flow Selection draft authors working on -12 version Brian Trammell commented on the IPFIX Aggregation Draft. He will publish a new version following the latest review, then Nevil will submit its write-up. Paul Aitken presented (via Meetecho) the Link Layer IEs draft. One open issue: sectionOfset. Discussion focussed on the problem of having multiple offset IEs in an export record, and the need to have an ofset reference base. Paul will add more text explaining this. WGLC after next version. Paul presented the MIB Variable Export draft. This is the -00 version, it has 20 open issues. He'll continue to work on them. Brian presented the 'IE-Doctors' draft. This has completed IETF LC, drawing many useful comments, these will be incorporated in a new version. It has two open issues: - Enterprise-Specific IEs, i.e. how to transition an IE from ES into the IE Registry. Two approaches were presented (see slides), no clear consensus was reached - discussion will continue on the list. - Deprecating an IE Consensus that 'Deprecated, SHOULD NOT be used' is enough. New version when when the ES issue is resolved, than back to our AD. Brian We need to discuss this in more detail on the list. Brian presented our 5101bis draft. - The changes discussed in Paris have been made, there is a little more editing work to do - We need to do some more testing, to make sure that all the features described in the document do interoperate properly . IPFIX implementers will try to arange this in Atlanta, during IETF-85 Aiming for WGLC after Atlanta. Brian presented our 5102bis draft. - The IANA IE Registry is now the canonical source of information about IEs. The registry can still use 5102 as a reference - 5102 will have the RFC Editor note ("Obsoleted by ...), pointing readers to the 5102bis RFC We will run the WG LC for this in paralell with that for 5101bis. Brian presented our Mediation Protocol draft. - This has been completely reorganised, it has many open issues - We need reviews for this. Please read it and post to the list! Aim for WGLC after Atlanta. Paul Aitken presented his 'Unobserved Fields' draft. - Read by at least four people in the room, clearly this would provide a useful feature - Could - one day - become a WG item Needs more discussion on the list. Hendrik Scholtz presented his 'VoIP Information elements' drafts. - These cover 'VoIP performance, and 'audio quality.' - Two open issues - The IEs here are for metrics defined in other WGs, These drafts cover how that information is transported using IPFIX The authors will develop the drafts further before Atlanta. Chris Innacio presented his "XML Enterprise Registry' draft. - Adresses the question "what do you need to describe your Enterprise IEs? - Considerable interest, this solves a real problem Comments on the list are encouraged. Discussion of "how should we handle conflicts between IE registration requests?" - At present, IANA need AD agreement to allocate code points for IEs described in a draft - Barry Leiba is working on updates to "IANA Considerations Guidelines" (5622bis) Nevil will discuss this issue with him. The IPFIX Milestones were discussed, Nevil will update them. The meeting finished at 1445. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Fri Aug 3 15:30:16 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5511E80D7 for ; Fri, 3 Aug 2012 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwF+CFy2C3Ep for ; Fri, 3 Aug 2012 15:30:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8899711E809C for ; Fri, 3 Aug 2012 15:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=202; q=dns/txt; s=iport; t=1344033015; x=1345242615; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0I08rvg9N3yKNunI1sxE9tgOe9Q79RSdkh7/63bQaF8=; b=B4MfuLsYxecDWQidWfx6PvFrN1h6lheYSI91WI9qanlXQoiKquR1KrqP gxzEsVutK3bDEH2TzRSpKK/Z14a5FHK7pCyp6kRs8AgBwvxnEAE+q/Jzs b3jlfkm3jNyYClXg+BNZs6PgNYqjxXFfzk5a1ExwdmVNkMFm7gSs4YvnX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIHAKJPHFCQ/khN/2dsb2JhbABEDo1kq0aBB4IhAQEEEgElQAEQCw4TFg8JAwIBAgFFBg0BBwEBHodrnF+gF5JMA5VKhVuITIFmgiY6 X-IronPort-AV: E=Sophos;i="4.77,709,1336348800"; d="scan'208";a="75773796" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 Aug 2012 22:30:14 +0000 Received: from [10.61.99.84] (dhcp-10-61-99-84.cisco.com [10.61.99.84]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q73MUE5v024181; Fri, 3 Aug 2012 22:30:14 GMT Message-ID: <501C50F6.9000003@cisco.com> Date: Fri, 03 Aug 2012 23:30:14 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nevil Brownlee References: <501C09F3.7010801@auckland.ac.nz> In-Reply-To: <501C09F3.7010801@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] DRAFT minutes for Vancouver meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:30:16 -0000 Nevil, > - Barry Leiba is working on updates to "IANA Considerations > Guidelines" (5622bis) > Nevil will discuss this issue with him. It's 5226-bis: draft-leiba-cotton-iana-5226bis. P. From michael.krueger@voipfuture.com Mon Aug 6 04:06:01 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC42821F8616 for ; Mon, 6 Aug 2012 04:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-1.683, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV+t5-oInFkI for ; Mon, 6 Aug 2012 04:06:00 -0700 (PDT) Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7947C21F8617 for ; Mon, 6 Aug 2012 04:05:59 -0700 (PDT) X-Footer: dm9pcGZ1dHVyZS5jb20= Received: from Mickru-MacBook.local ([192.168.1.1]) (authenticated user mkrueger@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.4.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Mon, 6 Aug 2012 12:51:46 +0200 Message-ID: <501FA50A.30501@voipfuture.com> Date: Mon, 06 Aug 2012 13:05:46 +0200 From: =?UTF-8?B?TWljaGFlbCBLcsO8Z2Vy?= Organization: VOIPFUTURE User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Paul Aitken References: <501BF904.6090401@cisco.com> In-Reply-To: <501BF904.6090401@cisco.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hscholz@voipfuture.com, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 11:06:01 -0000 Hi Hendrik, Am 03.08.12 18:15, schrieb Paul Aitken: > Hendrik, > > >> >> Network Working Group H. Scholz >> Internet-Draft VOIPFUTURE GmbH >> Intended status: Informational July 9, 2012 >> Expires: January 10, 2013 >> >> >> RTP Stream Quality Information Export using IPFIX >> draft-scholz-ipfix-rtp-audio-quality-00 >> >> Abstract >> >> This draft defines a set of Information Elements and matching > > Remove "matching" > > >> Templates to convey RTP media stream quality information in IPFIX >> packets. The Information Elements describe the RTP quality using the >> R-factor and Mean Opinion score (MOS) for the entire duration of a >> monitored stream or for a smaller time slice thereof. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on January 10, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> >> >> Scholz Expires January 10, 2013 [Page 1] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> This document may contain material from IETF Documents or IETF >> Contributions published or made publicly available before November >> 10, 2008. The person(s) controlling the copyright in some of this >> material may not have granted the IETF Trust the right to allow >> modifications of such material outside the IETF Standards Process. >> Without obtaining an adequate license from the person(s) controlling >> the copyright in such materials, this document may not be modified >> outside the IETF Standards Process, and derivative works of it may >> not be created outside the IETF Standards Process, except to format >> it for publication as an RFC or to translate it into languages other >> than English. >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.1.1. Quality of Service (QoS) Monitoring . . . . . . . . . 3 >> 1.1.2. Service Level Agreement (SLA) . . . . . . . . . . . . 3 >> 1.1.3. Troubleshooting . . . . . . . . . . . . . . . . . . . 3 >> 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3. MOS measurement . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3.1. rtpMOSCAlg . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3.2. rtpMOSClass1 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.3. rtpMOSClass2 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.4. rtpMOSClass3 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.5. rtpMOSClass4 . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.6. rtpMOSClass5 . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.7. rtpMinMOS . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.8. rtpAvgMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.9. rtpMaxMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.10. rtpMinRFactor . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.11. rtpAvgRFactor . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.12. rtpMaxRFactor . . . . . . . . . . . . . . . . . . . . . . 8 >> 4. Recommended Templates . . . . . . . . . . . . . . . . . . . . 8 >> 4.1. Entire stream . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.2. Time slice . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 >> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 >> 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 >> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 >> 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 >> 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 2] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 1. Introduction >> >> IPFIX [RFC5101] and [RFC5102] define a framework allowing to export > > NB these references will need to be updated to -bis. > > "the export of arbitrary data". > > >> arbitrary data from so called IPFIX exporters. One type of IPFIX > > Why "so called"? They *are* IPFIX exporters! > > >> exporter may be co-located with Session Initiation Protocol (SIP) > > At least, the IPFIX Device's Metering Process is co-located with the SIP > devices / calls. The Exporting Process may be remote; you don't care. > > >> [RFC3261] based VoIP entities or passively observe SIP based VoIP >> calls. The signaling messages can be exported using >> [I-D.trammell-ipfix-sip-msg] and Real Time Protocol (RTP) [RFC3550] >> media streams are covered in [I-D.akhter-ipfix-perfmon]. Media >> quality is out of the scope of both these documents. This document >> defines a set of additional IPFIX Information Elements (IEs) to >> describe RTP audio stream quality. >> >> 1.1. Use Cases >> >> RTP stream flow information contained in IPFIX flow records can be >> used for various tasks such as Quality of Service (QoS) monitoring, >> Service Level Agreement (SLA) validation and general troubleshooting >> of VoIP networks. >> >> 1.1.1. Quality of Service (QoS) Monitoring >> >> Aggregated to higher-level metrics the in-depth information provided >> by the RTP (and optionally SIP) flow records allow service providers >> to gauge the overall quality of their network in terms of the quality >> of experience (QoE). On this level an individual call is less >> important but the overall quality (e.g. amount of minutes meeting >> certain quality standards) can be used to get a quick overview on the >> network and service performance. >> >> 1.1.2. Service Level Agreement (SLA) >> >> SLAs are typically used as part of contracts between two network >> operators. The requirements on the reliability of the data may be >> higher compared to QoS Monitoring as the failure to meet >> contractually agreed quality standards often has a direct commercial >> impact. >> >> 1.1.3. Troubleshooting >> >> An active network component (SIP proxy, B2BUA, media server) may not >> have the capabilities to store session related information for a long >> time to facilitate troubleshooting capabilities (e.g. due to missing >> hard-disk). Such a system or a group of systems may run the metering >> process and export the data to a collector for processing or > > say "run a Metering Process and export IPFIX to a Collecting Process for > ...", since MP and CP are 5101 terms. > > >> troubleshooting purposes. > > You might want to have a terminology section here, if only to refer > readers to 5101. See how the other IPFIX drafts do this. > > >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 3] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 2. Conventions >> >> 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 RFC 2119 [RFC2119]. >> >> >> 3. MOS measurement >> >> A multitude of Mean Opinion Score (MOS) assessment algorithms have >> been defined of which only one or few may be available to an IPFIX >> Metering Process. The quality (i.e. accuracy) of these algorithms > > Technically it's not an "IPFIX Metering Process" - it's a SIP Metering > Process connected to an IPFIX Exporting Process. > For simplicity, just say "available to the Metering Process". > > >> varies and has to be noted when transporting MOS values. >> >> An IPFIX Metering Process may use these Information Elements to >> convey information on the duration of the stream in which the quality >> fell into the respective category as well as the measurement >> algorithm used to obtain the information. >> >> 3.1. rtpMOSCAlg >> >> The values carried in this IE are taken from the "RTCP XR QoE metric >> block - Calculation Algorithm" sub-registry of the "RTP Control >> Protocol Extended Reports (RTCP XR) Block Type Registry" as defined >> in [I-D.wu-xrblock-rtcp-xr-quality-monitoring]. >> >> Even when an algorithm other than G.107 is used the rtpMOSClassN >> Information Elements use the R-Factor based classes as defined in the >> G.107 documentation. >> >> Description: The calculation algorithm (CAlg) used by the Metering >> Process to calculate the MOS value. >> >> 0: undefined: The algorithm is not known/specified. >> >> 1: ITU-T P.564 >> >> 2: G.107 >> >> 3: G.107 / ETSI TS 101 329-5 Annex E >> >> 4: ITU-T P.NAMS >> >> 5: ITU-T P.NBAMS >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 4] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 6: RTCP - Real Time Control Protocol (not fefined in registry!) > > Typo: "defined". > > >> >> Data Type: unsigned8 >> >> Data Type Semantics: identifier >> >> PEN (provisional): tbd > > Don't specify PEN numbers. > > >> >> ElementId (provisional): tbd > > You might want to number these, eg TBD1, TBD2, ... > > >> >> The MOS values calculated are separated into MOS classes based on the >> ITU-T G.107 classes. >> >> 3.2. rtpMOSClass1 >> >> Description: Number of seconds the monitored stream had a MOS >> quality lower than 3.10 >> >> Data Type: float32 > > It's unusual to represent time as a float in IPFIX. Could you pick a > suitable resolution (eg, milliseconds or microseconds) and export an > integer? > The purpose of these IE items is to report the amount of full seconds VoIP streams have been in either one of these 5 MOS classes. So I suggest to change the type to unsigned64. Regards, Michael > >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.3. rtpMOSClass2 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 3.10 and lower than 3.60 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.4. rtpMOSClass3 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 3.60 and lower than 4.03 >> >> Data Type: float32 >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 5] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.5. rtpMOSClass4 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 4.03 and lower than 4.34 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.6. rtpMOSClass5 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 4.34 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.7. rtpMinMOS >> >> Description: Minimum MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 6] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 3.8. rtpAvgMOS >> >> Description: Average MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.9. rtpMaxMOS >> >> Description: Maximum MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.10. rtpMinRFactor >> >> Description: Minimum R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.11. rtpAvgRFactor >> >> Description: Average R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 7] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> ElementId (provisional): tbd >> >> 3.12. rtpMaxRFactor >> >> Description: Maximum R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> >> 4. Recommended Templates >> >> The defined RTP stream IPFIX templates must support both IPv4 and >> IPv6 transport. They need to carry either flow information regarding >> the entire duration of an RTP stream or specific to a shorter >> observation interval. >> >> The template incorporates IEs from [I-D.akhter-ipfix-perfmon] to >> describe the RTP stream. >> >> In order to correlate the RTP quality information with signaling >> information (e.g. subscriber IDs) a correlation ID may be added to >> the template. Note that this ID has yet to be defined and is outside >> the scope of this document. > > Lots of TBD's from here on... > > P. > >> 4.1. Entire stream >> >> tbd >> >> 4.2. Time slice >> >> tbd, based on previous template. Split a single RTP stream in three >> flow records as example including (empty) 'RTP stream ended' flow >> record. >> >> >> 5. Examples >> >> tbd >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 8] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 6. Acknowledgements >> >> tbd >> >> >> 7. IANA Considerations >> >> tbd >> >> >> 8. Security Considerations >> >> tbd >> >> >> 9. References >> >> 9.1. Normative References >> >> [I-D.wu-xrblock-rtcp-xr-quality-monitoring] >> Hunt, G., Clark, A., Wu, W., Schott, R., and G. Zorn, >> "RTCP XR Blocks for QoE metric reporting", >> draft-wu-xrblock-rtcp-xr-quality-monitoring-06 (work in >> progress), December 2011. >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC5101] Claise, B., "Specification of the IP Flow Information >> Export (IPFIX) Protocol for the Exchange of IP Traffic >> Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. >> Meyer, "Information Model for IP Flow Information Export", >> RFC 5102, January 2008. >> >> 9.2. Informative References >> >> [I-D.akhter-ipfix-perfmon] >> Akhter, A., "Information Elements for Flow Performance >> Measurement", draft-akhter-ipfix-perfmon-00 (work in >> progress), October 2010. >> >> [I-D.trammell-ipfix-sip-msg] >> Claise, B., Trammell, B., Kaplan, H., and S. Niccolini, >> "SIP Message Information Export using IPFIX", >> draft-trammell-ipfix-sip-msg-02 (work in progress), >> October 2011. >> >> >> >> Scholz Expires January 10, 2013 [Page 9] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, >> A., Peterson, J., Sparks, R., Handley, M., and E. >> Schooler, "SIP: Session Initiation Protocol", RFC 3261, >> June 2002. >> >> [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. >> Jacobson, "RTP: A Transport Protocol for Real-Time >> Applications", STD 64, RFC 3550, July 2003. >> >> >> Author's Address >> >> Hendrik Scholz >> VOIPFUTURE GmbH >> Wendenstrasse 4 >> Hamburg 20097 >> Germany >> >> Phone: +49 40 688 900 100 >> Email: hscholz@voipfuture.com >> URI: http://www.voipfuture.com/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 10] >> > From michael.krueger@voipfuture.com Mon Aug 6 05:14:35 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6321F8585 for ; Mon, 6 Aug 2012 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mapuAwuc+xyU for ; Mon, 6 Aug 2012 05:14:34 -0700 (PDT) Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 584E421F8541 for ; Mon, 6 Aug 2012 05:14:34 -0700 (PDT) X-Footer: dm9pcGZ1dHVyZS5jb20= Received: from mickru-macbook.voipfuture.com ([192.168.1.1]) (authenticated user mkrueger@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.4.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Mon, 6 Aug 2012 14:00:29 +0200 Message-ID: <501FB525.9010507@voipfuture.com> Date: Mon, 06 Aug 2012 14:14:29 +0200 From: =?UTF-8?B?TWljaGFlbCBLcsO8Z2Vy?= Organization: VOIPFUTURE User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hscholz@voipfuture.com References: <501BF904.6090401@cisco.com> <501FA50A.30501@voipfuture.com> In-Reply-To: <501FA50A.30501@voipfuture.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:14:35 -0000 Hi Hendrik, >>> >>> 3.2. rtpMOSClass1 >>> >>> Description: Number of seconds the monitored stream had a MOS >>> quality lower than 3.10 >>> >>> Data Type: float32 >> >> It's unusual to represent time as a float in IPFIX. Could you pick a >> suitable resolution (eg, milliseconds or microseconds) and export an >> integer? >> > The purpose of these IE items is to report the amount of full seconds > VoIP streams have been in either one of these 5 MOS classes. So I > suggest to change the type to unsigned64. > > Regards, > Michael > I did some math and really believe this should be an unsigned 64-bit value. Since the purpose of this IE is to provide an aggregation over all flows carried e.g. over a SIP trunk / carrier-interconnection the worst case would be potentially many millions of flows aggregated. Reporting the quality like this for a single flow is possible, but likely not the general application. A 32-bit resolution to report quality distribution of full day would only be sufficient for 49k flows or 24k bi-flows / calls. That doesn't seem to be a lot for quality reporting on a daily basis on a carrier-interconnection. Therefore unsigned64 with units = seconds seems for me the way to go. Regards, Michael From andrewf@plixer.com Mon Aug 6 05:33:36 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284AE21F86AA for ; Mon, 6 Aug 2012 05:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+n6FdIdMWyi for ; Mon, 6 Aug 2012 05:33:35 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8640421F8691 for ; Mon, 6 Aug 2012 05:33:35 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Aug 2012 08:33:34 -0400 Message-ID: <501FB99D.3010508@plixer.com> Date: Mon, 06 Aug 2012 08:33:33 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Kr=FCger?= References: <501BF904.6090401@cisco.com> <501FA50A.30501@voipfuture.com> <501FB525.9010507@voipfuture.com> In-Reply-To: <501FB525.9010507@voipfuture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Aug 2012 12:33:34.0233 (UTC) FILETIME=[B1D17090:01CD73CF] Cc: hscholz@voipfuture.com, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:33:36 -0000 If in doubt just go with the unsigned64. It is always possible for an implementation to use reduced length encoding and send fewer bytes if that implementation doesn't need all 8 bytes. -Andrew On 08/06/2012 08:14 AM, Michael Krüger wrote: > Hi Hendrik, > >>>> 3.2. rtpMOSClass1 >>>> >>>> Description: Number of seconds the monitored stream had a MOS >>>> quality lower than 3.10 >>>> >>>> Data Type: float32 >>> It's unusual to represent time as a float in IPFIX. Could you pick a >>> suitable resolution (eg, milliseconds or microseconds) and export an >>> integer? >>> >> The purpose of these IE items is to report the amount of full seconds >> VoIP streams have been in either one of these 5 MOS classes. So I >> suggest to change the type to unsigned64. >> >> Regards, >> Michael >> > I did some math and really believe this should be an unsigned 64-bit > value. Since the purpose of this IE is to provide an aggregation over > all flows carried e.g. over a SIP trunk / carrier-interconnection the > worst case would be potentially many millions of flows aggregated. > Reporting the quality like this for a single flow is possible, but > likely not the general application. > A 32-bit resolution to report quality distribution of full day would > only be sufficient for 49k flows or 24k bi-flows / calls. That doesn't > seem to be a lot for quality reporting on a daily basis on a > carrier-interconnection. Therefore unsigned64 with units = seconds seems > for me the way to go. > > Regards, > Michael > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Mon Aug 6 08:11:20 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9808621F8621 for ; Mon, 6 Aug 2012 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41ATHrvy1lyt for ; Mon, 6 Aug 2012 08:11:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 649B621F8548 for ; Mon, 6 Aug 2012 08:11:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q76FBA81015155 for ; Mon, 6 Aug 2012 17:11:10 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q76FBAOB029282 for ; Mon, 6 Aug 2012 17:11:10 +0200 (CEST) Message-ID: <501FDE8E.9030001@cisco.com> Date: Mon, 06 Aug 2012 17:11:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <501AFA50.10508@cisco.com> In-Reply-To: <501AFA50.10508@cisco.com> X-Forwarded-Message-Id: <501AFA50.10508@cisco.com> Content-Type: multipart/alternative; boundary="------------060505010207030201010604" Subject: [IPFIX] RFC 2026 versus RFC6410: progressing a document X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:11:20 -0000 This is a multi-part message in MIME format. --------------060505010207030201010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, And I'm trying to compare the conditions to progress a document in RFC 2026 and 6410 RFC 2026: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification.In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. RFC 6410 The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a document advances from Proposed Standard to Internet Standard. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. After confirmation from the IESG, we don't need to test _every single _feature from the specifications to progress the draft. However, the 4 points above must be respected. Regards, Benoit --------------060505010207030201010604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

And I'm trying to compare the conditions to progress a document in RFC 2026 and 6410

RFC 2026:
   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

RFC 6410
   The IESG, in an IETF-wide Last Call of at least four weeks, confirms
   that a document advances from Proposed Standard to Internet Standard.
   The request for reclassification is sent to the IESG along with an
   explanation of how the criteria have been met.  The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

After confirmation from the IESG, we don't need to test every single feature from the specifications to progress the draft.
However, the 4 points above must be respected.

Regards, Benoit




--------------060505010207030201010604-- From ietf@meetecho.com Tue Aug 7 15:44:55 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6230111E80D5 for ; Tue, 7 Aug 2012 15:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.914 X-Spam-Level: X-Spam-Status: No, score=0.914 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmtKDRhPFw72 for ; Tue, 7 Aug 2012 15:44:54 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id 353E211E80E5 for ; Tue, 7 Aug 2012 15:44:51 -0700 (PDT) Received: (qmail 28311 invoked by uid 89); 7 Aug 2012 22:44:50 -0000 Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq04.aruba.it with SMTP; 7 Aug 2012 22:44:50 -0000 Received: (qmail 2293 invoked by uid 89); 7 Aug 2012 22:44:50 -0000 Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp6.ad.aruba.it with ESMTPA; 7 Aug 2012 22:44:49 -0000 Message-ID: <50219A53.4020606@meetecho.com> Date: Wed, 08 Aug 2012 00:44:35 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [IPFIX] Meetecho session recording available X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:44:55 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of IPFIX session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_IPFIX For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From paitken@cisco.com Mon Aug 13 10:12:54 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347C321F86DA for ; Mon, 13 Aug 2012 10:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLL8971GClFL for ; Mon, 13 Aug 2012 10:12:53 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6D21F8582 for ; Mon, 13 Aug 2012 10:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=567; q=dns/txt; s=iport; t=1344877973; x=1346087573; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=uN5YM58p+mZg2IHV7HSFV4FJLe1oOvirYeBbi4gqqKw=; b=fOtlkWlNGZ1Und9WSSRXKsZbIFPJBH9esF/E03aMMYThJ5Wq+YESxeux zfjmX9uXYYpwbn8TV4JkJtwmi1/4BqZPVgDuewzJlQaNxLkR5N1Xx3mq7 KzrLpifL++IKWAiZ/PDBolUQjaCH/2gxVyKxoA3z7T+cJRKoOVxiGkgoH A=; X-IronPort-AV: E=Sophos;i="4.77,761,1336348800"; d="scan'208";a="7305456" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 13 Aug 2012 17:12:52 +0000 Received: from [10.61.94.173] (ams3-vpn-dhcp7854.cisco.com [10.61.94.173]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7DHCpZT029503; Mon, 13 Aug 2012 17:12:51 GMT Message-ID: <50293594.4030006@cisco.com> Date: Mon, 13 Aug 2012 18:12:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "ipfix-chairs@tools.ietf.org" , "Benoit Claise (bclaise)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: [IPFIX] IANA IPFIX announcement mailing list? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:12:54 -0000 Dear Chairs, AD, Could IANA support an IPFIX-announce mailing list, to which new information element allocations / changes / etc are sent? ie, a lower-volume mailing list than the IPFIX list, for those who are only interested in new IEs. Else, can the IPFIX mailing list survive in perpetuity, with IANA posting announcements there with a special/known/fixed format which can easily be filtered? Today, announcements may, or may not, be sent to the IPFIX list; there's no official policy. Perhaps IE-doctors should discuss this. Thanks, P. From n.brownlee@auckland.ac.nz Thu Aug 16 21:33:56 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA311E808D for ; Thu, 16 Aug 2012 21:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta+s9-7gQt9o for ; Thu, 16 Aug 2012 21:33:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A211E80BA for ; Thu, 16 Aug 2012 21:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1345178031; x=1376714031; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=FMgswynLMt8LJhQpK/gsHdchFJ9ON1gf9wD42bZJYog=; b=h4B6HbsUYNN4rXcyQxT6Ey4xWwVZs/XCdNocaAIyg8ElcmTAqmCDS2hQ 6slRtHLaFwwgS3EsnMjF+NfHeDl1xf1hHkSh+jH8y2AUZwEXbnAEqXtTo UFqeAd3LEfSmZY9zLTTOpTQVeumcW5KR1Oaxe6AxRGs9AYAmg0ye6uUyL Y=; X-IronPort-AV: E=Sophos;i="4.77,783,1336305600"; d="scan'208";a="139739036" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 17 Aug 2012 16:33:47 +1200 Message-ID: <502DC9AA.9080302@auckland.ac.nz> Date: Fri, 17 Aug 2012 16:33:46 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX Working Group References: <4FDC9E8B.1070800@cisco.com> <4FDE112B.40706@net.in.tum.de> <4FE88612.1080702@cisco.com> <4FE896DE.6050908@net.in.tum.de> <4FE89B1A.5060301@cisco.com> <4FE89EE0.9020409@net.in.tum.de> <4FEECE19.4080003@net.in.tum.de> <397E0C84-8482-4C4F-B1A3-95D42DEFA1E5@cisco.com> In-Reply-To: <397E0C84-8482-4C4F-B1A3-95D42DEFA1E5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] new monitoring interval information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 04:33:57 -0000 Hi all: Some time back Paul Aitken asked IANA for two new IEs to describe "monitoringInterval." There was some discussion of these in June~July, but no clear consensus. The last email on this was from Andrew Johnson (below). To me Andrew's definitions seem reasonable; can we go ahead with them, or can anyone offer further improvements? Cheers, Nevil On 7/07/12 1:42 AM, Andrew Johnson wrote: > Hi Gerhard > > There is more than one way to present the model I describe. It would seem to be valid to suggest that the Metering Process is re-initialising every interval and you could use delta or total counts, but you would also have to honour all the other aspects of re-initialising the Metering Process, like resetting any Metering Process statistics being gathered. I think this model would add a requirement on any Collecting Process to understand new IEs that describe the Metering Process re-initialisation in order to properly understand the total counts. > > I would like to model this using the idea that the interval is a common property (i.e. key field) of the flow. Again, delta counts or total counts *could* be used, because once a certain window has passed the new flows would have a different set of keys. Delta counts make more sense though, because then the collector doesn't have to be configured to understand that the interval is the key. The collector would be free to aggregate as it needs, with the ability to: > * show the aggregate view of flows, i.e. aggregate each flow across intervals > * show the whole network over time, i.e. aggregate all flows per interval > * show how a flow evolves over time, i.e. filter out a flow and display the per-interval info > > > The problem we are having, is to accurately define IEs that can describe the beginning and end of this interval. I was hoping that by laying out the model, we could get some consensus on the model and the IE definitions. My initial suggestion was: > > observationWindowStart dateTimeMilliseconds The absolute timestamp of the beginning of the current Observation Window. > observationWindowEnd dateTimeMilliseconds The absolute timestamp of the end of the current Observation Window. > > > but Observation Window is undefined. I'm open to suggestions on improving these. Perhaps: > > meteringIntervalStart dateTimeMilliseconds The absolute timestamp of beginning of the Metering > Interval the observation occurred in. Where a > series of Metering Intervals separates time into a > a set of discrete buckets of a configurable length. > meteringIntervalEnd dateTimeMilliseconds The absolute timestamp of the end of the Metering > Interval the observation occurred in. See > meteringIntervalStart. > > > Cheers, Andrew > > > On 30 Jun 2012, at 10:59, Gerhard Muenz wrote: >> Andrew, >> >> As I pointed out in my previous mail, the window IEs do not seem to be compatible with the descriptions of existing *TotalCount IEs because these refer to the time since (re-)initialization. You could use *DeltaCount, though. >> >> Gerhard >> >> >> On 29.06.2012 01:25, Andrew Johnson wrote: >>> Hi Gerhard >>> >>> Thanks for your inputs on this thread. It seems to me that the idea of "re-initialising" the Metering Process is pretty confusing, in light of what we're actually doing. I think my mental mode of what is happening is a bit different from Paul's, so let me start at the beginning, show how I think of the behaviour, and see what we can come up with to solve our problem. >>> >>> We would like to split the monitored packet streams into discrete buckets, based on time. >>> >>> t0 -----> t1 -----> t2 -----> t3 -----> t4 -----> t5 -----> >>> >>> >>> The packet stream is processed by the Metering Process as usual, and flows form in the cache in the usual manner. However, observations from one interval won't be merged with observations from a different interval. Ideally, at the end of each interval, all flows are exported and flushed from the cache. >>> >>> There are several ways to think about this. One way is to explicitly flush the cache at the end of each interval (i.e. reset / reinitialise the Metering Process). The way I see it though, we could just make an identifier of the current interval a key field and apply the optimisation of allowing flows from outside the current interval to be flushed from the cache ASAP, since we know they won't be updated again. >>> >>> Hopefully that gives a bit of a bigger picture. What we are looking for are two new fields that we can add to the flows, that identify the beginning at end of the interval they were observed in. In some circumstances the device may not fully stick to the provided interval window, so we can't rely on the end of the interval really being the intervalStart + intervalSize. >>> >>> I was thinking of: >>> >>> observationWindowStart dateTimeMilliseconds The absolute timestamp of the beginning of the current Observation Window. >>> observationWindowEnd dateTimeMilliseconds The absolute timestamp of the end of the current Observation Window. >>> >>> >>> However, Paul rightly pointed out to me that IPFIX doesn't have any concept of an Observation Window, and we're not sure how we can define that in description of the IE. The idea of re-initialising the Metering Process may fit in with the current IPFIX model, but I don't think it properly conveys the behaviour we're after. >>> >>> >>> Kind regards, >>> >>> Andrew >>> >>> >>> On 25 Jun 2012, at 18:24, Gerhard Muenz wrote: >>>> Paul, >>>> >>>> It depends on what kind of interval you want to specify. >>>> >>>> If you want to specify the (re-)initialization time of the Metering Process, why not name the IE meteringProcessSysUpTime or (if you do not like sysup) meteringProcessInitializationTime? >>>> And mention (re-)initialization in the description? >>>> Dito for exportingProcessInitializationTime etc. >>>> >>>> If we need the stop time, you can use meteringProcessStopTime or so. >>>> >>>> If you want to define a new interval which is not starting at (re-)initialization time but later, then your definitions are ok. But this means that you need to specify new counter elements for this interval. >>>> >>>> Thanks, >>>> Gerhard >>>> >>>> >>>> On 25.06.2012 19:08, Paul Aitken wrote: >>>>> Gerhard, >>>>> >>>>>> Ok, I see the difference to discontinuity time. >>>>>> >>>>>> Some further thoughts: >>>>>> >>>>>> The common understanding is that the "time since re-initialization" >>>>>> means sysUpTime. For example, have a look at the description of >>>>>> flowEndSysUpTime: >>>>>> "The relative timestamp of the last packet of this Flow. It indicates >>>>>> the number of milliseconds since the last (re-)initialization of the >>>>>> IPFIX Device (sysUpTime)." >>>>> >>>>> Yes, sysUpTime (so specifically, flowStartSysUpTime and >>>>> flowEndSysUpTime), are times "since the last (re-)initialization of the >>>>> IPFIX Device". >>>>> >>>>> These are not necessarily related to the metering process. >>>>> >>>>> Taking some other examples: octetTotalCount, packetTotalCount, >>>>> droppedOctetTotalCount, droppedPacketTotalCount, observedFlowTotalCount, >>>>> ignoredPacketTotalCount, ignoredOctetTotalCount, >>>>> postMCastOctetTotalCount, ... are all of the form: >>>>> >>>>> "The total number of X since the Metering Process >>>>> (re-)initialization for this Observation Point." >>>>> >>>>> We could suppose that the Metering Process initialised at system uptime. >>>>> However, that may not be the case: it could have started any amount of >>>>> time later. eg, a user could configure a Metering Process at any time. >>>>> Or, an automated system could start and stop Metering Processes >>>>> according to different times of day or different network conditions. >>>>> Without timestamps to tell us, we simply do not know. >>>>> >>>>> >>>>> >>>>>> Your proposed IEs do not mention neither (re-)initialization nor >>>>>> sysUpTime. They rather seem to specify a time interval which is >>>>>> located somewhere within the sysuptime interval. Hence, the interval >>>>>> does not work to define the time frame of exportedMessageTotalCount, >>>>>> for example. You would need to define a new IE >>>>>> exportedMessageInMonitoringInterval. >>>>> >>>>> Indeed, because the IEs which I'm specifying here are particular to the >>>>> Monitoring Process, whereas exportedMessageTotalCount seems to require a >>>>> time reference for the Exporting Process. It's a related, though >>>>> different, issue. >>>>> >>>>> (ie, the Exporting Process may start from system init, or at any time >>>>> since then. It may have been started before, or after, the Metering >>>>> Process. Without a suitable timestamp IE, we simply do not know.) >>>>> >>>>> >>>>>> The different IE descriptions suggest that the time of >>>>>> re-initialization (i.e. sysuptime) can be different for Metering >>>>>> Process, Exporting Process etc. >>>>> >>>>> Indeed this is so. There is no necessity for these to be the same. >>>>> >>>>> >>>>>> It seems that we need IE to export sysUpTime for each process. >>>>> >>>>> We agree. >>>>> >>>>> So in principal, you understand what I'm trying to do. However, you >>>>> would like clearer definitions of the Information Elements? >>>>> >>>>> Thanks, >>>>> P. >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Mon Aug 20 03:53:35 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6721F85C3 for ; Mon, 20 Aug 2012 03:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjBXzeOmT41o for ; Mon, 20 Aug 2012 03:53:34 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C921F8615 for ; Mon, 20 Aug 2012 03:53:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 38B72D9308; Mon, 20 Aug 2012 12:53:32 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8NP7BQOB-eNB; Mon, 20 Aug 2012 12:53:31 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A036CD9307; Mon, 20 Aug 2012 12:53:31 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <502DC9AA.9080302@auckland.ac.nz> Date: Mon, 20 Aug 2012 12:53:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77866394-11A9-442A-8E6D-34D5BD8E1920@tik.ee.ethz.ch> References: <4FDC9E8B.1070800@cisco.com> <4FDE112B.40706@net.in.tum.de> <4FE88612.1080702@cisco.com> <4FE896DE.6050908@net.in.tum.de> <4FE89B1A.5060301@cisco.com> <4FE89EE0.9020409@net.in.tum.de> <4FEECE19.4080003@net.in.tum.de> <397E0C84-8482-4C4F-B1A3-95D42DEFA1E5@cisco.com> <502DC9AA.9080302@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1278) Cc: IPFIX Working Group Subject: Re: [IPFIX] new monitoring interval information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 10:53:35 -0000 Hi Nevil, all, This seems reasonable; however, I'd ask what the semantic difference is = between these IEs and those defined for the same purpose in RFC5655 = (minFlowStart* and maxFlowEnd*, IEs 261, 265, 268-273). Cheers, Brian On Aug 17, 2012, at 6:33 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > Some time back Paul Aitken asked IANA for two new IEs to > describe "monitoringInterval." There was some discussion of these > in June~July, but no clear consensus. The last email on this was > from Andrew Johnson (below). >=20 > To me Andrew's definitions seem reasonable; can we go ahead with > them, or can anyone offer further improvements? >=20 > Cheers, Nevil >=20 >=20 > On 7/07/12 1:42 AM, Andrew Johnson wrote: >> Hi Gerhard >>=20 >> There is more than one way to present the model I describe. It would = seem to be valid to suggest that the Metering Process is re-initialising = every interval and you could use delta or total counts, but you would = also have to honour all the other aspects of re-initialising the = Metering Process, like resetting any Metering Process statistics being = gathered. I think this model would add a requirement on any Collecting = Process to understand new IEs that describe the Metering Process = re-initialisation in order to properly understand the total counts. >>=20 >> I would like to model this using the idea that the interval is a = common property (i.e. key field) of the flow. Again, delta counts or = total counts *could* be used, because once a certain window has passed = the new flows would have a different set of keys. Delta counts make = more sense though, because then the collector doesn't have to be = configured to understand that the interval is the key. The collector = would be free to aggregate as it needs, with the ability to: >> * show the aggregate view of flows, i.e. aggregate each flow across = intervals >> * show the whole network over time, i.e. aggregate all flows per = interval >> * show how a flow evolves over time, i.e. filter out a flow and = display the per-interval info >>=20 >>=20 >> The problem we are having, is to accurately define IEs that can = describe the beginning and end of this interval. I was hoping that by = laying out the model, we could get some consensus on the model and the = IE definitions. My initial suggestion was: >>=20 >> observationWindowStart dateTimeMilliseconds The absolute = timestamp of the beginning of the current Observation Window. >> observationWindowEnd dateTimeMilliseconds The absolute = timestamp of the end of the current Observation Window. >>=20 >>=20 >> but Observation Window is undefined. I'm open to suggestions on = improving these. Perhaps: >>=20 >> meteringIntervalStart dateTimeMilliseconds The absolute = timestamp of beginning of the Metering >> Interval the = observation occurred in. Where a >> series of Metering = Intervals separates time into a >> a set of discrete = buckets of a configurable length. >> meteringIntervalEnd dateTimeMilliseconds The absolute = timestamp of the end of the Metering >> Interval the = observation occurred in. See >> = meteringIntervalStart. >>=20 >>=20 >> Cheers, Andrew >>=20 >>=20 >> On 30 Jun 2012, at 10:59, Gerhard Muenz wrote: >>> Andrew, >>>=20 >>> As I pointed out in my previous mail, the window IEs do not seem to = be compatible with the descriptions of existing *TotalCount IEs because = these refer to the time since (re-)initialization. You could use = *DeltaCount, though. >>>=20 >>> Gerhard >>>=20 >>>=20 >>> On 29.06.2012 01:25, Andrew Johnson wrote: >>>> Hi Gerhard >>>>=20 >>>> Thanks for your inputs on this thread. It seems to me that the = idea of "re-initialising" the Metering Process is pretty confusing, in = light of what we're actually doing. I think my mental mode of what is = happening is a bit different from Paul's, so let me start at the = beginning, show how I think of the behaviour, and see what we can come = up with to solve our problem. >>>>=20 >>>> We would like to split the monitored packet streams into discrete = buckets, based on time. >>>>=20 >>>> t0 -----> t1 -----> t2 -----> t3 -----> t4 -----> t5 -----> >>>>=20 >>>>=20 >>>> The packet stream is processed by the Metering Process as usual, = and flows form in the cache in the usual manner. However, observations = from one interval won't be merged with observations from a different = interval. Ideally, at the end of each interval, all flows are exported = and flushed from the cache. >>>>=20 >>>> There are several ways to think about this. One way is to = explicitly flush the cache at the end of each interval (i.e. reset / = reinitialise the Metering Process). The way I see it though, we could = just make an identifier of the current interval a key field and apply = the optimisation of allowing flows from outside the current interval to = be flushed from the cache ASAP, since we know they won't be updated = again. >>>>=20 >>>> Hopefully that gives a bit of a bigger picture. What we are = looking for are two new fields that we can add to the flows, that = identify the beginning at end of the interval they were observed in. In = some circumstances the device may not fully stick to the provided = interval window, so we can't rely on the end of the interval really = being the intervalStart + intervalSize. >>>>=20 >>>> I was thinking of: >>>>=20 >>>> observationWindowStart dateTimeMilliseconds The absolute = timestamp of the beginning of the current Observation Window. >>>> observationWindowEnd dateTimeMilliseconds The absolute = timestamp of the end of the current Observation Window. >>>>=20 >>>>=20 >>>> However, Paul rightly pointed out to me that IPFIX doesn't have any = concept of an Observation Window, and we're not sure how we can define = that in description of the IE. The idea of re-initialising the Metering = Process may fit in with the current IPFIX model, but I don't think it = properly conveys the behaviour we're after. >>>>=20 >>>>=20 >>>> Kind regards, >>>>=20 >>>> Andrew >>>>=20 >>>>=20 >>>> On 25 Jun 2012, at 18:24, Gerhard Muenz wrote: >>>>> Paul, >>>>>=20 >>>>> It depends on what kind of interval you want to specify. >>>>>=20 >>>>> If you want to specify the (re-)initialization time of the = Metering Process, why not name the IE meteringProcessSysUpTime or (if = you do not like sysup) meteringProcessInitializationTime? >>>>> And mention (re-)initialization in the description? >>>>> Dito for exportingProcessInitializationTime etc. >>>>>=20 >>>>> If we need the stop time, you can use meteringProcessStopTime or = so. >>>>>=20 >>>>> If you want to define a new interval which is not starting at = (re-)initialization time but later, then your definitions are ok. But = this means that you need to specify new counter elements for this = interval. >>>>>=20 >>>>> Thanks, >>>>> Gerhard >>>>>=20 >>>>>=20 >>>>> On 25.06.2012 19:08, Paul Aitken wrote: >>>>>> Gerhard, >>>>>>=20 >>>>>>> Ok, I see the difference to discontinuity time. >>>>>>>=20 >>>>>>> Some further thoughts: >>>>>>>=20 >>>>>>> The common understanding is that the "time since = re-initialization" >>>>>>> means sysUpTime. For example, have a look at the description of >>>>>>> flowEndSysUpTime: >>>>>>> "The relative timestamp of the last packet of this Flow. It = indicates >>>>>>> the number of milliseconds since the last (re-)initialization of = the >>>>>>> IPFIX Device (sysUpTime)." >>>>>>=20 >>>>>> Yes, sysUpTime (so specifically, flowStartSysUpTime and >>>>>> flowEndSysUpTime), are times "since the last (re-)initialization = of the >>>>>> IPFIX Device". >>>>>>=20 >>>>>> These are not necessarily related to the metering process. >>>>>>=20 >>>>>> Taking some other examples: octetTotalCount, packetTotalCount, >>>>>> droppedOctetTotalCount, droppedPacketTotalCount, = observedFlowTotalCount, >>>>>> ignoredPacketTotalCount, ignoredOctetTotalCount, >>>>>> postMCastOctetTotalCount, ... are all of the form: >>>>>>=20 >>>>>> "The total number of X since the Metering Process >>>>>> (re-)initialization for this Observation Point." >>>>>>=20 >>>>>> We could suppose that the Metering Process initialised at system = uptime. >>>>>> However, that may not be the case: it could have started any = amount of >>>>>> time later. eg, a user could configure a Metering Process at any = time. >>>>>> Or, an automated system could start and stop Metering Processes >>>>>> according to different times of day or different network = conditions. >>>>>> Without timestamps to tell us, we simply do not know. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Your proposed IEs do not mention neither (re-)initialization nor >>>>>>> sysUpTime. They rather seem to specify a time interval which is >>>>>>> located somewhere within the sysuptime interval. Hence, the = interval >>>>>>> does not work to define the time frame of = exportedMessageTotalCount, >>>>>>> for example. You would need to define a new IE >>>>>>> exportedMessageInMonitoringInterval. >>>>>>=20 >>>>>> Indeed, because the IEs which I'm specifying here are particular = to the >>>>>> Monitoring Process, whereas exportedMessageTotalCount seems to = require a >>>>>> time reference for the Exporting Process. It's a related, though >>>>>> different, issue. >>>>>>=20 >>>>>> (ie, the Exporting Process may start from system init, or at any = time >>>>>> since then. It may have been started before, or after, the = Metering >>>>>> Process. Without a suitable timestamp IE, we simply do not know.) >>>>>>=20 >>>>>>=20 >>>>>>> The different IE descriptions suggest that the time of >>>>>>> re-initialization (i.e. sysuptime) can be different for Metering >>>>>>> Process, Exporting Process etc. >>>>>>=20 >>>>>> Indeed this is so. There is no necessity for these to be the = same. >>>>>>=20 >>>>>>=20 >>>>>>> It seems that we need IE to export sysUpTime for each process. >>>>>>=20 >>>>>> We agree. >>>>>>=20 >>>>>> So in principal, you understand what I'm trying to do. However, = you >>>>>> would like clearer definitions of the Information Elements? >>>>>>=20 >>>>>> Thanks, >>>>>> P. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >=20 >=20 > --=20 > --------------------------------------------------------------------- > 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 trammell@tik.ee.ethz.ch Tue Aug 21 07:55:53 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FDD21F869D for ; Tue, 21 Aug 2012 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4i1zSY7yGGE for ; Tue, 21 Aug 2012 07:55:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0405321F866C for ; Tue, 21 Aug 2012 07:55:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 674EED93A2 for ; Tue, 21 Aug 2012 16:55:51 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aknScZbk3ZfP for ; Tue, 21 Aug 2012 16:55:51 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3AC76D9309 for ; Tue, 21 Aug 2012 16:55:51 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2012 16:55:50 +0200 Message-Id: To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:55:53 -0000 Greetings, all, To close the discussion from Vancouver, we have two proposals under = consideration for handling the transition of enterprise-specific IEs = used for testing, research, or other pre-standardization purposes to = IANA IEs: (1) The addition of an Enterprise-specific Reference column to the IANA = registry, which would include PEN(s) and IE number(s) which have a = description compatible with the IANA-registered IE; this is covered in = the present revision of the IE-DOCTORS draft. The advantage of this is = it provides a central registry; however, it presumes a model in which = CPs are either frequently updated or periodically retrieve new = registration information from IANA, and requires all users of ESIE = codepoints replaced with an IANA codepoint to register that information = with IANA. (2) The definition of an IE equivalence options template, which would = define the equivalence of a set of IANA and enterprise-specific IEs. = This would be sent by EPs which had updated an IE from an older = enterprise-specific codepoint to a new IANA codepoint; this would be = covered in a new draft which Paul Aitken has (I think) already started = work on. This has the advantage that equivalence is not dependent on the = IANA registry. Benoit noted that this required the EP to (i) send = additional information on session startup and (ii) to be updated both to = use the new IANA codepoint as well as to send this additional = information: a CP would not know an old ESIE was equivalent to a newer = IANA IE if the EP it was receiving data from had not been updated. As I see it, there are four possible ways forward: (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a = draft describing approach (2).=20 (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. (c) Support only the Options method: remove approach (1) from = IE-DOCTORS, develop a draft describing approach (2). (d) Defer the question and leave ESIE promotion an open issue: remove = approach (1) from IE-DOCTORS with no present decision on a draft about = approach (2). I suppose I'm in favor of option (a), since each approach has its own = use cases, as long as we're clear in both IE-DOCTORS and the equivalence = options draft about the applicability of each approach. Thoughts? Cheers, Brian= From paitken@cisco.com Tue Aug 21 08:18:50 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D777621F8771 for ; Tue, 21 Aug 2012 08:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJy80rvtqs8w for ; Tue, 21 Aug 2012 08:18:50 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CC5EB21F876F for ; Tue, 21 Aug 2012 08:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3508; q=dns/txt; s=iport; t=1345562330; x=1346771930; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=in2urAkvoESSfNUMQ0/UWyWzToXVeNBAW8r1RsggdAM=; b=mOey3WDDAHEOzR2JCKnQhzPWDekqMDJs5BRIP8H0XkO0J6O/PAzgOcOw RFebtQiKckI4FlZvY/m2g5352elUY+0BqyC+5g9+QcuaiYvDgrdbioAI5 +zLh1WHh0DmI+R2ovohztxVu3yJ2zzNZ4iZmhgPlE+VIROIE4R7R5sbnV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI+lM1CQ/khL/2dsb2JhbABFumKBB4IgAQEBAwESASVAAQULCyEWDwkDAgECAUUGDQEHAQEeh2UGmQ6gQJIkA5VShVyIUYFmgmI X-IronPort-AV: E=Sophos;i="4.77,802,1336348800"; d="scan'208";a="7477891" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 21 Aug 2012 15:18:45 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7LFIjq4015052; Tue, 21 Aug 2012 15:18:45 GMT Message-ID: <5033A6D6.8000903@cisco.com> Date: Tue, 21 Aug 2012 16:18:46 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:18:51 -0000 Brian, > Greetings, all, > > To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs: > > (1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA. NB "compatible description" isn't sufficient. The type, range, semantics, units, all have to be compatible too. > (2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. The draft was written over a year ago, and only needs some polishing before publication. > Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated. So when updating an ESIE to IANA, I either notify IANA for method (1), or I add the mapping to my code for method (2). There's little difference in effort between them. Method (1) has some disadvantages: IANA must store enterprise-specific information, which seems contrary; and CP's must frequently refer to IANA for updates, which may not be possible or desirable in deployed systems. Method (2) ensures that a CP is always up to date for any EP which exports to it. It also has an additional advantage that a mapping can be sent from old-ESIE to new-ESIE, which isn't possible with method (1). > As I see it, there are four possible ways forward: > > (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2). Providing two methods for the same thing is asking for trouble in future. eg, non-interoperable implementations, one using method (1), the other using method (2). Worse, how to handle inconsistencies between the information received by each method? > (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. > > (c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2). > > (d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2). > > I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach. Let me see if I can quickly polish up the draft so people can see what method (2) entails. P. From trammell@tik.ee.ethz.ch Tue Aug 21 08:32:40 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD87E21F84C8 for ; Tue, 21 Aug 2012 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXOnVWD5UJrN for ; Tue, 21 Aug 2012 08:32:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F007821F8564 for ; Tue, 21 Aug 2012 08:32:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4F1C2D9494; Tue, 21 Aug 2012 17:32:39 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7pYdY018PxAl; Tue, 21 Aug 2012 17:32:39 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1BA79D93A2; Tue, 21 Aug 2012 17:32:39 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5033A6D6.8000903@cisco.com> Date: Tue, 21 Aug 2012 17:32:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18792420-2A8E-47CD-9B32-C393BBF2E4DE@tik.ee.ethz.ch> References: <5033A6D6.8000903@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:32:41 -0000 Hi, Paul, thanks for the swift reply! inline per tradition: On Aug 21, 2012, at 5:18 PM, Paul Aitken wrote: > Brian, >=20 >> Greetings, all, >>=20 >> To close the discussion from Vancouver, we have two proposals under = consideration for handling the transition of enterprise-specific IEs = used for testing, research, or other pre-standardization purposes to = IANA IEs: >>=20 >> (1) The addition of an Enterprise-specific Reference column to the = IANA registry, which would include PEN(s) and IE number(s) which have a = description compatible with the IANA-registered IE; this is covered in = the present revision of the IE-DOCTORS draft. The advantage of this is = it provides a central registry; however, it presumes a model in which = CPs are either frequently updated or periodically retrieve new = registration information from IANA, and requires all users of ESIE = codepoints replaced with an IANA codepoint to register that information = with IANA. >=20 > NB "compatible description" isn't sufficient. The type, range, = semantics, units, all have to be compatible too. indeed; I should have used a different word than "description" -- "IEs = which are interoperable by definition"... >> (2) The definition of an IE equivalence options template, which would = define the equivalence of a set of IANA and enterprise-specific IEs. = This would be sent by EPs which had updated an IE from an older = enterprise-specific codepoint to a new IANA codepoint; this would be = covered in a new draft which Paul Aitken has (I think) already started = work on. This has the advantage that equivalence is not dependent on the = IANA registry. >=20 > The draft was written over a year ago, and only needs some polishing = before publication. Excellent. >> Benoit noted that this required the EP to (i) send additional = information on session startup and (ii) to be updated both to use the = new IANA codepoint as well as to send this additional information: a CP = would not know an old ESIE was equivalent to a newer IANA IE if the EP = it was receiving data from had not been updated. >=20 > So when updating an ESIE to IANA, I either notify IANA for method (1), = or I add the mapping to my code for method (2). There's little = difference in effort between them. >=20 > Method (1) has some disadvantages: IANA must store enterprise-specific = information, which seems contrary; and CP's must frequently refer to = IANA for updates, which may not be possible or desirable in deployed = systems. >=20 > Method (2) ensures that a CP is always up to date for any EP which = exports to it. It also has an additional advantage that a mapping can be = sent from old-ESIE to new-ESIE, which isn't possible with method (1). >=20 >=20 >> As I see it, there are four possible ways forward: >>=20 >> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a = draft describing approach (2). >=20 > Providing two methods for the same thing is asking for trouble in = future. eg, non-interoperable implementations, one using method (1), the = other using method (2). Worse, how to handle inconsistencies between the = information received by each method? A good point; however, the worst-case interoperability of a two-method = solution is no worse than that of no solution. Rules for conflict = resolution would be a necessary part of any two-method solution. >> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >>=20 >> (c) Support only the Options method: remove approach (1) from = IE-DOCTORS, develop a draft describing approach (2). >>=20 >> (d) Defer the question and leave ESIE promotion an open issue: remove = approach (1) from IE-DOCTORS with no present decision on a draft about = approach (2). >>=20 >> I suppose I'm in favor of option (a), since each approach has its own = use cases, as long as we're clear in both IE-DOCTORS and the equivalence = options draft about the applicability of each approach. >=20 > Let me see if I can quickly polish up the draft so people can see what = method (2) entails. Please do! Cheers, Brian From trammell@tik.ee.ethz.ch Tue Aug 21 09:50:00 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6521F87D2 for ; Tue, 21 Aug 2012 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuNQXBMTMU3Y for ; Tue, 21 Aug 2012 09:50:00 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4F21F87C6 for ; Tue, 21 Aug 2012 09:50:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 76636D9496 for ; Tue, 21 Aug 2012 18:49:59 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fm9PnJ2B6TiF for ; Tue, 21 Aug 2012 18:49:59 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4D359D93A2 for ; Tue, 21 Aug 2012 18:49:59 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2012 18:49:58 +0200 Message-Id: <0CF66E32-FDBA-4DDA-A3C0-63D3BB1C721B@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] tcpControlBits, ECN, and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:50:00 -0000 Greetings, all, I note that the definition of IE 6, tcpControlBits, uses the RFC793 = definition of the TCP Flags byte, ignoring the changes to the definition = of this field made by RFC3168 (ECN). The "must be zero" language here = has two unfortunate consequences: (1) it obliges MP implementors to mask = the field by 0x3F to zero out bytes that may be set in headers due to = ECN negotiation and (2) it makes it impossible to use compliant = implementations to measure ECN negotiation. I have verified that the at least one shipping implementation of NetFlow = V9 follows the IANA definition; it does indeed mask 0x3F, destroying ECN = negotiation information. Yes, I know "nobody uses ECN" but recent active = measurement efforts have shown increased default support for ECN = negotiation; see e.g. Honda et al. in IMC 2011.=20 I'd considered the right way to address this in view of the proposed = IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would = indeed appear to be eligible for an updated IE on first pass per section = 5.2 (it harmonizes with an updated external reference (3168 updates 793, = though the update happened before the definition of IPFIX); it also = defines a previously reserved bit in an IE with flag semantics). = However, tcpControlBits is in the magic lower 128 V9-compatible space; = new IEs in this space require V9 expert approval, but changes (as yet) = do not. Should this be corrected?=20 Cheers, Brian= From paitken@cisco.com Tue Aug 21 13:01:24 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C2B21F875A for ; Tue, 21 Aug 2012 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS2eHC-cYvlr for ; Tue, 21 Aug 2012 13:01:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E33121F875C for ; Tue, 21 Aug 2012 13:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4282; q=dns/txt; s=iport; t=1345579283; x=1346788883; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TTkolkLNUfQUPpiDD1jyUFtCgOo0/eGdgIHUQvbfBOw=; b=i+tLlYNzJMovmm65CtcSLflyqUAGcPiRIoQmT6HNdl5KLZJV9R0C9VEp A99HqME+HPGDm0OLaUR9Ie10QOvsWn3bhL/NLgmcNpjiThX4L71VWtQkq 5IbAXBUacxab0TGpgkMKO4kjERqOrxVvuag6DN/qxIJBXdmsHKXUOOFKa 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG7oM1CQ/khR/2dsb2JhbABFul6BB4IgAQEBAwESASVAAQULCxgJFg8JAwIBAgFFBg0BBwEBFweHZQaZF6A6iwiHHAOVUoVciFGBZoJi X-IronPort-AV: E=Sophos;i="4.77,804,1336348800"; d="scan'208";a="142693476" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Aug 2012 20:01:22 +0000 Received: from [10.55.83.195] (dhcp-10-55-83-195.cisco.com [10.55.83.195]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7LK1L4u013810; Tue, 21 Aug 2012 20:01:21 GMT Message-ID: <5033E911.9090208@cisco.com> Date: Tue, 21 Aug 2012 21:01:21 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <5033A6D6.8000903@cisco.com> <18792420-2A8E-47CD-9B32-C393BBF2E4DE@tik.ee.ethz.ch> In-Reply-To: <18792420-2A8E-47CD-9B32-C393BBF2E4DE@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 20:01:24 -0000 Brian, Once more inline... > Hi, Paul, > > thanks for the swift reply! inline per tradition: > > On Aug 21, 2012, at 5:18 PM, Paul Aitken wrote: > >> Brian, >> >>> Greetings, all, >>> >>> To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs: >>> >>> (1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA. >> NB "compatible description" isn't sufficient. The type, range, semantics, units, all have to be compatible too. > indeed; I should have used a different word than "description" -- "IEs which are interoperable by definition"... To be picky: eg, are TOS and DSCP interoperable? >>> (2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. >> The draft was written over a year ago, and only needs some polishing before publication. > Excellent. > >>> Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated. >> So when updating an ESIE to IANA, I either notify IANA for method (1), or I add the mapping to my code for method (2). There's little difference in effort between them. >> >> Method (1) has some disadvantages: IANA must store enterprise-specific information, which seems contrary; and CP's must frequently refer to IANA for updates, which may not be possible or desirable in deployed systems. >> >> Method (2) ensures that a CP is always up to date for any EP which exports to it. It also has an additional advantage that a mapping can be sent from old-ESIE to new-ESIE, which isn't possible with method (1). >> >> >>> As I see it, there are four possible ways forward: >>> >>> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2). >> Providing two methods for the same thing is asking for trouble in future. eg, non-interoperable implementations, one using method (1), the other using method (2). Worse, how to handle inconsistencies between the information received by each method? > A good point; however, the worst-case interoperability of a two-method solution is no worse than that of no solution. Disagree. If there was no method, we'd work to create one as soon as the need was established. Whereas with two methods, we don't know who's doing what. > Rules for conflict resolution would be a necessary part of any two-method solution. Yep. >>> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >>> >>> (c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2). >>> >>> (d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2). >>> >>> I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach. >> Let me see if I can quickly polish up the draft so people can see what method (2) entails. > Please do! Ack! P. From paitken@cisco.com Wed Aug 22 04:07:17 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C721F8620 for ; Wed, 22 Aug 2012 04:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYNN3+TV9iIq for ; Wed, 22 Aug 2012 04:07:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95521F861F for ; Wed, 22 Aug 2012 04:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2467; q=dns/txt; s=iport; t=1345633633; x=1346843233; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=psGtsOGJ9LOZt7XofNU4Bo1Z7klEo73kwkd6VnFVKOQ=; b=e77jko7zZiutI3T1qhbO4287AWHlMDNyMCNVI/LbApvN/iTTiqWpd0da 2rG4iRYIWFDiWcDu7CbY7VV2z3BI8Z/icPC/i2xq9XyguhPLQ3IT6i5gt PVIZSDi2S1srIskWhqLSkjXu98H3V80x9VCS0nKRfDeifD8rzx+PV3vsZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAI28NFCQ/khL/2dsb2JhbABFsxSHLIEHgiABAQEEAQEBDwElMwMKARALGAkWDwkDAgECARUwBg0BBQIBAR6HawuZM6BOBIJCj2IDlVKFXIhRgWaCYg X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="76159671" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 22 Aug 2012 11:07:10 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7MB7ABD032234; Wed, 22 Aug 2012 11:07:10 GMT Message-ID: <5034BD5D.5060502@cisco.com> Date: Wed, 22 Aug 2012 12:07:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <0CF66E32-FDBA-4DDA-A3C0-63D3BB1C721B@tik.ee.ethz.ch> In-Reply-To: <0CF66E32-FDBA-4DDA-A3C0-63D3BB1C721B@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] tcpControlBits, ECN, and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:07:17 -0000 Brian, Any IPFIX changes in the < 128 block should also be reflected in NFv9. If the change can't be in NFv9 for some reason, then a new IPFIX IE should be allocated. If this isn't corrected then presumably IANA and the IPFIX expert reviewers would assume sole authority for changes in the < 128 block, which could have the undesirable effect of making IEs in this section incompatible with NFv9. So short answer: yes, this should be corrected. As a NFv9 expert, I'd be happy to see the ECE and CWR bits added to the existing IANA definition - although this means that CP can't know for sure what the 0-valued bits mean: they could be !ECE / !CWR, or they could be old implementations which mask out those bits. Hopefully the latter will disappear over time, so we can come to trust the bits. P. On 21/08/12 17:49, Brian Trammell wrote: > Greetings, all, > > I note that the definition of IE 6, tcpControlBits, uses the RFC793 definition of the TCP Flags byte, ignoring the changes to the definition of this field made by RFC3168 (ECN). The "must be zero" language here has two unfortunate consequences: (1) it obliges MP implementors to mask the field by 0x3F to zero out bytes that may be set in headers due to ECN negotiation and (2) it makes it impossible to use compliant implementations to measure ECN negotiation. > > I have verified that the at least one shipping implementation of NetFlow V9 follows the IANA definition; it does indeed mask 0x3F, destroying ECN negotiation information. Yes, I know "nobody uses ECN" but recent active measurement efforts have shown increased default support for ECN negotiation; see e.g. Honda et al. in IMC 2011. > > I'd considered the right way to address this in view of the proposed IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would indeed appear to be eligible for an updated IE on first pass per section 5.2 (it harmonizes with an updated external reference (3168 updates 793, though the update happened before the definition of IPFIX); it also defines a previously reserved bit in an IE with flag semantics). However, tcpControlBits is in the magic lower 128 V9-compatible space; new IEs in this space require V9 expert approval, but changes (as yet) do not. Should this be corrected? > > Cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Aug 22 04:24:45 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DB021F8620 for ; Wed, 22 Aug 2012 04:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j6dd8SyQDjJ for ; Wed, 22 Aug 2012 04:24:42 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1927C21F862A for ; Wed, 22 Aug 2012 04:24:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 363FCD930A; Wed, 22 Aug 2012 13:24:40 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UGM-iq3R10xE; Wed, 22 Aug 2012 13:24:40 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 08203D9305; Wed, 22 Aug 2012 13:24:40 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5034BD5D.5060502@cisco.com> Date: Wed, 22 Aug 2012 13:24:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39381F8D-290F-4D15-902F-B62148842397@tik.ee.ethz.ch> References: <0CF66E32-FDBA-4DDA-A3C0-63D3BB1C721B@tik.ee.ethz.ch> <5034BD5D.5060502@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] tcpControlBits, ECN, and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:24:45 -0000 Hi, Paul, On Aug 22, 2012, at 1:07 PM, Paul Aitken wrote: > Brian, >=20 > Any IPFIX changes in the < 128 block should also be reflected in NFv9. = If the change can't be in NFv9 for some reason, then a new IPFIX IE = should be allocated. >=20 > If this isn't corrected then presumably IANA and the IPFIX expert = reviewers would assume sole authority for changes in the < 128 block, = which could have the undesirable effect of making IEs in this section = incompatible with NFv9. >=20 > So short answer: yes, this should be corrected. Will do in IE-DOCTORS -03 working copy... > As a NFv9 expert, I'd be happy to see the ECE and CWR bits added to = the existing IANA definition - although this means that CP can't know = for sure what the 0-valued bits mean: they could be !ECE / !CWR, or they = could be old implementations which mask out those bits. Hopefully the = latter will disappear over time, so we can come to trust the bits. An update of the description of this IE would need to mention this = ambiguity, of course. It wouldn't be the only IE requiring some post-collection = interpretation: ipClassOfService for instance also requires some = knowledge of what's happening on the measured network, as it could = really be (ipDiffServCodepoint << 2) | ecn (which would have unfortunate = consequences on older ECN-naive MPs treating ipClassOfService as a key = field). Cheers, Brian > P. >=20 >=20 > On 21/08/12 17:49, Brian Trammell wrote: >> Greetings, all, >>=20 >> I note that the definition of IE 6, tcpControlBits, uses the RFC793 = definition of the TCP Flags byte, ignoring the changes to the definition = of this field made by RFC3168 (ECN). The "must be zero" language here = has two unfortunate consequences: (1) it obliges MP implementors to mask = the field by 0x3F to zero out bytes that may be set in headers due to = ECN negotiation and (2) it makes it impossible to use compliant = implementations to measure ECN negotiation. >>=20 >> I have verified that the at least one shipping implementation of = NetFlow V9 follows the IANA definition; it does indeed mask 0x3F, = destroying ECN negotiation information. Yes, I know "nobody uses ECN" = but recent active measurement efforts have shown increased default = support for ECN negotiation; see e.g. Honda et al. in IMC 2011. >>=20 >> I'd considered the right way to address this in view of the proposed = IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would = indeed appear to be eligible for an updated IE on first pass per section = 5.2 (it harmonizes with an updated external reference (3168 updates 793, = though the update happened before the definition of IPFIX); it also = defines a previously reserved bit in an IE with flag semantics). = However, tcpControlBits is in the magic lower 128 V9-compatible space; = new IEs in this space require V9 expert approval, but changes (as yet) = do not. Should this be corrected? >>=20 >> Cheers, >>=20 >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Aug 22 04:37:20 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9821F8665 for ; Wed, 22 Aug 2012 04:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyhUHE4LY3AZ for ; Wed, 22 Aug 2012 04:37:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2457821F869F for ; Wed, 22 Aug 2012 04:37:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BF12CD9305 for ; Wed, 22 Aug 2012 13:37:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bPaavpSzXaNX for ; Wed, 22 Aug 2012 13:37:14 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8D9F9D9300 for ; Wed, 22 Aug 2012 13:37:14 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Aug 2012 13:37:13 +0200 Message-Id: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] obsoleting obsoletion in 5102-bis and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:37:20 -0000 Greetings, all, Following the discussion in Vancouver, I propose to modify RFC5102-bis = and the IE-DOCTORS draft to remove the 'obsolete' status; the arguments = presented there that two different ways to say "this IE is dead" don't = really reflect operational realities seem to me to be pretty convincing. Any objections? Cheers, Brian= From paitken@cisco.com Wed Aug 22 05:54:33 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90F21F8617 for ; Wed, 22 Aug 2012 05:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHnJqYf-olFb for ; Wed, 22 Aug 2012 05:54:29 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4821F852C for ; Wed, 22 Aug 2012 05:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1512; q=dns/txt; s=iport; t=1345640069; x=1346849669; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hExOSklY+1XZ+uQ36DpFqvh+peB/r4d8w8sd7fm24aI=; b=dlkv+wCFiydFjC3UceqTzIZ9w88NFclPIb61RKa2HQtSFmFxT9lgS+Gx hJAm6Bw6slHuu/SJuxQE4BewaQmQBIVJZz/GwVb8AxnRDnESSvuo2lYeK Op7fn2eJiO+17FEvneVENbA1636BlcKqpMedmZZ3ufvMSlLBAYSbZYWU2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIGACfWNFCQ/khM/2dsb2JhbABFsxWHLIEHgiABAQEEAQEBDwElNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBHodrC5kQoEsEkiQDlVKFXIhRgWaCYg X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="7505068" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 22 Aug 2012 12:54:27 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7MCsR3C017598; Wed, 22 Aug 2012 12:54:27 GMT Message-ID: <5034D682.4030409@cisco.com> Date: Wed, 22 Aug 2012 13:54:26 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> In-Reply-To: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] obsoleting obsoletion in 5102-bis and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:54:33 -0000 Brian, No objection. Consider VRRP: although VRRP v2 (RFC 3768) was obsoleted by VRRP v3 (RFC 5798), v2 is still in common use. We should expect the same for IPFIX IEs: obsolete IEs may continue in use for many years because people are unaware, unable, or simply unwilling to update. Can IANA record the obsolescence date individually for each field? Reviewing draft-ietf-ipfix-ie-doctors-03, The use of deprecated Information Elements SHOULD result in a log entry or human-readable warning at the Exporting and Collecting Processes. That's just not possible. How can an existing EP know that its IEs have been deprecated? - Unless it's able to reference IANA, and method (1) of yesterday's discussion is in use. However, that's not desirable since it allows a third party (whoever causes the IANA deprecation) to cause warnings to appear in your tried and tested and perfectly good EP - CP setup. Thanks, P. On 22/08/12 12:37, Brian Trammell wrote: > Greetings, all, > > Following the discussion in Vancouver, I propose to modify RFC5102-bis and the IE-DOCTORS draft to remove the 'obsolete' status; the arguments presented there that two different ways to say "this IE is dead" don't really reflect operational realities seem to me to be pretty convincing. > > Any objections? > > Cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Aug 22 06:14:22 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BA521F8598 for ; Wed, 22 Aug 2012 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew8palu0euGr for ; Wed, 22 Aug 2012 06:14:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4085C21F859C for ; Wed, 22 Aug 2012 06:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 022E2D930D; Wed, 22 Aug 2012 15:14:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DuV98qgnZI8d; Wed, 22 Aug 2012 15:14:15 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B5D84D9305; Wed, 22 Aug 2012 15:14:15 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5034D682.4030409@cisco.com> Date: Wed, 22 Aug 2012 15:14:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCD4A54-CA4C-48EE-A9BD-6AC7C8E8BC93@tik.ee.ethz.ch> References: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> <5034D682.4030409@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] obsoleting obsoletion in 5102-bis and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 13:14:22 -0000 On Aug 22, 2012, at 2:54 PM, Paul Aitken wrote: > Brian, >=20 > No objection. >=20 > Consider VRRP: although VRRP v2 (RFC 3768) was obsoleted by VRRP v3 = (RFC 5798), v2 is still in common use. >=20 > We should expect the same for IPFIX IEs: obsolete IEs may continue in = use for many years because people are unaware, unable, or simply = unwilling to update. >=20 > Can IANA record the obsolescence date individually for each field? Yep. =46rom IE-DOCTORS (current -04 working copy): The revision number of an Information Element is incremented upon = deprecation, and the revision date updated. > Reviewing draft-ietf-ipfix-ie-doctors-03, >=20 > The use of deprecated Information Elements SHOULD result > in a log entry or human-readable warning at the Exporting and > Collecting Processes. >=20 >=20 > That's just not possible. How can an existing EP know that its IEs = have been deprecated? - Unless it's able to reference IANA, and method = (1) of yesterday's discussion is in use. An EP using a deprecated IE sending to a CP using a deprecated IE has in = essence no problem -- sure, they're deprecated, but they're = interoperating ("living in the past") one could say. As soon as _one_ of them is updated, though, then one of them SHOULD log = (within reason - once per IE per runtime should suffice, but this is an = implementation detail).=20 How about "the use of IEs known by a CP or an EP to be deprecated"...? > However, that's not desirable since it allows a third party (whoever = causes the IANA deprecation) to cause warnings to appear in your tried = and tested and perfectly good EP - CP setup. Which is the last remaining question on IE-DOCTORS, and the short = version of the other thread: to remove ESIE Reference from IE-DOCTORS or = not? Cheers, Brian > On 22/08/12 12:37, Brian Trammell wrote: >> Greetings, all, >>=20 >> Following the discussion in Vancouver, I propose to modify = RFC5102-bis and the IE-DOCTORS draft to remove the 'obsolete' status; = the arguments presented there that two different ways to say "this IE is = dead" don't really reflect operational realities seem to me to be pretty = convincing. >>=20 >> Any objections? >>=20 >> Cheers, >>=20 >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Aug 22 06:27:21 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C270A21F853B for ; Wed, 22 Aug 2012 06:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os6PEgw8q8GQ for ; Wed, 22 Aug 2012 06:27:17 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 779C421F853E for ; Wed, 22 Aug 2012 06:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2096; q=dns/txt; s=iport; t=1345642037; x=1346851637; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1VfpcPSNiXcl4AevDuSp/OC9IPGR3ASp1wlUsop9Aek=; b=SRJeRlqGAGe3pk8qKvJamotYFoC62goLMYEwrYIWzDmp9EyrcLjIDujh mZ6b9Kza4TqnVu/PkkVy6JuCzaOnQkvfaKorHl7K6uV6CWEgbVnTJPOah 9I6EoBS1FVtoXVjZRDzjRwW8XaPX2Fb4Ypg0yivPKeGpDmXEHyQ/RZadf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8GANPdNFCQ/khR/2dsb2JhbABFsxWHM4EHgiABAQEDARIBJUABBQsLGAkWDwkDAgECAUUGDQEHAQEQDodlBpkYoE6LCIccA5VShVyIUYFmgmQ X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="76163334" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 22 Aug 2012 13:27:06 +0000 Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7MDR6si020360; Wed, 22 Aug 2012 13:27:06 GMT Message-ID: <5034DE29.1060906@cisco.com> Date: Wed, 22 Aug 2012 14:27:05 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> <5034D682.4030409@cisco.com> <5DCD4A54-CA4C-48EE-A9BD-6AC7C8E8BC93@tik.ee.ethz.ch> In-Reply-To: <5DCD4A54-CA4C-48EE-A9BD-6AC7C8E8BC93@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] obsoleting obsoletion in 5102-bis and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 13:27:21 -0000 Brian, > On Aug 22, 2012, at 2:54 PM, Paul Aitken wrote: > >> Brian, >> >> No objection. >> >> Consider VRRP: although VRRP v2 (RFC 3768) was obsoleted by VRRP v3 (RFC 5798), v2 is still in common use. >> >> We should expect the same for IPFIX IEs: obsolete IEs may continue in use for many years because people are unaware, unable, or simply unwilling to update. >> >> Can IANA record the obsolescence date individually for each field? > Yep. From IE-DOCTORS (current -04 working copy): > > The revision number of an Information Element is incremented upon deprecation, and the revision date updated. Which revision date is that? The overall revision date of the registry? >> Reviewing draft-ietf-ipfix-ie-doctors-03, >> >> The use of deprecated Information Elements SHOULD result >> in a log entry or human-readable warning at the Exporting and >> Collecting Processes. >> >> >> That's just not possible. How can an existing EP know that its IEs have been deprecated? - Unless it's able to reference IANA, and method (1) of yesterday's discussion is in use. > An EP using a deprecated IE sending to a CP using a deprecated IE has in essence no problem -- sure, they're deprecated, but they're interoperating ("living in the past") one could say. > > As soon as _one_ of them is updated, though, then one of them SHOULD log (within reason - once per IE per runtime should suffice, but this is an implementation detail). > > How about "the use of IEs known by a CP or an EP to be deprecated"...? That would work. Note that if the EP is to do this, then it knows that it's using a deprecated IE, so it's part-way to answering Benoit's note/objection. >> However, that's not desirable since it allows a third party (whoever causes the IANA deprecation) to cause warnings to appear in your tried and tested and perfectly good EP - CP setup. > Which is the last remaining question on IE-DOCTORS, and the short version of the other thread: to remove ESIE Reference from IE-DOCTORS or not? We need wider community input on this one. P. From trammell@tik.ee.ethz.ch Wed Aug 22 07:27:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B064E21F8607 for ; Wed, 22 Aug 2012 07:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSEMMf8J2n0w for ; Wed, 22 Aug 2012 07:27:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEDF21F8606 for ; Wed, 22 Aug 2012 07:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F2794D9309; Wed, 22 Aug 2012 16:27:04 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XfmbmFFOK957; Wed, 22 Aug 2012 16:27:04 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A4874D9305; Wed, 22 Aug 2012 16:27:04 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5034DE29.1060906@cisco.com> Date: Wed, 22 Aug 2012 16:27:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7132C02F-C26A-4925-A805-D1BFD24AE8D8@tik.ee.ethz.ch> References: <6B5CC734-09AA-4232-89C4-4D5DA5A9BC6C@tik.ee.ethz.ch> <5034D682.4030409@cisco.com> <5DCD4A54-CA4C-48EE-A9BD-6AC7C8E8BC93@tik.ee.ethz.ch> <5034DE29.1060906@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] obsoleting obsoletion in 5102-bis and IE-DOCTORS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:27:06 -0000 On Aug 22, 2012, at 3:27 PM, Paul Aitken wrote: > Brian, >=20 >> On Aug 22, 2012, at 2:54 PM, Paul Aitken wrote: >>=20 >>> Brian, >>>=20 >>> No objection. >>>=20 >>> Consider VRRP: although VRRP v2 (RFC 3768) was obsoleted by VRRP v3 = (RFC 5798), v2 is still in common use. >>>=20 >>> We should expect the same for IPFIX IEs: obsolete IEs may continue = in use for many years because people are unaware, unable, or simply = unwilling to update. >>>=20 >>> Can IANA record the obsolescence date individually for each field? >> Yep. =46rom IE-DOCTORS (current -04 working copy): >>=20 >> The revision number of an Information Element is incremented upon = deprecation, and the revision date updated. >=20 > Which revision date is that? The overall revision date of the = registry? The revision date of the IE, will clarify. >>> Reviewing draft-ietf-ipfix-ie-doctors-03, >>>=20 >>> The use of deprecated Information Elements SHOULD result >>> in a log entry or human-readable warning at the Exporting and >>> Collecting Processes. >>>=20 >>>=20 >>> That's just not possible. How can an existing EP know that its IEs = have been deprecated? - Unless it's able to reference IANA, and method = (1) of yesterday's discussion is in use. >> An EP using a deprecated IE sending to a CP using a deprecated IE has = in essence no problem -- sure, they're deprecated, but they're = interoperating ("living in the past") one could say. >>=20 >> As soon as _one_ of them is updated, though, then one of them SHOULD = log (within reason - once per IE per runtime should suffice, but this is = an implementation detail). >>=20 >> How about "the use of IEs known by a CP or an EP to be = deprecated"...? >=20 > That would work. >=20 > Note that if the EP is to do this, then it knows that it's using a = deprecated IE, so it's part-way to answering Benoit's note/objection. The only case it doesn't cover is old EP (still using a = pre-standardization ESIE, and therefore not exporting equivalence) = exporting to a new CP (using IANA, and doesn't know anything about the = ESIE). >>> However, that's not desirable since it allows a third party (whoever = causes the IANA deprecation) to cause warnings to appear in your tried = and tested and perfectly good EP - CP setup. >> Which is the last remaining question on IE-DOCTORS, and the short = version of the other thread: to remove ESIE Reference from IE-DOCTORS or = not? >=20 > We need wider community input on this one. Indeed. Cheers, Brian From trammell@tik.ee.ethz.ch Wed Aug 22 07:45:22 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122821F855E for ; Wed, 22 Aug 2012 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgtjelK9LG-z for ; Wed, 22 Aug 2012 07:45:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC721F853D for ; Wed, 22 Aug 2012 07:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2787CD9305; Wed, 22 Aug 2012 16:45:13 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1gkQIkBC9HJ0; Wed, 22 Aug 2012 16:45:12 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D393FD9304; Wed, 22 Aug 2012 16:45:12 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <500039DE.5050706@cisco.com> Date: Wed, 22 Aug 2012 16:45:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> References: <500039DE.5050706@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:45:22 -0000 Hi, Paul, Thanks for the review! Coming back to this now that IE-DOCTORS is = waiting on resolution... Deleted comments have been fixed in the = document without discussion; other comments inline. I've incorporated edits into a -06 revision, to be submitted shortly. On Jul 13, 2012, at 5:08 PM, Paul Aitken wrote: > Dear Authors, >=20 > Here with an extensive and detailed review of draft-ietf-ipfix-a9n-04. >=20 > P. >=20 >>=20 >> 2. Terminology >>=20 >> Terms used in this document that are defined in the Terminology >> section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] >> document are to be interpreted as defined there. >>=20 >> 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]. >>=20 >> In addition, this document defines the following terms >>=20 >> Aggregated Flow: A Flow, as defined by >> [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of = zero >> or more original Flows within a defined Aggregation Interval. = The >>=20 >=20 > Zero things can't be aggregated. You can only say, "none were seen". This is equivalent to what's written in the terminology, no? Export of = an aggregation of an empty set is the same thing as an assertion that = nothing was observed corresponding to the given key in the reported = interval. >> primary difference between a Flow and an Aggregated Flow in the >> general case is that the time interval (i.e., the two-tuple of >> start and end times) of a Flow is derived from information = about >> the timing of the packets comprising the Flow, while the time >> interval of an Aggregated Flow is often externally imposed. = Note >> that an Aggregated Flow is defined in the context of an >> Intermediate Aggregation Process only. Once an Aggregated Flow = is >> exported, it is essentially a Flow as in >> [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as = such. =20 >> Original Exporter: When the Intermediate Aggregation Process is >> hosted in an IPFIX Mediator, the Original Exporter is the = Exporter >> from which the Original Flows are received. >>=20 >=20 > Does the meaning of "Original Exporter" change when the Intermediate = Aggregation Process is _not_ hosted in an IPFIX Mediator? No, it simply has no meaning. >> 3. Use Cases for IPFIX Aggregation >>=20 >> While much of the discussion in this document, and all of the >> examples, apply to the common case that the Original Flows to be >> aggregated are all of the same underlying type (i.e., are = represented >> with identical or compatible Templates), and that each packet >>=20 >=20 > What are "compatible" Templates ? Templates which represent the same essential complex data type (6313 = notwithstanding); templates containing substantially the same IEs, with = allowances for free convertibility of timestamps and information which = is multiply representable (e.g. TOS and DSCP, 5103 biflows and = initiator*/responder*, etc.) and the dropping of IEs in which the IAP is = not interested or cannot decode. I'll describe this more succinctly in the document. > How does this work when there are zero things to be aggregated? ie, = are zero things all of the same type? I'd presume you generally only have zero things in the context of some = complex type -- i.e., you know what the template would be of the records = you didn't see, because you got it from the OE. The degenerate case of = you receive nothing at all, not even a template, would be handled by not = exporting anything and maybe reminding whoever's responsible for the = whole infrastructure that they should turn stuff on with a helpful note = in the log. Otherwise, I suppose this is an interesting philosophical question ("if = a flow doesn't pass through a router in the woods, does anyone hear = it?"), but I don't get the point... >> 5. IP Flow Aggregation Operations >>=20 >> As stated in Section 2, an Aggregated Flow is simply an IPFIX Flow >> generated from Original Flows by an Intermediate Aggregation = Process. >> Here, we detail the operations by which this is achieved within an >> Intermediate Aggregation Process. >>=20 >> 5.1. Temporal Aggregation through Interval Distribution >>=20 >> Interval distribution imposes a time interval on the resulting >> Aggregated Flows. The selection of an interval is specific to the >> given aggregation application. Intervals may be derived from the >> Original Flows themselves (e.g., an interval may be selected to = cover >> the entire time containing the set of all Flows sharing a given = Key, >> as in Time Composition described in Section 5.1.2) or externally >> imposed; in the latter case the externally imposed interval may be >> regular (e.g., every five minutes) or irregular (e.g., to allow = for >> different time resolutions at different times of day, under = different >> network conditions, or indeed for different sets of Original = Flows). >>=20 >> The length of the imposed interval itself has tradeoffs. Shorter >> intervals allow higher-resolution aggregated data and, in = streaming >>=20 >>=20 >>=20 >> Trammell, et al. Expires December 29, 2012 [Page = 15] >> Internet-Draft IPFIX Aggregation June = 2012 >>=20 >>=20 >> applications, faster reaction time. Longer intervals generally = lead >> to greater data reduction and simplified counter distribution. >> Specifically, counter distribution is greatly simplified by the >> choice of an interval longer than the duration of longest Original >> Flow, itself generally determined by the Original Flow's Metering >> Process active timeout; in this case an Original Flow can = contribute >> to at most two Aggregated Flows, and the more complex value >> distribution methods become inapplicable. >>=20 >> | | | | >> | |<--Flow A-->| | | | >> | |<--Flow B-->| | | >> | |<-------------Flow C-------------->| | >> | | | | >> | interval 0 | interval 1 | interval 2 | >>=20 >> Figure 5: Illustration of interval distribution >>=20 >> In Figure 5, we illustrate three common possibilities for interval >> distribution as applies with regular intervals to a set of three >> Original Flows. For Flow A, the start and end times lie within = the >> boundaries of a single interval 0; therefore, Flow A contributes = to >> only one Aggregated Flow. Flow B, by contrast, has the same = duration >> but crosses the boundary between intervals 0 and 1; therefore, it >> will contribute to two Aggregated Flows, and its counters must be >> distributed among these Flows, though in the two-interval case = this >> can be simplified somewhat simply by picking one of the two >> intervals, or proportionally distributing between them. Only = Flows >> like Flow A and Flow B will be produced when the interval is = chosen >> to be longer than the duration of longest Original Flow, as above. >> More complicated is the case of Flow C, which contributes to more >> than two Aggregated Flows, and must have its counters distributed >> according to some policy as in Section 5.1.1. >>=20 >=20 > This discussion applies equally to many other fields. eg, Figure 5 = could show source ports, with the "intervals" grouping well-known ports = and ephemeral ports. Flow A uses only a few source ports whereas Flow C = uses many. Hm, not really; this is that in reverse. It's like saying that original = Flow had N source ports, and we're going to split that into N Partially = Aggregated Flows, one with each of the original ports.=20 >>=20 >> 5.1.1. Distributing Values Across Intervals >>=20 >> End Interval: The counters for an Original Flow are added to the >> counters of the appropriate Aggregated Flow containing the end >> time of the Original Flow. >>=20 >> Start Interval: The counters for an Original Flow are added to = the >> counters of the appropriate Aggregated Flow containing the = start >> time of the Original Flow. >>=20 >> Mid Interval: The counters for an Original Flow are added to the >> counters of a single appropriate Aggregated Flow containing = some >> timestamp between start and end time of the Original Flow. >>=20 >> Simple Uniform Distribution: Each counter for an Original Flow = is >> divided by the number of time intervals the Original Flow = covers >> (i.e., of appropriate Aggregated Flows sharing the same Flow >> Keys), and this number is added to each corresponding counter = in >> each Aggregated Flow. >>=20 >> Proportional Uniform Distribution: This is like simple uniform >> distribution, but accounts for the fractional portions of a = time >> interval covered by an Original Flow in the first and last time >> interval. Each counter for an Original Flow is divided by the >> number of time _units_ the Original Flow covers, to derive a = mean >> count rate. This rate is then multiplied by the number of time >> units in the intersection of the duration of the Original Flow = and >> the time interval of each Aggregated Flow. >>=20 >> Simulated Process: Each counter of the Original Flow is = distributed >> among the intervals of the Aggregated Flows according to some >> function the Aggregation Process uses based upon properties of >> Flows presumed to be like the Original Flow. For example, Flow >> Records representing bulk transfer might follow a more or less >> proportional uniform distribution, while interactive processes = are >> far more bursty. >>=20 >=20 > BTW, the case of a collector or mediator aggregating received flows = presents another possibility: the flow could be received late (eg, = delayed export), so rather than re-opening an old start / mid / end = aggregation, the flow is simply included in the "current" aggregation. = ie, real time aggregation, regardless of the flow timestamps. A good point; however, this is already covered in section 6.2:=20 In certain circumstances, additional delay at the original Exporter may cause an IAP to close an interval before the last Original Flow(s) accountable to the interval arrives; in this case the IAP SHOULD drop the late Original Flow(s). Accounting of flows lost at an Intermediate Process due to such issues is covered in [I-D.ietf-ipfix-mediation-protocol]. Would you suggest loosening the language to allow an IAP to fake = timestamps to avoid drops in delay-intolerant situations? >> Trammell, et al. Expires December 29, 2012 [Page = 17] >> Internet-Draft IPFIX Aggregation June = 2012 >>=20 >>=20 >> Direct: The Aggregation Process has access to the original = packet >> timings from the packets making up the Original Flow, and uses >> these to distribute or recalculate the counters. >>=20 >> A method for exporting the distribution of counters across = multiple >> Aggregated Flows is detailed in Section 7.4. In any case, = counters >> MUST be distributed across the multiple Aggregated Flows in such a >> way that the total count is preserved, within the limits of = accuracy >> of the implementation. This property allows data to be aggregated >> and re-aggregated with negligible loss of original count = information. >> To avoid confusion in interpretation of the aggregated data, all = the >> counters for a set of given Original Flows SHOULD be distributed = via >> the same method. >>=20 >=20 > Consider changing that to a "MUST". >=20 > As long as the method is consistent, is it necessary to know what = method was used? Depending on what you intend to do with the data, it can be helpful to = know if everything's in one bin or if there was some distribution across = bins; however, exactly how it was done may not be so important. This = list is meant only to be a covering set of possible distribution = policies (given the assumption that you're not simply faking timestamps, = as above)... >>=20 >> 5.4. Aggregation Combination >>=20 >> Interval distribution and key aggregation together may generate >> multiple Partially Aggregated Flows covering the same time = interval >> with the same set of Flow Key values. The process of combining = these >> Partially Aggregated Flows into a single Aggregated Flow is called >> aggregation combination. In general, non-Key values from multiple >> Contributing Flows are combined using the same operation by which >> values are combined from packets to form Flows for each = Information >> Element. Counters are summed, averages are averaged, flags are >> unioned, and so on. >>=20 >=20 > Disagree. Delta counters can be summed; total counters need the latest = (newest) value. For aggregating across multiple contributing flows, you take the latest = total counter from each, then sum them. > However, averages cannot be averaged. Yeah, that's just a silly mistake; removed. >> 7.2. Flow Count Export >>=20 >> The following four Information Elements are defined to count = Original >> Flows as discussed in Section 5.2.1. >>=20 >> 7.2.1. originalFlowsPresent >>=20 >> Description: The non-conservative count of Original Flows >> contributing to this Aggregated Flow. Non-conservative counts >> need not sum to the original count on re-aggregation. >>=20 >> Abstract Data Type: unsigned64 >>=20 >=20 > Sematics? Either totalCount or deltaCount. Same for the fields below = too. deltaCount for these, total for the distinct counters thanks for = catching this... >> =20 >>=20 >>=20 >> ElementId: TBD1 >>=20 >> Status: Current >>=20 >=20 > I'm sure it's not necessary to say "Status: Current", since it's very = unlikely that we'd be introducing new but deprecated fields. >=20 > What does IE police have to say on this matter? It's not in the IE-DOCTORS template; this is copied from an (older) = document without a specified template (I think anon), wherein Status: = was a field. >>=20 >> 7.2.2. originalFlowsInitiated >>=20 >> Description: The conservative count of Original Flows whose = first >> packet is represented within this Aggregated Flow. = Conservative >> counts must sum to the original count on re-aggregation. >>=20 >> Abstract Data Type: unsigned64 >>=20 >> ElementId: TBD2 >>=20 >> Status: Current >>=20 >> 7.2.3. originalFlowsCompleted >>=20 >> Description: The conservative count of Original Flows whose last >> packet is represented within this Aggregated Flow. = Conservative >> counts must sum to the original count on re-aggregation. >>=20 >> Abstract Data Type: unsigned64 >>=20 >> ElementId: TBD3 >>=20 >> Status: Current >>=20 >> 7.2.4. deltaFlowCount >>=20 >> Description: The conservative count of Original Flows = contributing >> to this Aggregated Flow; may be distributed via any of the = methods >> described in Section 5.1.1. This Information Element is >> compatible with Information Element 3 as used in NetFlow = version >> 9. >>=20 >=20 > This is not a good description for inclusion in the IANA registry = (which currently doesn't define element 3): >=20 > - "may be distributed via any of the methods described in Section = 5.1.1." only makes sense within the context of this document. > - "This Information Element is compatible with Information Element 3 = as used in NetFlow version 9." is suitable as a Note, but not as part of = the description. Good points both. Will fix. >=20 >> =20 >>=20 >>=20 >>=20 >>=20 >> Trammell, et al. Expires December 29, 2012 [Page = 26] >> Internet-Draft IPFIX Aggregation June = 2012 >>=20 >>=20 >> Abstract Data Type: unsigned64 >>=20 >> ElementId: 3 >>=20 >> Status: Current >>=20 >> 7.3. Distinct Host Export >>=20 > It's a pity that six new IEs were required here, rather than a single = "countOf" field + property. eg, "countOf" + "SourceIPv6Address". See my messages of 9 July = http://www.ietf.org/mail-archive/web/ipfix/current/msg06436.html and 9 = April http://www.ietf.org/mail-archive/web/ipfix/current/msg06347.html = which modify mibvar to be the first half of a general solution to this = problem. I suspect at this rate you can expect a message from me on 9 = October on the subject, as well. :) >> 7.4.2. valueDistributionMethod Information Element >>=20 >> Description: A description of the method used to distribute the >> counters from Contributing Flows into the Aggregated Flow = records >> described by an associated scope, generally a Template. The >> method is deemed to apply to all the non-key Information = Elements >> in the referenced scope for which value distribution is a valid >> operation; if the originalFlowsInitiated and/or >> originalFlowsCompleted Information Elements appear in the >> Template, they are not subject to this distribution method, as >> they each infer their own distribution method. This is = intended >> to be a complete set of possible value distribution methods; it = is >>=20 >=20 > Do you mean to say it's a non-extensible? It's an explanation of why there's not a definition of an IANA = sub-registry here. >> 8. Examples (many, many thanks for going over these again; I know how tedious they = are...) >> In these examples, the same data, described by the same template, >> will be aggregated multiple different ways; this illustrates the >> various different functions which could be implemented by >> Intermediate Aggregation Processes. Templates are shown in IESpec >> format as introduced in [I-D.ietf-ipfix-ie-doctors]. The source = data >> format is a simplified flow: timestamps, traditional 5-tuple, and >> octet count. The template is shown in Figure 8. >>=20 >> flowStartMilliseconds(152)[8] >> flowEndMilliseconds(153)[8] >> sourceIPv4Address(8)[4] >> destinationIPv4Address(12)[4] >> sourceTransportPort(7)[2] >> destinationTransportPort(11)[2] >> protocolIdentifier(4)[1] >> octetDeltaCount(1)[8] >>=20 >> Figure 8: Input template for examples >>=20 >=20 > This isn't really a figure. It's not really a table either. Additionally, XML2RFC is not apparently = capable of labelling things tables unless they appear in the texttable, = and texttables are too limited to handle all the various things I need = to do in the examples area. I'm inclined to leave this as it is (umpteen repetitions below omitted) = as I don't see a good solution that doesn't involve custom tooling. >> dest ip4 port dist src >> 192.0.2.131 53 3 >> 198.51.100.2 80 1 >> 198.51.100.2 443 3 >> 198.51.100.67 80 2 >> 198.51.100.68 80 2 >> 198.51.100.133 80 2 >> 198.51.100.3 80 3 >> 198.51.100.4 80 2 >> 198.51.100.17 80 1 >> 198.51.100.69 443 1 >>=20 >=20 > This table seems to be completely wrong. Even the total counts is = wrong - ie, add up the "dist src" =3D 20. Yet Figure 9 has 24 entries. These are *distinct* sources per destination endpoint. For 192.0.2.131:53, there are 5 flows, but the sources are 192.0.2.2, = 192.0.2.3, 192.0.2.131. > I think it should be: >=20 > 198.51.100.17 80 4 > 198.51.100.2 80 1 > 198.51.100.2 443 4 > 198.51.100.3 80 3 > 198.51.100.4 80 2 > 198.51.100.68 80 4 > 198.51.100.69 443 1 I don't get where this comes from at all.=20 >>=20 >> Following metadata export, the aggregation steps follow as before. >> However, two long flows are distributed across multiple intervals = in >> the interval imposition step, as indicated with "*" in Figure 27. >>=20 >=20 > It might help to use *1 and *2 to distinguish the two flows. Would do so but I'm at the nits width limit with this figure/table. >> Benoit Claise >> Cisco Systems, Inc. >> De Kleetlaan 6a b1 >> 1831 Diagem >>=20 >=20 > Once again, in existing RFCs - and in Cisco's internal directory - = this is "Diegem 1831". Per the Universal Postal Union, the most authoritative reference source = I could find in English with a couple of minutes of googling, the proper = format for addressing in Belgium places the postcode before the = municipality name. See: = http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/belE= n.pdf >> Belgium Cheers, Brian From internet-drafts@ietf.org Wed Aug 22 07:46:46 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5221F861A; Wed, 22 Aug 2012 07:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td5Ujx3bfunO; Wed, 22 Aug 2012 07:46:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06F721F8607; Wed, 22 Aug 2012 07:46:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120822144641.4005.29284.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2012 07:46:41 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:46:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Flow Aggregation for the IP Flow Information Export (IPF= IX) Protocol Author(s) : Brian Trammell Arno Wagner Benoit Claise Filename : draft-ietf-ipfix-a9n-06.txt Pages : 57 Date : 2012-08-22 Abstract: This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-a9n-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-a9n-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n.brownlee@auckland.ac.nz Wed Aug 22 20:23:12 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F09A21F8503 for ; Wed, 22 Aug 2012 20:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-ZodmAXIhZn for ; Wed, 22 Aug 2012 20:23:11 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7B21F84FC for ; Wed, 22 Aug 2012 20:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1345692191; x=1377228191; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6dJS6kvQxIJ2Olr4Oz1LkgvrAxrm5lcvTnYNgzCXn9A=; b=DJhCk5wK/e4vqCJc51KYzF/EJ9qL0pqsZqC+O/AXfyexW77U4BCaMV0m p6XGRsLmv8Z/oamI8zpbkDgWeAI9QwzHOuzzD0LdMXpdvoT5E93BDQJKS xHn1WauNO9yvVavaogSQp1FSQqejrEPGEZ2PNSHmTxisyxGeeWNbk/17e w=; X-IronPort-AV: E=Sophos;i="4.77,813,1336305600"; d="scan'208";a="140984639" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 23 Aug 2012 15:23:09 +1200 Message-ID: <5035A21C.7070703@auckland.ac.nz> Date: Thu, 23 Aug 2012 15:23:08 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX Working Group References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Fwd: [Pam-sc] PAM 2013 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 03:23:12 -0000 Hi all: Next year's Passive and Active Measurements conference will be held in Hong Kong. Information about it - including its CFP - is at http://pam2013.comp.polyu.edu.hk/ . Cheers, Nevil _______________________________________________ Pam-sc mailing list Pam-sc@cs.bu.edu http://cs-mailman.bu.edu/mailman/listinfo/pam-sc From trammell@tik.ee.ethz.ch Fri Aug 31 03:14:03 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0EB21F8578 for ; Fri, 31 Aug 2012 03:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.19 X-Spam-Level: X-Spam-Status: No, score=-5.19 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3ioJkTGMHDk for ; Fri, 31 Aug 2012 03:14:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9786821F8570 for ; Fri, 31 Aug 2012 03:14:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7AE0AD9309 for ; Fri, 31 Aug 2012 12:14:00 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XBWprZIav6o8 for ; Fri, 31 Aug 2012 12:14:00 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E0B71D9308 for ; Fri, 31 Aug 2012 12:13:59 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Aug 2012 12:13:59 +0200 Message-Id: <80EAF962-5034-493D-B1C2-02E4FA5CB640@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] On promotion of enterprise-specific Information Elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:14:03 -0000 Greetings, all, Following up on the discussion of methods for promotion of Information = Elements, it seems we have a couple of approaches, and that they're not = really compatible: we do have to choose one. However, I'm not sure at this point that a solution to this problem = necessarily belongs in IE-DOCTORS: first, it's a corner case of = information element definition; second, it appears there does need to be = some more discussion about this, supported by a forthcoming proposed = solution by Paul. I believe this can be handled separately from the IE-DOCTORS and = RFC5102-bis documents, to prevent discussion on this issue from holding = up IE-DOCTORS and RFC5102-bis as well as to keep from rushing the = discussion in order to finish IE-DOCTORS and RFC5102-bis. Therefore, I propose to remove ESIE promotion from the upcoming = IE-DOCTORS revision (-04, which I plan to submit today) as well as to = remove the Enterprise-Specific Reference column from the IANA registry = definition in RFC5102-bis; I intend to post new versions today. Thoughts? Best regards, Brian= From internet-drafts@ietf.org Fri Aug 31 09:56:54 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104F921F865E; Fri, 31 Aug 2012 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DEb1tfaZT25; Fri, 31 Aug 2012 09:56:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B63621F8629; Fri, 31 Aug 2012 09:56:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> Date: Fri, 31 Aug 2012 09:56:53 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:56:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Guidelines for Authors and Reviewers of IPFIX Informatio= n Elements Author(s) : Brian Trammell Benoit Claise Filename : draft-ietf-ipfix-ie-doctors-04.txt Pages : 33 Date : 2012-08-31 Abstract: This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-ie-doctors-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Aug 31 09:57:03 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1EA21F866E; Fri, 31 Aug 2012 09:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeHGqj9dP8Aa; Fri, 31 Aug 2012 09:57:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C3D21F865E; Fri, 31 Aug 2012 09:57:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120831165702.28392.97957.idtracker@ietfa.amsl.com> Date: Fri, 31 Aug 2012 09:57:02 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:57:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-04.txt Pages : 29 Date : 2012-08-31 Abstract: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/