From iesg-secretary@ietf.org Mon Dec 3 08:25: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 1907D21F88A4; Mon, 3 Dec 2012 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 LixB0xA8ggVH; Mon, 3 Dec 2012 08:25:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79021F88B8; Mon, 3 Dec 2012 08:25:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203162530.23475.24042.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 08:25:30 -0800 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Guidelines for Authors and Reviewers of IPFIX Information Elements' to Best Current Practice (draft-ietf-ipfix-ie-doctors-07.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: Mon, 03 Dec 2012 16:25:31 -0000 The IESG has approved the following document: - 'Guidelines for Authors and Reviewers of IPFIX Information Elements' (draft-ietf-ipfix-ie-doctors-07.txt) as Best Current Practice This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ Technical Summary 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. Working Group Summary This draft has been discussed already at WG sessions and on the mailing list for along time before adopting it as WG work item. There was strong consensus on the need for such a document and on the general content. Details has been discussed extensively. WGLC was conducted in February 2012. Raise issues in the LC Phase were discussed and fixed. Document Quality This BCP for IPFIX IE doctors summarizes experiences gained in several years of dealing with new proposals for IEs. Personnel By default, Benoit Claise would be the responsible area director. But since Benoit Claise is co-author of the draft, the responsible area director is Ron Bonica. Document shepherd is Juergen Quittek. From andrewf@plixer.com Mon Dec 3 19:59:59 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 EC98821E8037 for ; Mon, 3 Dec 2012 19:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFN1Tlab3WLX for ; Mon, 3 Dec 2012 19:59:59 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDFF21E8034 for ; Mon, 3 Dec 2012 19:59:59 -0800 (PST) Received: from [192.168.1.37] ([24.34.46.175]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 22:59:57 -0500 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 03 Dec 2012 22:59:49 -0500 From: Andrew Feren To: Paul Aitken , IETF IPFIX Working Group Message-ID: Thread-Topic: [IPFIX] RFC 3550 jitter In-Reply-To: <50B64A4F.6030003@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Dec 2012 03:59:57.0941 (UTC) FILETIME=[D3727250:01CDD1D3] Subject: Re: [IPFIX] RFC 3550 jitter 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, 04 Dec 2012 04:00:00 -0000 Hi Paul, Is it necessary to have an IE each possible jitter calculation and the document where that calculation is defined? Seems like we could end up with a huge pile of jitter IEs. Are there other calculated values that have need to specify how they were calculated? PSAMP has selectorAlgorithm etc., applicationId has an embedded Classification Engine ID, do we need some sort of calculationTypeId for calculated values like jitter? -Andrew On 11/28/12 12:30 PM, "Paul Aitken" wrote: >Dear all, > >I received feedback that the name should include "mean" and 'rfc3550', >since there are other jitter metrics which take into account all samples >rather than running average based last 16 samples as done by RFC3550. > >So the proposed names could be rfc3550JitterMeanMilliseconds, >rfc3550JitterMeanMicroseconds, and rfc3550JitterMeanNanoseconds. > >P. > > >On 28/11/12 15:25, Paul Aitken wrote: >> Dear IPFIX experts, >> >> I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines >> a suitable "interarrival jitter". Unfortunately it's measured in >> "timestamp units": >> >> An estimate of the statistical variance of the RTP data packet >> interarrival time, measured in timestamp units and expressed as an >> unsigned integer. >> >> >> Therefore it seems we may need multiple IEs: one for units of >> milliseconds, one for microseconds, one for nanoseconds... >> Else comparison of two jitter values would be meaningless. >> >> So I request your feedback on the following: >> >> Name: interarrivalJitterMilliseconds >> Type: unsigned32 >> Semantic: quantity >> Description: interarrival jitter as defined in section 6.4.1 of RFC >> 3550, measured in milliseconds. >> Units: milliseconds >> References: [RFC3550] >> >> Name: interarrivalJitterMicroseconds >> Type: unsigned32 >> Semantic: quantity >> Description: interarrival jitter as defined in section 6.4.1 of RFC >> 3550, measured in microseconds. >> Units: microseconds >> References: [RFC3550] >> >> Name: interarrivalJitterNanoseconds >> Type: unsigned32 >> Semantic: quantity >> Description: interarrival jitter as defined in section 6.4.1 of RFC >> 3550, measured in nanoseconds. >> Units: nanoseconds >> References: [RFC3550] >> >> 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 From andrewf@plixer.com Mon Dec 3 20:18:39 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 4DE3421F8599 for ; Mon, 3 Dec 2012 20:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huRu0a1X5il4 for ; Mon, 3 Dec 2012 20:18:38 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8921F8585 for ; Mon, 3 Dec 2012 20:18:38 -0800 (PST) Received: from [192.168.1.37] ([24.34.46.175]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 23:18:37 -0500 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 03 Dec 2012 23:18:33 -0500 From: Andrew Feren To: Brian Trammell Message-ID: Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-07.txt In-Reply-To: <20121003144756.4800.68013.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Dec 2012 04:18:37.0709 (UTC) FILETIME=[6EE17BD0:01CDD1D6] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-07.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: Tue, 04 Dec 2012 04:18:39 -0000 Hi Brian, I haven't reread this entire draft, but happened to notice that this version still has "Specific examples of such Information Elements include initiatorOctets and responderOctets (which duplicate octetDeltaCount and its reverse per [RFC5103 ]) and initiatorPackets and responderPackets (the same, for packetDeltaCount)." Which is not correct Earlier discussion at http://www.ietf.org/mail-archive/web/ipfix/current/msg06451.html http://www.ietf.org/mail-archive/web/ipfix/current/msg06456.html -Andrew On 10/3/12 10:47 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IP Flow Information Export Working >Group of the IETF. > > Title : Guidelines for Authors and Reviewers of IPFIX >Information Elements > Author(s) : Brian Trammell > Benoit Claise > Filename : draft-ietf-ipfix-ie-doctors-07.txt > Pages : 33 > Date : 2012-10-03 > >Abstract: > This document provides guidelines for how to write definitions of new > Information Elements for the IP Flow Information Export (IPFIX) > protocol. It provides instructions on using the proper conventions > for Information Elements to be registered in the IANA IPFIX > Information Element registry, and provides guidelines for expert > reviewers to evaluate new registrations. > > >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-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-ie-doctors-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Tue Dec 4 01:44: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 5284821F875A for ; Tue, 4 Dec 2012 01:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuRbLjemwNhl for ; Tue, 4 Dec 2012 01:44:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4554E21F876D for ; Tue, 4 Dec 2012 01:44:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A3DCAD9309; Tue, 4 Dec 2012 10:44:10 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JHhMZ7LX8s8a; Tue, 4 Dec 2012 10:44:10 +0100 (MET) Received: from [80.48.104.80] (unknown [80.48.104.80]) (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 45337D9305; Tue, 4 Dec 2012 10:44:10 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Tue, 4 Dec 2012 10:44:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <662DB88B-EAB3-4980-BED3-59AB29552DA3@tik.ee.ethz.ch> References: To: Andrew Feren X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-07.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: Tue, 04 Dec 2012 09:44:17 -0000 Hi, Andrew, I recall this thread, but had completely missed the resolution to it; = apologies, and thanks for bringing it back up. Rereading the descriptions and the approved revision of ie-doctors, = there are two problems with the draft text: (1) the assumed semantics are incorrect; and (2) initiatorOctets doesn't actually duplicate octetTotalCount (since it = counts from the end of the L4 payload as opposed to the beginning of the = L3 header). The following problems still exist with these IEs: (3) initiatorPackets still appears to duplicate packetTotalCount, = unless... (3a) the definition of initiatorPackets is interpreted in a certain way. = As it is, it's still ambiguous to the point of not being implementable: = "The total number of layer 4 packets in a flow from the initiator"... = What is a "layer 4 packet"? Is this a packet containing payload beyond = the layer 4 header? containing content that will be delivered to the = application (which may be different, depending on which layer 4)? a = packet containing a layer 4 header known to the MP? (4) responder{Octets/Packets} still duplicate the RFC 5103 reversed = versions of initiatorOctets and initiatorPackets using "initiator" = biflowDirection, which goes against the general rule to reuse IEs when = necessary. =46rom a process standpoint, I'm not sure what the right thing to do is, = as IE-DOCTORS is now in the RFC-EDITOR queue. I believe the point made = by this paragraph (the second in section 4.9) to be a necessary one, but = the examples given are clearly in error. The meaning of the text is = conveyed by the first sentence, which does not require update; the = example is non-normative. I believe that the problem is therefore = editorial, and would propose an RFC-EDITOR note like the following = during AUTH48: OLD: Before registering a new Information Element, it must be determined that it would be sufficiently unique within the IANA IE registry. This evaluation has not always been done in the past, and the existence of the Information Elements defined without this evaluation should not be taken as an example that such Information Element definition practices should be followed in the future. Specific examples of such Information Elements include initiatorOctets and responderOctets (which duplicate octetDeltaCount and its reverse per [RFC5103]) and initiatorPackets and responderPackets (the same, for packetDeltaCount). NEW: Before registering a new Information Element, it must be determined that it would be sufficiently unique within the IANA IE registry. This evaluation has not always been done in the past, and the existence of the Information Elements defined without this evaluation should not be taken as an example that such Information Element definition practices should be followed in the future. Specific examples of such Information Elements include initiatorPackets and responderPackets (which appear to duplicate packetTotalCount and=20 its reverse per [RFC5103]). However, I'd like a ruling from our Friendly Area Directors as to = whether this an acceptable resolution at this stage. Separate from this, issue (3a) above concerning the ambiguity of = initiatorPackets and responderPackets should be handled with a revision = to the Information Element definitions. Cheers, Brian On 4 Dec 2012, at 5:18, Andrew Feren wrote: > Hi Brian, >=20 > I haven't reread this entire draft, but happened to notice that this > version still has=20 >=20 > "Specific > examples of such Information Elements include initiatorOctets and > responderOctets (which duplicate octetDeltaCount and its reverse per > [RFC5103 ]) and initiatorPackets > and responderPackets (the same, for > packetDeltaCount)." >=20 >=20 > Which is not correct >=20 > Earlier discussion at >=20 > http://www.ietf.org/mail-archive/web/ipfix/current/msg06451.html >=20 > http://www.ietf.org/mail-archive/web/ipfix/current/msg06456.html >=20 >=20 > -Andrew >=20 > On 10/3/12 10:47 AM, "internet-drafts@ietf.org" = > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Flow Information Export Working >> Group of the IETF. >>=20 >> Title : Guidelines for Authors and Reviewers of IPFIX >> Information Elements >> Author(s) : Brian Trammell >> Benoit Claise >> Filename : draft-ietf-ipfix-ie-doctors-07.txt >> Pages : 33 >> Date : 2012-10-03 >>=20 >> Abstract: >> This document provides guidelines for how to write definitions of = new >> Information Elements for the IP Flow Information Export (IPFIX) >> protocol. It provides instructions on using the proper conventions >> for Information Elements to be registered in the IANA IPFIX >> Information Element registry, and provides guidelines for expert >> reviewers to evaluate new registrations. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-ie-doctors-07 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 From paitken@cisco.com Tue Dec 4 04:01: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 357F421F867C for ; Tue, 4 Dec 2012 04:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlOP+d0zlVta for ; Tue, 4 Dec 2012 04:01:16 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8E21F85EA for ; Tue, 4 Dec 2012 04:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3405; q=dns/txt; s=iport; t=1354622476; x=1355832076; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HsbWwWK/pr2U9I68yk1DAVXo2b+7bwWlkjH/kk1pqZg=; b=C2GehRhP6mB3NPwZFQH3mm7R7uRdMXh1I1gerHkjX4Cnx2orZPuy3ZVF 7OxNl94InS6I2zZ6LIZkNT6oPC7KukQ1QugRmz6H43GAF7aNkt7TSrzas VR4fNXs2xOBGNNkTe7bZX59UzYnzD4cZLpKcYVs3sfhJIuhuyK5gbucUf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIvlvVCQ/khM/2dsb2JhbABEvjMWc4IeAQEBAgEBAQEBNTMDCgEFCwsYCQwKDwkDAgECARUwBg0BBQIBAReHbwYMsDyQU41OgzMDlgKBHIRPilyCcg X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="10140074" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 04 Dec 2012 12:01:14 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB4C1E75006341; Tue, 4 Dec 2012 12:01:14 GMT Message-ID: <50BDE60A.9090503@cisco.com> Date: Tue, 04 Dec 2012 12:01:14 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Feren References: 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] RFC 3550 jitter 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, 04 Dec 2012 12:01:17 -0000 Andrew, This is a great point. It was also raised privately (off list) by one other responder. Cisco already has a large number of jitter metrics which we export in enterprise-specific fields. RFC 3550 jitter was the only one we thought standardisable. I expect others have similar ES fields for their own jitter metrics. One solution would be to use the same mechanism that I proposed for MIB export, ie Extended Field Specifiers. ie, we'd have a single export ID for "jitter", to which an extension can be applied indicating which jitter it is, which implies how it's calculated. See slide 7 here: http://tools.ietf.org/agenda/85/slides/slides-85-ipfix-2.pdf P. > Is it necessary to have an IE each possible jitter calculation and the > document where that calculation is defined? Seems like we could end up > with a huge pile of jitter IEs. Are there other calculated values that > have need to specify how they were calculated? PSAMP has > selectorAlgorithm etc., applicationId has an embedded Classification > Engine ID, do we need some sort of calculationTypeId for calculated values > like jitter? > > -Andrew > > On 11/28/12 12:30 PM, "Paul Aitken" wrote: > >> Dear all, >> >> I received feedback that the name should include "mean" and 'rfc3550', >> since there are other jitter metrics which take into account all samples >> rather than running average based last 16 samples as done by RFC3550. >> >> So the proposed names could be rfc3550JitterMeanMilliseconds, >> rfc3550JitterMeanMicroseconds, and rfc3550JitterMeanNanoseconds. >> >> P. >> >> >> On 28/11/12 15:25, Paul Aitken wrote: >>> Dear IPFIX experts, >>> >>> I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines >>> a suitable "interarrival jitter". Unfortunately it's measured in >>> "timestamp units": >>> >>> An estimate of the statistical variance of the RTP data packet >>> interarrival time, measured in timestamp units and expressed as an >>> unsigned integer. >>> >>> >>> Therefore it seems we may need multiple IEs: one for units of >>> milliseconds, one for microseconds, one for nanoseconds... >>> Else comparison of two jitter values would be meaningless. >>> >>> So I request your feedback on the following: >>> >>> Name: interarrivalJitterMilliseconds >>> Type: unsigned32 >>> Semantic: quantity >>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>> 3550, measured in milliseconds. >>> Units: milliseconds >>> References: [RFC3550] >>> >>> Name: interarrivalJitterMicroseconds >>> Type: unsigned32 >>> Semantic: quantity >>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>> 3550, measured in microseconds. >>> Units: microseconds >>> References: [RFC3550] >>> >>> Name: interarrivalJitterNanoseconds >>> Type: unsigned32 >>> Semantic: quantity >>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>> 3550, measured in nanoseconds. >>> Units: nanoseconds >>> References: [RFC3550] >>> >>> 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 From andrewf@plixer.com Tue Dec 4 08:56: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 039C621F8720 for ; Tue, 4 Dec 2012 08:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_37=0.6] 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 XgflBzUL02xo for ; Tue, 4 Dec 2012 08:56:23 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6B21F85D1 for ; Tue, 4 Dec 2012 08:56:21 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 11:56:20 -0500 Message-ID: <50BE2B34.8070000@plixer.com> Date: Tue, 04 Dec 2012 11:56:20 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20.0 Thunderbird/20.0a1 MIME-Version: 1.0 To: Benoit Claise , Nevil Brownlee References: <50AEF1D1.9010809@auckland.ac.nz> <50AF39CA.7070706@cisco.com> In-Reply-To: <50AF39CA.7070706@cisco.com> Content-Type: multipart/mixed; boundary="------------090808060209040709000201" X-OriginalArrivalTime: 04 Dec 2012 16:56:20.0651 (UTC) FILETIME=[48E7E7B0:01CDD240] Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-protocol-rfc5101bis-03 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, 04 Dec 2012 16:56:31 -0000 This is a multi-part message in MIME format. --------------090808060209040709000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Benoit, All, Attached is a marked up version of the draft. Notes all tagged with ACF. -Andrew On 11/23/2012 03:54 AM, Benoit Claise wrote: > Dear all, Nevil, > > Trying to avoid any potential confusing, correcting the subject to the > correct draft name: draft-ietf-ipfix-protocol-rfc5101bis-03 > > Regards, Benoit >> >> Hi all: >> >> Following up on Brian's email dated 20 November ... >> >> The WG Last Call for this I-D starts now, and will run until Monday, >> 10 December. >> >> Do please read the draft, and post your comments to the list. It's >> important that we can show it has been well-considered/reviewed within >> the WG, so short comments like "yes, this does clearly describe the >> IPFIX Information Model as we want it to be" are important and useful! >> >> Cheers, Nevil >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------090808060209040709000201 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-ipfix-protocol-rfc5101bis-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ipfix-protocol-rfc5101bis-03.txt" Network Working Group B. Claise, Ed. Internet Draft Cisco Systems, Inc. Obsoletes: 5101 B. Trammell, Ed. Category: Standards Track ETH Zurich Expires: May 24, 2013 November 20, 2012 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information draft-ietf-ipfix-protocol-rfc5101bis-03 Abstract This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. 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 March 23, 2012. Copyright Notice Copyright (c) 2011 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 Standards Track [Page 1] Internet-Draft IPFIX Protocol Specification November 20, 2012 (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. Table of Contents 1.1. Changes since RFC 5101 . . . . . . . . . . . . . . . . . . 4 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 11 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 11 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 14 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 15 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 16 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 17 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 18 3.4.2. Options Template Record Format . . . . . . . . . . . . 20 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 21 3.4.2.2. Options Template Record Format . . . . . . . . . . 22 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 24 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 25 4.1. The Metering Process Statistics Options Template . . . . . 25 4.2. The Metering Process Reliability Statistics Options Template . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. The Exporting Process Reliability Statistics Options Template . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 29 5. IPFIX Message Header Export Time and Flow Record Time . . . . 30 6. Linkage with the Information Model . . . . . . . . . . . . . . 30 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 31 6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 31 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 32 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 32 Standards Track [Page 2] Internet-Draft IPFIX Protocol Specification November 20, 2012 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 32 6.2. Reduced Size Encoding . . . . . . . . . . . . . . . . . . 33 7. Variable-Length Information Element . . . . . . . . . . . . . 34 8. Template Management . . . . . . . . . . . . . . . . . . . . . 36 8.1. Template Withdrawal and Redefinition . . . . . . . . . . . 37 8.2 Sequencing Template Management Actions . . . . . . . . . . 39 8.3. Additional considerations for Template Management over SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.4. Additional considerations for Template Management over UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 41 9.1. Additional considerations for SCTP Collecting Processes . 42 9.2. Additional considerations for UDP Collecting Processes . . 42 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 42 10.1. Transport Compliance and Transport Usage . . . . . . . . 44 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 44 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 44 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.2.4. Association Establishment and Shutdown . . . . . . . 45 10.2.5. Failover . . . . . . . . . . . . . . . . . . . . . . 46 10.2.6. Streams . . . . . . . . . . . . . . . . . . . . . . . 46 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 46 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 46 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.3.4. Session Establishment and Shutdown . . . . . . . . . 47 10.3.5. Failover and Session Duplication . . . . . . . . . . 47 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 48 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 49 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.4.4. Connection Establishment, Shutdown, and Restart . . . 49 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 51 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 52 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 53 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 54 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 55 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 55 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 56 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 56 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 57 A.2.1. Template Set Using IETF-Specified Information Elements . . . . . . . . . . . . . . . . . . . . . . . 57 Standards Track [Page 3] Internet-Draft IPFIX Protocol Specification November 20, 2012 A.2.2. Template Set Using Enterprise-Specific Information Elements . . . . . . . . . . . . . . . . . . . . . . . 57 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 59 A.4. Options Template Set Examples . . . . . . . . . . . . . . 60 A.4.1. Options Template Set Using IETF-Specified Information Elements . . . . . . . . . . . . . . . . . 60 A.4.2. Options Template Set Using Enterprise-Specific Information . . . . . . . . . . . . . . . . . . . . . 60 A.4.3. Options Template Set Using an Enterprise-Specific Scope . . . . . . . . . . . . . . . . . . . . . . . . 61 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 62 A.5. Variable-Length Information Element Examples . . . . . . . 63 A.5.1. Example of Variable-Length Information Element with Length . . . . . . . . . . . . . . . . . . . . . . . . 63 A.5.2. Example of Variable-Length Information Element with 3 Octet Length Encoding . . . . . . . . . . . . . . . 63 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Normative References . . . . . . . . . . . . . . . . . . . . . . . 63 Informative References . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 1. Introduction Traffic on a data network can be seen as consisting of flows passing through network elements. It is often interesting, useful, or even necessary to have access to information about these flows that pass through the network elements for administrative or other purposes. A collecting process should be able to receive the flow information [ACF - "Collecting Process"? or keep "collecting process" ] passing through multiple network elements within the data network. This requires uniformity in the method of representing the flow information and the means of communicating the flows from the network elements to the collection point. This document specifies a protocol to achieve these aforementioned requirements. This document specifies [ACF - I'd drop the "aforementioned".] in detail the representation of different flows, the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc. 1.1. Changes since RFC 5101 This document obsoletes the Proposed Standard revision of the IPFIX Protocol Specification [RFC5101]. The protocol specified by this document is interoperable with the protocol as specified in [RFC5101]. The following changes have been made to this document with respect to the previous document: Standards Track [Page 4] Internet-Draft IPFIX Protocol Specification November 20, 2012 - EDITOR'S NOTE: not sure if we need to this information Errata ID: 1655 (technical) Errata ID: 2791 (technical) Errata ID: 2814 (editorial) Errata ID: 1818 (editorial) Errata ID: 2792 (editorial) Errata ID: 2888 (editorial) Errata ID: 2889 (editorial) Errata ID: 2890 (editorial) Errata ID: 2891 (editorial) Errata ID: 2892 (editorial) Errata ID: 2903 (editorial) Errata ID: 2761 (editorial) Errata ID: 2762 (editorial) Errata ID: 2763 (editorial) Errata ID: 2764 (editorial) Errata ID: 2852 (editorial) Errata ID: 2857 (editorial) - The encoding of the dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, and dateTimeNanoseconds data types, and the related encoding of the IPFIX Message Header Export Time field, have been clarified, especially with respect to the epoch upon which the timestamp data types are based. - Clarifications on encoding, especially in Section 6: all IPFIX values encoded big-endian. - Template management in section 8 has been simplified, and made as independent of transport protocol as is interoperably possible, by relaxing restrictions on template management actions. - Editorial changes, including structural changes to sections 8, 9, and 10 to improve readability. 1.2. IPFIX Documents Overview The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. This document specifies how IPFIX data records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. Four IPFIX optimizations/extensions are currently specified: a bandwidth saving method for the IPFIX protocol in [RFC5473], an Standards Track [Page 5] Internet-Draft IPFIX Protocol Specification November 20, 2012 efficient method for exporting bidirectional flow in [RFC5103], a method for the definition and export of complex data structures in [RFC6313], and the specification of the Protocol for IPFIX Mediations [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. [ACF - IPIFX should be IPFIX ] IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102bis], with the export of the Information Element types specified in [RFC5610]. [IPFIX-CONF] specifies a data model for configuring and monitoring IPFIX and PSAMP compliant devices using the NETCONF protocol, while the [RFC5815bis] specifies a MIB module for monitoring. In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing. Finally, [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. 2. Terminology 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]. The definitions of the basic terms like Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical to those found in the IPFIX requirements document [RFC3917]. Some of the terms have been expanded for more clarity when defining the protocol. Additional terms required for the protocol have also been defined. Definitions in this document and in [RFC5470] are equivalent, except that definitions that are only relevant to the IPFIX protocol only appear here. [ACF - all are equivalent except when they aren't seems awkward. How about... the protocol have also been defined. Definitions in this document and in [RFC5470] are equivalent. Any definitions that are only relevant to the IPFIX protocol only appear here. ] The terminology summary table in Section 2.1 gives a quick overview of the relationships between some of the different terms defined. Observation Point An Observation Point is a location in the network where packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. Standards Track [Page 6] Internet-Draft IPFIX Protocol Specification November 20, 2012 Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces. Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device. Traffic Flow or Flow There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition: A Flow is defined as a set of packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. one or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (e.g., RTP header fields [RFC3550]). 2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc...). 3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc...). A packet is defined as belonging to a Flow if it completely satisfies all the defined properties of the Flow. Note that the set of packets represented by a Flow may be empty; Standards Track [Page 7] Internet-Draft IPFIX Protocol Specification November 20, 2012 that is, a Flow may represent zero or more packets. Note also that as sampling is a packet treatent, this definition includes packets [ACF - treatent should be treatment ] selected by a sampling mechanism. Flow Key Each of the fields that: 1. belong to the packet header (e.g., destination IP address), 2. are a property of the packet itself (e.g., packet length), 3. are derived from packet treatment (e.g., Autonomous System (AS) number), and that are used to define a Flow are termed Flow Keys. Flow Record A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address). Metering Process The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface). The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. Exporting Process The Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes. Exporter Standards Track [Page 8] Internet-Draft IPFIX Protocol Specification November 20, 2012 A device that hosts one or more Exporting Processes is termed an Exporter. IPFIX Device An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes. Collecting Process A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document. Collector A device that hosts one or more Collecting Processes is termed a Collector. Template A Template is an ordered sequence of pairs used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID. IPFIX Message An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer. Message Header The Message Header is the first part of an IPFIX Message, which provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc. Template Record A Template Record defines the structure and interpretation of fields in a Data Record. Data Record Standards Track [Page 9] Internet-Draft IPFIX Protocol Specification November 20, 2012 A Data Record is a record that contains values of the parameters corresponding to a Template Record. Options Template Record An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record. Set Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header. There are three different types of Sets: Template Set, Options Template Set, and Data Set. Template Set A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message. Options Template Set An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message. Data Set A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record. Information Element An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model [RFC5102bis] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX. Transport Session Standards Track [Page 10] Internet-Draft IPFIX Protocol Specification November 20, 2012 In Stream Control Transmission Protocol (SCTP), the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]; in TCP, the transport session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the transport session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used. 2.1. Terminology Summary Table +------------------+---------------------------------------------+ | | contents | | +--------------------+------------------------+ | Set | Template | record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Figure A: Terminology Summary Table A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record. A Template Set contains only Template Record(s). An Options Template Set contains only Options Template Record(s). 3. IPFIX Message Format An IPFIX Message consists of a Message Header, followed by one or more Sets. The Sets can be any of the possible three types: Data Set, Template Set, or Options Template Set. The format of the IPFIX Message is shown in Figure B. +----------------------------------------------------+ | Message Header | +----------------------------------------------------+ | Set | +----------------------------------------------------+ | Set | Standards Track [Page 11] Internet-Draft IPFIX Protocol Specification November 20, 2012 +----------------------------------------------------+ ... +----------------------------------------------------+ | Set | +----------------------------------------------------+ Figure B: IPFIX Message Format The Exporter MUST encode all integers in the Message Header and the [ACF - What about floats?] Set Headers in network byte order (also known as big-endian byte order). [ACF - How about unless otherwise noted ALL fields must be encoded using network byte order. Turns out section 6 uses language closer to what I suggested above. " As with values in the IPFIX Message Header and Set Header, values of all Information Elements [RFC5102bis], except for those of the string and octetArray data types, are encoded in canonical format in network byte order (also known as big-endian byte ordering)." We also seem to beat the endianness to death. It is an important detail, but as somepoint stating it over and over again just becomes noise. I'd rather see a clear broad statement in one spot and make exceptions as needed. ] Following are some examples of IPFIX Messages: 1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets -- A newly created Template is exported as soon as possible. So, if there is already an IPFIX Message with a Data Set that is being prepared for export, the Template and Options Template Sets are interleaved with this information, subject to availability of space. Standards Track [Page 12] Internet-Draft IPFIX Protocol Specification November 20, 2012 +--------+--------------------------------------------------------+ | | +----------+ +---------+ +-----------+ +---------+ | |Message | | Template | | Data | | Options | | Data | | | Header | | Set | | Set | ... | Template | | Set | | | | | | | | | Set | | | | | | +----------+ +---------+ +-----------+ +---------+ | +--------+--------------------------------------------------------+ Figure C: IPFIX Message, Example 1 2. An IPFIX Message consisting entirely of Data Sets -- After the appropriate Template Records have been defined and transmitted to the Collecting Process, the majority of IPFIX Messages consist solely of Data Sets. +--------+----------------------------------------------+ | | +---------+ +---------+ +---------+ | |Message | | Data | | Data | | Data | | | Header | | Set | ... | Set | ... | Set | | | | +---------+ +---------+ +---------+ | +--------+----------------------------------------------+ Figure D: IPFIX Message, Example 2 3. An IPFIX Message consisting entirely of Template and Options Template Sets. +--------+-------------------------------------------------+ | | +----------+ +----------+ +----------+ | |Message | | Template | | Template | | Options | | | Header | | Set | ... | Set | ... | Template | | | | | | | | | Set | | | | +----------+ +----------+ +----------+ | +--------+-------------------------------------------------+ Figure E: IPFIX Message, Example 3 Standards Track [Page 13] Internet-Draft IPFIX Protocol Specification November 20, 2012 3.1. Message Header Format The format of the IPFIX Message Header is shown in Figure F. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure F: IPFIX Message Header Format Message Header Field Descriptions: Version Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954]. Length Total length of the IPFIX Message, measured in octets, including Message Header and Set(s). Export Time Time at which the IPFIX Message Header leaves the Exporter, expressed in seconds since the UNIX epoch of 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer. Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in a the current stream from the current Observation Domain [ACF - "in a the" should be "in the" ] by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number. Standards Track [Page 14] Internet-Draft IPFIX Protocol Specification November 20, 2012 [ACF - "The "Observation Domain ID" header seems to have gone AWOL] A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporter. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported. [ACF - I feel like I'm missing something here. What does a hierarchy of Collectors have to do with setting observationDomainId?] 3.2. Field Specifier Format Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standards product, or the Information Element is, in some way, commercially sensitive. This section describes the Field Specifier format for both IETF-specified Information Elements [RFC5102bis] and enterprise- specific Information Elements. The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2. The Field Specifier format is shown in Figure G. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure G: Field Specifier Format Standards Track [Page 15] Internet-Draft IPFIX Protocol Specification November 20, 2012 Where: E Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four- octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise- specific Information Element, and the Enterprise Number filed [ACF - "filed" should be "field"] MUST be present. Information Element identifier A numeric value that represents the type of Information Element. Refer to [RFC5102bis]. [ACF - I think this was discussed on the mailing list, but I don't recall the conclusion. Is it worth also adding a reference to IANA here? RFC5102bis should ultimately direct readers there so I'm not sure how much it matters.] Field Length The length of the corresponding encoded Information Element, in octets. Refer to [RFC5102bis]. The field length may be smaller than the definition in [RFC5102bis] if the reduced size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7). [ACF - we use "variable-length", "variable length" and "Variable-Length" in various places. I don't have a strong opinion as to which, but we should pick one.] Enterprise Number IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record. 3.3. Set and Set Header Format A Set is a generic term for a collection of records that have a similar structure. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets. Each of these Sets consists of a Set Header and one or more records. The Set Format and the Set Header Format are defined in the following sections. 3.3.1. Set Format A Set has the format shown in Figure H. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set. Standards Track [Page 16] Internet-Draft IPFIX Protocol Specification November 20, 2012 +--------------------------------------------------+ | Set Header | +--------------------------------------------------+ | record | +--------------------------------------------------+ | record | +--------------------------------------------------+ ... +--------------------------------------------------+ | record | +--------------------------------------------------+ | Padding (opt.) | +--------------------------------------------------+ [ACF - There is plenty of space let's spell out "optional" or even OPTIONAL] Figure H: Set Format The Set Field Definitions are as follows: Set Header The Set Header Format is defined in Section 3.3.2. Record One of the record Formats: Template Record, Options Template Record, or Data Record Format. Padding The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets. The padding length MUST be shorter than any allowable record in this Set. If padding of the IPFIX Message is desired in combination with very short records, then the padding Information Element 'paddingOctets' [RFC5102bis] can be used for padding records such that their length is increased to a multiple of 4 or 8 octets. Because Template Sets are always 4-octet aligned by definition, padding is only needed in case of other alignments e.g., on 8-octet boundaries. 3.3.2. Set Header Format Every Set contains a common header. This header is defined in Figure I. Standards Track [Page 17] Internet-Draft IPFIX Protocol Specification November 20, 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure I: Set Header Format The Set Header Field Definitions are as follows: Set ID Set ID value identifies the Set. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Options Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. Length Total length of the Set, in octets, including the Set Header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set. 3.4. Record Format IPFIX defines three record formats, defined in the next sections: the Template Record Format, the Options Template Record Format, and the Data Record Format. 3.4.1. Template Record Format One of the essential elements in the IPFIX record format is the Template Record. Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process IPFIX Messages without necessarily knowing the interpretation of all Data Records. A Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers. The format of the Template Record is shown in Figure J. It consists of a Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above. Standards Track [Page 18] Internet-Draft IPFIX Protocol Specification November 20, 2012 +--------------------------------------------------+ | Template Record Header | +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ ... +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ Figure J: Template Record Format The format of the Template Record Header is shown in Figure K. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID (> 255) | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure K: Template Record Header Format The Template Record Header Field Definitions are as follows: Template ID Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation. Field Count Number of fields in this Template Record. The example in Figure L shows a Template Set with mixed standard and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers. Standards Track [Page 19] Internet-Draft IPFIX Protocol Specification November 20, 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 1.1 | Field Length 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element id. 1.2 | Field Length 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 1.N | Field Length 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element id. 2.1 | Field Length 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 2.2 | Field Length 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 2.M | Field Length 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ACF - There is plenty of space let's spell out "optional" or even OPTIONAL] Figure L: Template Set Example Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them. 3.4.2. Options Template Record Format Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector that would not be possible with Flow Records alone. Standards Track [Page 20] Internet-Draft IPFIX Protocol Specification November 20, 2012 One Options Template Record example is the "Flow Keys", which reports the Flow Keys for a Template, which is defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the Template, which is defined as the scope. 3.4.2.1. Scope The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records. Note that the IPFIX Message Header already contains the Observation Domain ID (the identifier of the Observation Domain). If not zero, [ACF - "(the identifier of the Observation Domain)" seems redundant] this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message. The Observation Domain ID MUST be zero when the IPFIX Message contains Data Records with different Observation Domain ID values defined as scopes. Multiple Scope Fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are defined as "metering process" and [ACF - should "metering process" simply be meteringProcessId?] "template", the combined scope is this Template for this Metering [ACF - should "template" simply be templateId?] Process. The order of the Scope Fields, as defined in the Options Template Record, is irrelevant in this case. However, if the order of the Scope Fields in the Options Template Record is relevant, the order of the Scope Fields MUST be used. For example, if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function. In this case, the Collector deduces the function order by looking at the order of the scope in the Options Template Record. The scope is an Information Element specified in the IPFIX Information Model [RFC5102bis]. An IPFIX-compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements, such as meteringProcessId, exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However, some Information Element types don't make sense if specified as scope; for example, the counter Information Elements. Finally, note that the Scope Field Count MUST NOT be zero. Standards Track [Page 21] Internet-Draft IPFIX Protocol Specification November 20, 2012 3.4.2.2. Options Template Record Format An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers. The format of the Options Template Record is shown in Figure M. It consists of an Options Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above. +--------------------------------------------------+ | Options Template Record Header | +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ ... +--------------------------------------------------+ | Field Specifier | +--------------------------------------------------+ Figure M: Options Template Record Format The format of the Options Template Record Header is shown in Figure N. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID (> 255) | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure N: Options Template Record Header Format The Options Template Record Header Field Definitions are as follows: Template ID Template ID of this Options Template Record. This value is greater than 255. Standards Track [Page 22] Internet-Draft IPFIX Protocol Specification November 20, 2012 Field Count Number of all fields in this Options Template Record, including the Scope Fields. Scope Field Count Number of scope fields in this Options Template Record. The Scope Fields are normal Fields except that they are interpreted as scope at the Collector. The Scope Field Count MUST NOT be zero. The example in Figure O shows an Options Template Set with mixed IETF and enterprise-specific Information Elements. It consists of a Set Header, an Options Template Header, and several Field Specifiers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = N + M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = N |0| Scope 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 2 Field Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |1| Scope N Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Option 1 Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |0| Option M Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option M Field Length | Padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure O: Options Template Set Example Standards Track [Page 23] Internet-Draft IPFIX Protocol Specification November 20, 2012 3.4.3. Data Record Format The Data Records are sent in Data Sets. The format of the Data Record is shown in Figure P. It consists only of one or more Field Values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". +--------------------------------------------------+ | Field Value | +--------------------------------------------------+ | Field Value | +--------------------------------------------------+ ... +--------------------------------------------------+ | Field Value | +--------------------------------------------------+ Figure P: Data Record Format Note that Field Values do not necessarily have a length of 16 bits. Field Values are encoded according to their data type specified in [RFC5102bis]. Interpretation of the Data Record format can be done only if the Template Record corresponding to the Template ID is available at the Collecting Process. The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values. Standards Track [Page 24] Internet-Draft IPFIX Protocol Specification November 20, 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = Template ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 1 | Record 1 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 1 | Record 2 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 1 | Record 3 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure Q: Data Set, Containing Data Records 4. Specific Reporting Requirements Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process. The Options Template and Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations, MAY be implemented. If implemented, the specific Options Templates SHOULD be implemented as specified in these subsections. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates. The Collecting Process MUST check the possible combinations of Information Elements within the Options Template Records to correctly interpret the following Options Templates. 4.1. The Metering Process Statistics Options Template The Metering Process Statistics Options Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements that are defined in [RFC5102bis]: Standards Track [Page 25] Internet-Draft IPFIX Protocol Specification November 20, 2012 (scope) observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field. (scope) meteringProcessId An identifier of the Metering Process for which statistics are reported. This Information Element MUST be defined as a Scope Field. exportedMessageTotalCount The total number of IPFIX Messages that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization. exportedFlowRecordTotalCount The total number of Flow Records that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization. exportedOctetTotalCount The total number of octets that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re- initialization. [ACF - Should the above definitions be synced with IANA or maybe removed. If the definition is needed go to IANA. Most of those names seem pretty self explanitory. Maybe something like (scope) observationDomainId This Information Element MUST be defined as a Scope Field. (scope) meteringProcessId Information Element MUST be defined as a Scope Field. exportedMessageTotalCount exportedFlowRecordTotalCount exportedOctetTotalCount Looking at the stripped down version I wonder. Are we saying that observationDomainId MUST always be scope or MUST be scope in this particular template? ] The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable. Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field. 4.2. The Metering Process Reliability Statistics Options Template The Metering Process Reliability Options Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements that are defined in [RFC5102bis]: Standards Track [Page 26] Internet-Draft IPFIX Protocol Specification November 20, 2012 (scope) observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field. (scope) meteringProcessId The identifier of the Metering Process for which lack of reliability is reported. This Information Element MUST be defined as a Scope Field. ignoredPacketTotalCount The total number of IP packets that the Metering Process did not process. ignoredOctetTotalCount The total number of octets in observed packets that the Metering Process did not process. time first packet ignored The timestamp of the first packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. time last packet ignored The timestamp of the last packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. [ACF - Same questions as above. Should the above definitions be synced with IANA or maybe removed. etc. ... ] The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable. Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field. Standards Track [Page 27] Internet-Draft IPFIX Protocol Specification November 20, 2012 Since the Metering Process Reliability Option Template will logically contain two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic behind the time first packet ignored and time last packet ignored Information Elements. Note that the counters wrap-around for the timestamps SHOULD also be taken into account. [ACF - Why can't order be guaranteed? We SHOULD rely on it elsewhere. "If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process." More importantly can the collector at least assume that once it has figured out the ordering for a particular template that the ordering will remain consistent. Or MUST the collector determine the ordering for every record? ] 4.3. The Exporting Process Reliability Statistics Options Template The Exporting Process Reliability Options Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102bis]: (scope) Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102bis] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field. notSentFlowTotalCount The total number of Flows that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. Standards Track [Page 28] Internet-Draft IPFIX Protocol Specification November 20, 2012 time first flow dropped The time at which the first Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. time last flow dropped The time at which the last Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. [ACF - Same questions as above. Should the above definitions be synced with IANA or maybe removed. etc. ... ] The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable. Since the Exporting Process Reliability Option Template will logically contain two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process MUST determine which is the oldest and the most recent timestamp in order the determine the right semantic behind the time first packet ignored and time last packet ignored Information Elements. Note that the counters wrap-around for the timestamps SHOULD also be taken into account. [ACF - Same question as above. Why can't order be guaranteed?.] 4.4. The Flow Keys Options Template The Flow Keys Options Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow. The Flow Keys Options Template SHOULD contain the following Information Elements that are defined in [RFC5102bis]: Standards Track [Page 29] Internet-Draft IPFIX Protocol Specification November 20, 2012 (scope) templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field. flowKeyIndicator Bitmap with the positions of the Flow Keys in the Data Records. [ACF - Same questions as above. Should the above definitions be synced with IANA or maybe removed. etc. ... ] 5. IPFIX Message Header Export Time and Flow Record Time The IPFIX Message Header Export Time field is the time at which the IPFIX Message Header leaves the Exporter, expressed in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded in an unsigned 32-bit integer. Certain time-related Information Elements may be expressed as an offset from this Export Time. For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102bis], which encode the absolute time in microseconds in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102bis] in the Data Record, which respectively report the flow start and end time as negative offsets from the Export Time, as an unsigned 32-bit integer. This latter solution lowers the export bandwidth requirement, saving two bytes per timestamp, while increasing the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message. It must be noted that timestamps based on the Export Time impose some time constraints on the Data Records contained within the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102bis], the Data Record can only contain records with timestamps within 71 minutes of the Export Time. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset. 6. Linkage with the Information Model As with values in the IPFIX Message Header and Set Header, values of all Information Elements [RFC5102bis], except for those of the string and octetArray data types, are encoded in canonical format in network byte order (also known as big-endian byte ordering). Standards Track [Page 30] Internet-Draft IPFIX Protocol Specification November 20, 2012 6.1. Encoding of IPFIX Data Types The following sections will define the encoding of the data types specified in [RFC5102bis]. 6.1.1. Integral Data Types Integral data types -- octet, signed8, unsigned16, signed16, unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded using the default canonical format in network byte order. Signed Integral data types are represented in two's complement notation. 6.1.2. Address Types Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types, as six, four, and sixteen octets in network byte order, respectively. 6.1.3. float32 The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985], in network byte order. 6.1.4. float64 The float64 data type MUST be encoded as an IEEE double-precision 64- bit floating point-type, as specified in [IEEE.754.1985], in network byte order. 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer in network byte [Captain Pedantic says - endianness for a single byte is a non issue] order, as in Section 6.1.1., with the value 1 for true and a value 2 for false. Every other value is undefined. 6.1.6. string and octetArray The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. [ACF - I have a question here. Should it be recommended for fixed length strings zero out trailing bytes? The reason I ask is that I endup having to do this in the collector. What I see receive on occasion is something like this "useful\0random_junk_to_end_of string". Unfortunately the random junk sometimes contains invalid UTF-8 which causes tools outside of my control to error. We already require that padding be zero for security reasons. Does the same apply here? Does that make zeroing a MUST?] The data type octetArray has no encoding rules; it represents a raw array of octets, with the intepretation of the octets defined in the [ACF - intepretation should be "interpretation"] Information Element definition. 6.1.7. dateTimeSeconds Standards Track [Page 31] Internet-Draft IPFIX Protocol Specification November 20, 2012 The data type dateTimeSeconds is an unsigned 32-bit integer in network byte order containing the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. dateTimeSeconds is encoded identically to the IPFIX Message Header Export Time field. It can represent dates between 1 January 1970 and 8 February 2106. 6.1.8. dateTimeMilliseconds The data type dateTimeMilliseconds is an unsigned 64-bit integer in network byte order, containing the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It can represent dates beginning on 1 January 1970 for approximately the next 500 billion years. 6.1.9 dateTimeMicroseconds The data type dateTimeMicroseconds is a 64-bit field encoded according to the NTP Timestamp format as defined in section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order, Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates beginning between 1 January 1900 and 8 February 2036. Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. The dataTimeMicroseconds data type is intended [ACF - dataTimeMicroseconds should be dateTimeMicroseconds] only to represent timestamps of microsecond precision. Therefore, the bottom 11 bits of the fraction field MAY contain any value and MUST be ignored for all Information Elements of this data type (as 2^11 x 233 picoseconds = .477 microseconds). 6.1.10 dateTimeNanoseconds The data type dateTimeNanoseconds is a 64-bit field encoded according to the NTP Timestamp format as defined in section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order, Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates beginning between 1 January 1900 and 8 February 2036. Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. There is no restriction on the interpretation of the Fraction field for the dateTimeNanoseconds data type. Standards Track [Page 32] Internet-Draft IPFIX Protocol Specification November 20, 2012 6.2. Reduced Size Encoding Information Elements encoded as signed, unsigned, or float data types MAY be encoded using fewer octets than those implied by their type in the information model definition [RFC5102bis], based on the assumption that the smaller size is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [RFC5102bis] will always define the maximum encoding size. For instance, the information model [RFC5102bis] defines octetDeltaCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount, while an unsigned32 might be sufficient for an [ACF - byteCount? should that be byte count or octetDeltaCount?] access router. This behavior is indicated by the Exporter by specifying a size in the Template with a smaller length than that associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template. If reduced size encoding MAY be be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). Reduced size encoding MAY be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa, is also less precise. In this case, the float64 would be reduced in size to 4 octets. Reduced size encoding MUST NOT be applied to any other data type defined in [RFC5102bis] that implies a fixed length, as these types either have internal structure (such as ipv4Address or dateTimeMicroseconds) or restricted ranges that are not suitable for reduced length encoding (such as dateTimeMilliseconds). Information Elements of type octetArray and string may be exported using any length, subject to restrictions on length specific to each Information Element, as noted in that Information Element's description. Standards Track [Page 33] Internet-Draft IPFIX Protocol Specification November 20, 2012 7. Variable-Length Information Element The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC5102bis]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IETF and proprietary Information Elements. In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that length of the Information Element will be carried in the Information Element content itself. In most cases, the length of the Information Element will be less than 255 octets. The following length-encoding mechanism optimizes the overhead of carrying the Information Element length in this majority case. The length is carried in the octet before the Information Element, as shown in Figure R. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (< 255)| Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure R: Variable-Length Information Element (length < 255 octets) The length may also be encoded into 3 octets before the Information element allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, first octet of the Length field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | IE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure S: Variable-Length Information Element (length 0 to 65535 octets) [ACF - Not sure that it matters, but the max length MUST be < 65535. Section 10 notes. "The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535" ] The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Standards Track [Page 34] Internet-Draft IPFIX Protocol Specification November 20, 2012 Element. Standards Track [Page 35] Internet-Draft IPFIX Protocol Specification November 20, 2012 8. Template Management This section describes the management of Templates and Options Templates at the Exporting and Collecting Processes. The goal of Template management is to ensure, to the extent possible, that the Exporting Process and Collecting Process have a consistent view of the Templates and Options Templates used to encode and decode the Records sent from the Exporting Process to the Collecting Process. Achieving this goal is complicated somewhat by two factors: 1. the need to support the reuse of Template IDs within a Transport Session and 2. the need to support unreliable transmission for templates when UDP is used as the transport protocol for IPFIX Messages. The Template Management mechanisms defined in this section apply to IPFIX Message export on any supported Transport Protocol. Additional considerations specific to SCTP and UDP transport are given in sections 8.3 and 8.4, respectively. The Exporting Process assigns and maintains the Template IDs per Transport Session for the Exporter's Observation Domains. A newly created Template Record is assigned an unused Template ID by the Exporting Process. The Collecting Process MUST store all received Template Record information for the duration of each Transport Session until reuse or withdrawal as in section 8.1, except as noted in section 8.4, so that it can interpret the corresponding Data Records that are received in subsequent Data Sets. The Collecting Process MUST NOT assume that the Template IDs from a given Exporting Process refer to the same Templates as they did in previous Transport Sessions from the same Exporting Process. When a Transport Session is closed, the Collecting Process MUST discard all Templates received over that association and stop decoding IPFIX Messages that use those Templates. If a specific Information Element is required by a Template, but is not present in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record defined by a new Template. If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the address of Standards Track [Page 36] Internet-Draft IPFIX Protocol Specification November 20, 2012 the inner header. Collecting processes MUST properly handle Templates with multiple identical Information Elements. The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s). This ensures that the Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. However, if the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received. In any case, a Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message. Different Observation Domains from the same Transport Session MAY use the same Template ID value to refer to different Templates; Collecting Processes MUST properly handle this case. Options Templates and Templates which are related or interdependent (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent together in the same IPFIX Message. 8.1. Template Withdrawal and Redefinition Since a Template may have a lifetime at the Exporting Process independent of the Transport Session, IPFIX provides a mechanism for the withdrawal of templates and for the reuse of template IDs. This mechanism does not apply when UDP is used to transport IPFIX messages; for this case, see Section 8.4. Templates that will not be used further by an Exporting Process MUST be withdrawn by sending a Template Withdrawal Message. After receiving a Template Withdrawal, a Collecting Process MUST discard the Template and stop using it to interpret Data Sets. A Template Withdrawal consists of a Template Record for the Template ID to be with a Field Count of 0. The format of a Template Withdrawal is shown in Figure T. Standards Track [Page 37] Internet-Draft IPFIX Protocol Specification November 20, 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = (2 or 3) | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID N | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID ... | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID M | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure T: Template Withdrawal Set Format The Set ID field MUST contain the value 2 for Template Set Withdrawal and the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal, in that case, padding MAY be used. A Template Withdrawal Message is an IPFIX Message containing Template Withdrawals. It withdraws Template IDs for the Observation Domain ID specified in the IPFIX Message Header. It MUST NOT contain new Template or Options Template Records, or any Data Sets. The Exporting Process SHOULD NOT send a Template Withdrawal Message until sufficient time has elapsed to allow receipt and processing of and Data Records described by the withdrawn Templates; see section 8.2 for more information on sequencing Template Withdrawals. The end of a Transport Session implicitly withdraws all the Templates used within the Transport Session, and Templates must be resent during subsequent Transport Sessions between an Exporting Process and Collecting Process. All Templates for a given Observation Domain MAY also be withdrawn using an All Templates Withdrawal, which withdraws the special Template ID 2; this is shown in Figure U. All Options Templates for a given observation Domain MAY likewise be withdrawn using an All Options Templates Withdrawal, which withdraws the special Template ID 3. Each of these Withdrawals MUST appear in a Template Withdrawal Message with no other Withdrawals. Standards Track [Page 38] Internet-Draft IPFIX Protocol Specification November 20, 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 2 | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure U: All Templates Withdrawal Set Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 3 | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure V: All Options Templates Withdrawal Set Format Template IDs MAY be reused for new Templates by sending a new Template Record or Options Template Record for a given Template ID after withdrawing the Template. If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, without having received a withdrawal, it MUST ignore the new Template Record and discard the old Template Record for the allocated ID; it SHOULD log the error. If a Collecting Process receives a Template Withdrawal for a Template or Options Template it does not presently have stored, it MUST ignore the Template Withdrawal and SHOULD log the error. 8.2 Sequencing Template Management Actions Since there is no guarantee of the ordering of exported IPFIX Messages across SCTP Streams or over UDP, an Exporting Process MUST sequence all template management actions (i.e., Template Records defining new templates and Template Withdrawals withdrawing them) using the Export Time field in the IPFIX Message Header. An Exporting Process MUST NOT export a Data Set described by a new Template in an IPFIX Message with an Export Time before the Export Time of the IPFIX Message containing that Template. If a new Template and a Data Set described by it appear in the same IPFIX Message, the Standards Track [Page 39] Internet-Draft IPFIX Protocol Specification November 20, 2012 Template Set containing the Template MUST appear before the Data Set in the Message. An Exporting Process MUST NOT export any Data Sets described by a withdrawn Template in IPFIX Messages with an Export Time after the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing that Template. Put another way, a Template only describes Records contained in IPFIX Messages with the same Export Time as the IPFIX Message containing Template Record, or a subsequent export time. Likewise, a Template Withdrawal is only in effect for IPFIX Messages with the same Export Time as the Template Withdrawal, or a subsequent Export Time. Collecting Processes MAY implement a buffer to handle out-of-order Template management events. 8.3. Additional considerations for Template Management over SCTP Template Sets and Options Template Sets MAY be sent on any SCTP stream. Data Sets sent on a given SCTP stream MAY be represented by Template Records exported on any SCTP stream. Template Sets and Options Template Sets MUST be sent reliably and in order. Template Withdrawal Messages MAY be sent on any SCTP stream. Template Withdrawal Messages MUST be sent reliably, using SCTP-ordered delivery. Template IDs MAY be reused by sending a Template Withdrawal Message and/or a new Template Record on a different SCTP stream than the stream on which the original Template was sent. Additional Template Management considerations are given in [IPFIX- PER-SCTP-STREAM], which specifies an extension to explicitly link Templates with SCTP streams. In exchange for more restrictive rules on the assignment of Template Records to SCTP streams, this extension allows fast, reliable reuse of Template IDs and estimation of Data Record loss per Template. 8.4. Additional considerations for Template Management over UDP Since UDP provides no method for reliable transmission of Templates, Exporting Processes using UDP as the Transport Protocol MUST periodically retransmit each active Template at regular intervals. The template retransmission interval MUST be configurable, as via the the templateRefreshTimeout and optionsTemplateRefreshTimeout defined in [IPFIX-CONF]. Default settings for these values are deployment- and application-specific. Standards Track [Page 40] Internet-Draft IPFIX Protocol Specification November 20, 2012 Before exporting any Data Records described by a given Template Record or Options Template Record, especially in the case of Template ID reuse as in section 8.1, the Exporting Process SHOULD send multiple copies of the Template Record in separate IPFIX Message, in order to help ensure the Collecting Process has received it. In order to minimize resource requirements for templates which have expired at the Exporting Process without being withdrawn, or in cases when the Template Withdrawal Message was lost between the Exporting Process and the Collecting Process, the Collecting Process MAY associate a lifetime with each Template received in a UDP Transport Session. Templates not refreshed by the Exporting Process within the lifetime can then be discarded by the Collecting Process. The template lifetime at the Collecting Process MAY be exposed by a configuration parameter, or MAY be derived from observation of the interval of periodic Template retransmissions from the Exporting Process. In this latter case, the Template lifetime SHOULD default to at least 3 times the observed retransmission rate. As template IDs are unique per UDP session and per Observation Domain, at any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: . 9. The Collecting Process's Side This section describes the handling of the IPFIX Protocol at the Collecting Process common to all Transport Protocols. Additional considerations for SCTP and UDP are given in Sections 9.1 and 9.2 respectively. Template management at Collecting Processes is covered in Section 8. The Collecting Process MUST listen for association requests / connections to start new Transport Sessions from the Exporting Process. The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record. The Collecting Process MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record. The IPFIX protocol has a Sequence Number field in the Export header that increases with the number of IPFIX Data Records in the IPFIX Standards Track [Page 41] Internet-Draft IPFIX Protocol Specification November 20, 2012 Message. The Collecting Process MAY detect out-of-sequence, dropped, or duplicate IPFIX Messages using this the Sequence Number. If it [ACF - way back in the description of Sequence Number we stated. "This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed." but here it is MAY.] supports this mechanism, the Collecting Process SHOULD log out-of-sequence IPFIX Messages, as these could indicate resource [ACF - Only out-of-sequence? What about logging dropped or duplicate?] exhaustion at the Exporting Process or the Collecting Process, an Exporting Process reset, packet loss due to congestion between the Exporting Process and the Collecting Process, or message injection. If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. Note that non- zero Set padding does not constitute a malformed IPFIX Message. 9.1. Additional considerations for SCTP Collecting Processes The Exporting Process requests a number of streams to use for export at association setup time. An Exporting Process MAY request and support more than one stream per SCTP association. 9.2. Additional considerations for UDP Collecting Processes A Transport Session for IPFIX Messages transported over UDP is defined from the point of view of the Exporting Process, and roughly corresponds to the time during which a given Exporting Process sends IPFIX messages over UDP to a given Collecting Process. Since this is difficult to detect at the Collecting Process, the Collecting Process MAY expire all Transport Session state after no IPFIX Messages are received from a given Exporting Process during a configurable idle timeout. The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions) required to decode the Data Record. If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records [ACF - is this in conflict with section 8? (SHOULD vs MAY) "However, if the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received." ] (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. 10. Transport Protocol The IPFIX Protocol Specification has been designed to be transport protocol independent. Note that the Exporter can export to multiple Collecting Processes using independent transport protocols. The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 Standards Track [Page 42] Internet-Draft IPFIX Protocol Specification November 20, 2012 octets. Standards Track [Page 43] Internet-Draft IPFIX Protocol Specification November 20, 2012 10.1. Transport Compliance and Transport Usage SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations. SCTP SHOULD be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability. TCP MAY be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation. UDP MAY be used, although it is not a congestion-aware protocol. However, in this case the IPFIX traffic between Exporter and Collector MUST be separately contained or provisioned to minimize the risk of congestion-related loss. 10.2. SCTP This section describes how IPFIX is transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension. 10.2.1. Congestion Avoidance The SCTP transport protocol provides the required level of congestion avoidance by design. SCTP will detect congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limit the transfer rate accordingly. When an IPFIX Exporting Process has records to export, but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of [ACF - SHOULD it also be reported to the collector or just accounted for internally. See templates above.] dropped export data can be reported. 10.2.2. Reliability The SCTP transport protocol is by default reliable, but has the capability to deliver messages with partial reliability [RFC3758]. Using reliable SCTP messages for the IPFIX export is not in itself a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Standards Track [Page 44] Internet-Draft IPFIX Protocol Specification November 20, 2012 Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up; the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded the IPFIX Sequence Numbers used for export MUST reflect the loss of data. 10.2.3. MTU SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery. 10.2.4. Association Establishment and Shutdown The IPFIX Exporting Process SHOULD initiate an SCTP association with the IPFIX Collecting Process. By default, the Collecting Process listens for connections on SCTP port 4739. By default, the Collecting Process listens for secure connections on SCTP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different SCTP port. The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process. An Exporting Process MAY support more than one active association to different Collecting Processes (including the case of different Collecting Processes on the same host). When an Exporting Process is shut down, it SHOULD shut down the SCTP association. When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association. When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment. When an Exporting Process detects that the SCTP association to the Collecting Process is abnormally terminated, it SHOULD try to re-establish the association. Association timeouts SHOULD be configurable. Standards Track [Page 45] Internet-Draft IPFIX Protocol Specification November 20, 2012 10.2.5. Failover If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish an association, the Exporting Process should retry using the SCTP exponential backoff feature. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, configurable on the Exporter. If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance. 10.2.6. Streams An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets. Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup. An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as per Section 4 of the PR-SCTP [RFC3758] specification when using partial reliability to transmit IPFIX Messages containing only Data Sets. However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow. 10.3. UDP This section describes how IPFIX is transported over UDP [UDP]. 10.3.1. Congestion Avoidance UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., links that are over-provisioned compared to the maximum export rate from the Exporters. 10.3.2. Reliability UDP is not a reliable transport protocol, and cannot guarantee delivery of messages. IPFIX Messages sent from the Exporting Process Standards Track [Page 46] Internet-Draft IPFIX Protocol Specification November 20, 2012 to the Collecting Process using UDP may therefore be lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages. The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be re-sent at regular intervals, in case previous copies were lost. Exporting Processes exporting IPFIX Messages via UDP MUST include a valid UDP checksum. 10.3.3. MTU The maximum size of exported messages MUST be configured such that the total packet size does not exceed the path MTU. If the path MTU is unknown, a maximum packet size of 512 octets SHOULD be used. 10.3.4. Session Establishment and Shutdown By default, the Collecting Process listens on the UDP port 4739. By default, the Collecting Process listens for secure connections on UDP port 4740 (refer to the "Security Considerations" section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different UDP port. As UDP is a connectionless protocol, there is no real session establishment or shutdown for IPFIX over UDP. An Exporting Process starts sending IPFIX Messages to a Collecting Process at one point in time, and stops sending them at another point in time. This leads to some complications in template management, which are outlined in Section 8.4 above. 10.3.5. Failover and Session Duplication Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes. Standards Track [Page 47] Internet-Draft IPFIX Protocol Specification November 20, 2012 10.4. TCP The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter. 10.4.1. Congestion Avoidance TCP controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that takes into account both congestion in the network and the capabilities of the receiver. Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates it, either because of congestion in the network or because the Collecting Process cannot handle IPFIX Messages fast enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. But such buffering is necessarily limited, both because of resource limitations and because of timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked. When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid blocking, it can decide to drop some Data Records. The dropped Data Records MUST be accounted for, so that the number of lost records can later be exported as in Section 4.3. When an Exporting Process finds that the rate at which records should be exported is consistently higher than the rate at which TCP sending permits, it SHOULD provide back pressure to the Metering Processes. The Metering Process could then adapt by temporarily reducing the amount of data it generates, for example, using sampling or aggregation. Standards Track [Page 48] Internet-Draft IPFIX Protocol Specification November 20, 2012 10.4.2. Reliability TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process. In the case of TCP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent from this TCP connection, from the current Observation Domain by the Exporting Process, prior to the receipt of this IPFIX Message, modulo 2^32. 10.4.3. MTU As TCP offers a stream service instead of a datagram or sequential packet service, IPFIX Messages transported over TCP are instead separated using the Length field in the IPFIX Message Header. The Exporting Process can choose any valid length for exported IPFIX Messages, as TCP handles segmentation. However, if an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line blocking between different Observation Domains. 10.4.4. Connection Establishment, Shutdown, and Restart The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter. When an Exporting Process is shut down, it SHOULD shut down the TCP connection. [ACF - Throughout the documente there seems to be about 50/50 usage of "shutdown" vs "shut down". I believe all should be shutdown.] When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process Standards Track [Page 49] Internet-Draft IPFIX Protocol Specification November 20, 2012 has closed its end. When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection. When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute. 10.4.5. Failover If the Collecting Process does not acknowledge the attempt by the [ACF - IMO "an attempt" instead of "the attempt"] Exporting Process to establish a connection, it will retry using the [ACF - "will retry" or "MUST retry"?] TCP exponential backoff feature. If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance. 11. Security Considerations The security considerations for the IPFIX protocol have been derived from an analysis of potential security threats, as discussed in the "Security Considerations" section of IPFIX requirements [RFC3917]. The requirements for IPFIX security are as follows: 1. IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent disclosure of Flow Records transported via IPFIX. 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent the injection of incorrect data or control information (e.g., Templates) into an IPFIX Message stream. 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process. Because IPFIX can be used to collect information for network forensics and billing purposes, attacks designed to confuse, disable, or take information from an IPFIX collection system may be seen as a Standards Track [Page 50] Internet-Draft IPFIX Protocol Specification November 20, 2012 prime objective during a sophisticated network attack. An attacker in a position to inject false messages into an IPFIX Message stream can either affect the application using IPFIX (by falsifying data), or the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options); for this reason, IPFIX Message integrity is important. The IPFIX Messages themselves may also contain information of value to an attacker, including information about the configuration of the network as well as end-user traffic and payload data, so care must be taken to confine their visibility to authorized users. When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data. 11.1. Applicability of TLS and DTLS Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC4347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys. With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is selected as the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. Note that DTLS is selected as the security mechanism for SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require all communication to be over reliable, bidirectional streams, and require one TLS connection per stream. This arrangement is not compatible with the rationale behind the choice of SCTP as an IPFIX transport protocol. Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man in the middle may attempt to take data out of an association and fool the sender into thinking that the data was actually received by the peer. In generic TLS for SCTP (and/or TCP), this is not possible. This means that the removal of a message may become hidden from the sender or receiver. Another vulnerability of using SCTP with DTLS is that someone could inject SCTP control information to shut down the SCTP association, effectively generating a loss of IPFIX Messages if Standards Track [Page 51] Internet-Draft IPFIX Protocol Specification November 20, 2012 those are buffered outside of the SCTP association. Techniques such as [RFC6083] could be used to overcome these vulnerabilities. When using DTLS over SCTP, the Exporting Process MUST ensure that each IPFIX Message is sent over the same SCTP stream that would be used when sending the same IPFIX Message directly over SCTP. Note that DTLS may send its own control messages on stream 0 with full reliability; however, this will not interfere with the processing of stream 0 IPFIX Messages at the Collecting Process, because DTLS consumes its own control messages before passing IPFIX Messages up to the application layer. When using DTLS over SCTP or UDP, the Heartbeat Extention [RFC6520] SHOULD be used, especially on long-lived Transport Sessions, to ensure that the association remains active. 11.2. Usage The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process, and acts as a TLS or DTLS client according to [RFC5246] and [RFC4347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on the SCTP port 4740 of the DTLS server if SCTP is selected as the transport protocol. The TLS client opens a secure connection on the TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on the UDP port 4740 of the DTLS server if UDP is selected as the transport protocol. 11.3. Authentication IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC5280]. To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints. Standards Track [Page 52] Internet-Draft IPFIX Protocol Specification November 20, 2012 The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension is given preference. Internationalized domain names (IDN) in either the subjectAltName extension of type dNSName or the most specific Common Name field of the Subject field of the X.509 certificate MUST be encoded using Punycode [RFC3492] as described in [RFC5891], "Conversion Operations". 11.4. Protection against DoS Attacks An attacker may mount a denial-of-service (DoS) attack against an [ACF - "DoS" defined after first use and then never used again. DoS is widely known so I'm not sure it matters.] IPFIX collection system either directly, by sending large amounts of traffic to a Collecting Process, or indirectly, by generating large amounts of traffic to be measured by a Metering Process. Direct denial-of-service attacks can also involve state exhaustion, whether at the transport layer (e.g., by creating a large number of pending connections), or within the IPFIX Collecting Process itself (e.g., by sending Flow Records pending Template or scope information, a large amount of Options Template Records, etc.). SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion denial-of-service attacks. Similarly, TCP provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be used by any Collecting Process accepting TCP connections. DTLS also provides cookie exchange to protect against DTLS server state exhaustion. The reader should note that there is no way to prevent fake IPFIX Message processing (and state creation) for UDP & SCTP communication. The use of TLS and DTLS can obviously prevent the creation of fake states, but they are themselves prone to state exhaustion attacks. Therefore, Collector rate limiting SHOULD be used to protect TLS & DTLS (like limiting the number of new TLS or DTLS session per second to a sensible number). IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations will be opened by the Collecting Process, the rate at which IPFIX Messages will be accepted by the Collecting Process, and adaptively limiting the amount of state kept, particularly records waiting on Templates. These rate and state limits MAY be provided by a Collecting Process; if provided, the limits SHOULD be user configurable. Standards Track [Page 53] Internet-Draft IPFIX Protocol Specification November 20, 2012 Additionally, an IPFIX Collecting Process can eliminate the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication, causing the Collecting Process to accept IPFIX Messages only from trusted sources. With respect to indirect denial of service, the behavior of IPFIX [ACF - "denial of service" should be "denial-of-service". Or at least that is how it is used in the rest of the document] under overload conditions depends on the transport protocol in use. For IPFIX over TCP, TCP congestion control would cause the flow of IPFIX Messages to back off and eventually stall, blinding the IPFIX system. SCTP improves upon this situation somewhat, as some IPFIX Messages would continue to be received by the Collecting Process due to the avoidance of head-of-line blocking by SCTP's multiple streams and partial reliability features, possibly affording some visibility of the attack. The situation is similar with UDP, as some datagrams may continue to be received at the Collecting Process, effectively applying sampling to the IPFIX Message stream, implying that some forensics may be left. To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link. Alternatively, IPFIX Messages can be transported over a dedicated network. In this case, care must be taken to ensure that the dedicated network can handle the expected peak IPFIX Message traffic. 11.5. When DTLS or TLS Is Not an Option The use of DTLS or TLS might not be possible in some cases due to performance issues or other operational concerns. Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, and using ingress filtering to prevent spoofing, can improve the usefulness of this approach. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further. In any case, the use of open Collecting Processes (those that will accept IPFIX Messages from any Exporting Process regardless of IP address or identity) is discouraged. Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC1948], [RFC4960]); however, UDP offers no such protection. For this reason, IPFIX Message traffic transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network. Standards Track [Page 54] Internet-Draft IPFIX Protocol Specification November 20, 2012 11.6. Logging an IPFIX Attack IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number, and SHOULD provide a logging mechanism for reporting out-of-sequence messages. Note that an attacker may be able to exploit the handling of out-of-sequence messages at the Collecting Process, so care should be taken in handling these conditions. For example, a Collecting Process that simply resets the expected Sequence Number upon receipt of a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers. IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure, whether due to being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or due to a connection attempt from an unauthorized IP address when TLS or DTLS is not in use. IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset. 11.7. Securing the Collector The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document. 12. IANA Considerations IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message. [ACF - What about Information Elements? What about PEN for vendor IEs?] The IPFIX Version Number value of 10 is reserved for the IPFIX [ACF - nit. earlier this value was given as 0x000a. Should both locations use the same format or maybe list both (eg 0x000a (10))] protocol specified in this document. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Options Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets. New assignments in either IPFIX Version Number or IPFIX Set ID assignments require a Standards Action [RFC5226], i.e., they are to be made via Standards Track RFCs approved by the IESG. Standards Track [Page 55] Internet-Draft IPFIX Protocol Specification November 20, 2012 Appendix A. IPFIX Encoding Examples This appendix, which is a not a normative reference, contains IPFIX encoding examples. Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set and a Data Set (which contains 2 Data Records related to the previous Options Template Record). IPFIX Message: +--------+------------------------------------------. . . | | +--------------+ +------------------+ |Message | | Template | | Data | | Header | | Set | | Set | . . . | | | (1 Template) | | (3 Data Records) | | | +--------------+ +------------------+ +--------+------------------------------------------. . . . . .-------------------------------------------+ +------------------+ +------------------+ | | Options | | Data | | . . . | Template Set | | Set | | | (1 Template) | | (2 Data Records) | | +------------------+ +------------------+ | . . .-------------------------------------------+ A.1. Message Header Example The Message Header is composed of: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 0x000a | Length = 152 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Standards Track [Page 56] Internet-Draft IPFIX Protocol Specification November 20, 2012 A.2. Template Set Examples A.2.1. Template Set Using IETF-Specified Information Elements We want to report the following Information Elements: - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with a length of 4 octets - The IPv4 destination IP address: destinationIPv4Address in [RFC5102bis], with a length of 4 octets - The next-hop IP address (IPv4): ipNextHopIPv4Address in [RFC5102bis], with a length of 4 octets - The number of packets of the Flow: packetDeltaCount in [RFC5102bis], with a length of 4 octets - The number of octets of the Flow: octetDeltaCount in [RFC5102bis], with a length of 4 octets Therefore, the Template Set will be composed of the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 28 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipNextHopIPv4Address = 15 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 2 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount = 1 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.2.2. Template Set Using Enterprise-Specific Information Elements We want to report the following Information Elements: - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with a length of 4 octets Standards Track [Page 57] Internet-Draft IPFIX Protocol Specification November 20, 2012 - The IPv4 destination IP address: destinationIPv4Address in [RFC5102bis], with a length of 4 octets - An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4 - The number of packets of the Flow: packetDeltaCount in [RFC5102bis], with a length of 4 octets - The number of octets of the Flow: octetDeltaCount in [RFC5102bis], with a length of 4 octets Therefore, the Template Set will be composed of the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 32 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element Id. = 15| Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 2 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount = 1 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Standards Track [Page 58] Internet-Draft IPFIX Protocol Specification November 20, 2012 A.3. Data Set Example In this example, we report the following three Flow Records: Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets | | | Number | Number ------------------------------------------------------------------ 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 256 | Length = 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5009 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5344385 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 748 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 388934 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.56 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.65 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6534 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that padding is not necessary in this example. Standards Track [Page 59] Internet-Draft IPFIX Protocol Specification November 20, 2012 A.4. Options Template Set Examples A.4.1. Options Template Set Using IETF-Specified Information Elements Per line card (the router being composed of two line cards), we want to report the following Information Elements: - Total number of IPFIX Messages: exportedMessageTotalCount [RFC5102bis], with a length of 2 octets - Total number of exported Flows: exportedFlowRecordTotalCount [RFC5102bis], with a length of 2 octets The line card, which is represented by the lineCardId Information Element [RFC5102bis], is used as the Scope Field. Therefore, the Options Template Set will be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 258 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| lineCardId = 141 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4.2. Options Template Set Using Enterprise-Specific Information Elements Per line card (the router being composed of two line cards), we want to report the following Information Elements: - Total number of IPFIX Messages: exportedMessageTotalCount [RFC5102bis], with a length of 2 octets - An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets The line card, which is represented by the lineCardId Information Standards Track [Page 60] Internet-Draft IPFIX Protocol Specification November 20, 2012 Element [RFC5102bis], is used as the Scope Field. The format of the Options Template Set is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 259 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| lineCardId = 141 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |1|Information Element Id. = 42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | Enterprise number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Enterprise number | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4.3. Options Template Set Using an Enterprise-Specific Scope In this example, we want to export the same information as in the example in Section A.4.1: - Total number of IPFIX Messages: exportedMessageTotalCount [RFC5102bis], with a length of 2 octets - Total number of exported Flows: exportedFlowRecordTotalCount [RFC5102bis], with a length of 2 octets But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123. Standards Track [Page 61] Internet-Draft IPFIX Protocol Specification November 20, 2012 The format of the Options Template Set is now as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 260 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 | Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Enterprise Number |0|exportedMessageTotalCount=41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4.4. Data Set Using an Enterprise-Specific Scope In this example, we report the following two Data Records: Enterprise field 123 | IPFIX Message | Exported Flow Records ------------------------------------------------------------------- 1 | 345 | 10201 2 | 690 | 20402 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 260 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 345 | 10201 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 690 | 20402 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Standards Track [Page 62] Internet-Draft IPFIX Protocol Specification November 20, 2012 A.5. Variable-Length Information Element Examples A.5.1. Example of Variable-Length Information Element with Length Inferior to 255 Octets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 5 octet Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.5.2. Example of Variable-Length Information Element with 3 Octet Length Encoding 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | 1000 | IE ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1000 octet Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. Standards Track [Page 63] Internet-Draft IPFIX Protocol Specification November 20, 2012 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S. Boeyen, S. Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, April 2008. [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010 [RFC5891] J. Klensin, "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", draft-claise-ipfix-information-model- rfc5102bis-01.txt, Work in Progress, October 2011. Informative References [PEN] IANA Private Enterprise Numbers registry http://www.iana.org/assignments/enterprise-numbers. Standards Track [Page 64] Internet-Draft IPFIX Protocol Specification November 20, 2012 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008. [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC5153, April 2008 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC5470, March 2009. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC5472, March 2009. [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC5471, March 2009 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC5473, March 2009 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, Standards Track [Page 65] Internet-Draft IPFIX Protocol Specification November 20, 2012 "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", July 2009. [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC6083, January 2011. [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC6313, July 2011. [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC6183, April 2011. [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information Technology - Portable Operating System Interface, IEEE, 2008. [IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for IPFIX and PSAMP", draft-ietf-ipfix- configuration-model-10, Work in Progress, July 2011. [IPFIX-PER-SCTP-STREAM] Claise, B., Aitekn, P., Johnson, A. and G. [ACF - Aitken, P. (perhaps?)] Muenz, "IPFIX Export per SCTP Stream", draft-ietf- ipfix-export-per-sctp-stream-08, Work in Progress, May 2010. [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Specification of the Protocol for IPFIX Mediations", draft-claise-ipfix-mediation-protocol-04, Work in Progress, July 2011. [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", draft-dkcm-ipfix-rfc5815bis- 00.txt, Work in Progress, October 2011. Acknowledgments We would like to thank the following persons: Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification; Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and Standards Track [Page 66] Internet-Draft IPFIX Protocol Specification November 20, 2012 Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical reviews and feedback. Authors' Addresses Benoit Claise (Ed.) Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com Brian Trammell (Ed.) Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 EMail: trammell@tik.ee.ethz.ch Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom Phone: +44 (0)20 8824-8828 EMail: stbryant@cisco.com Standards Track [Page 67] Internet-Draft IPFIX Protocol Specification November 20, 2012 Simon Leinen SWITCH Werdstrasse 2 P.O. Box 8021 Zurich Switzerland Phone: +41 44 268 1536 EMail: simon.leinen@switch.ch Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 EMail: Thomas.Dietz@nw.neclab.eu Standards Track [Page 68] --------------090808060209040709000201-- From andrewf@plixer.com Tue Dec 4 10:22:58 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 CEEA321F8C9C for ; Tue, 4 Dec 2012 10:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599] 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 qDBIz83AJnhU for ; Tue, 4 Dec 2012 10:22:58 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 19EEA21F8BFD for ; Tue, 4 Dec 2012 10:22:58 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 13:22:57 -0500 Message-ID: <50BE3F81.1050105@plixer.com> Date: Tue, 04 Dec 2012 13:22:57 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20.0 Thunderbird/20.0a1 MIME-Version: 1.0 To: ATSUSHI KOBAYASHI , IPFIX Working Group References: <20121125175952.D64A.C996B02F@orange.plala.or.jp> <20121125224113.262B.C996B02F@orange.plala.or.jp> In-Reply-To: <20121125224113.262B.C996B02F@orange.plala.or.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2012 18:22:57.0546 (UTC) FILETIME=[627F26A0:01CDD24C] Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-03 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, 04 Dec 2012 18:22:58 -0000 Hi All, Atsushi, On 11/25/2012 08:41 AM, ATSUSHI KOBAYASHI wrote: > Dear all, Nevil, > > I checked the draft, I found some comments and editorial issue. > Please see in-line. > > Regards, Atsushi [ snip ] > Comment#3: > > I could not understand the following paragraph. If you want to describe > another way, please explain it in more detail. I think Atsushi makes a good point here. >> Put another way, a Template only describes Records contained in IPFIX >> Messages with the same Export Time as the IPFIX Message containing >> Template Record, or a subsequent export time. Likewise, a Template >> Withdrawal is only in effect for IPFIX Messages with the same Export >> Time as the Template Withdrawal, or a subsequent Export Time. Perhaps something like... Put another way, a Template only describes Data Records contained in IPFIX Messages with the an Export Time greater than or equal to the Export Time of the IPFIX Message containing Template Record. Or until a Template Withdrawal is received. Likewise, a Template Withdrawal is only in effect for IPFIX Messages with the an Export Time greater than or equal to the Export Time of the IPFIX Message containing Template Withdrawal. Or until a new Template with the withdrawn Template ID is received. -Andrew From andrewf@plixer.com Tue Dec 4 10:53: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 6FD8E21F8CC8 for ; Tue, 4 Dec 2012 10:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599] 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 mV-7g-o8NI2G for ; Tue, 4 Dec 2012 10:52:59 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82F21F8CC4 for ; Tue, 4 Dec 2012 10:52:59 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 13:52:58 -0500 Message-ID: <50BE468A.6000603@plixer.com> Date: Tue, 04 Dec 2012 13:52:58 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20.0 Thunderbird/20.0a1 MIME-Version: 1.0 To: Brian Trammell References: <20121119191834.9520.597.idtracker@ietfa.amsl.com> In-Reply-To: <20121119191834.9520.597.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------000605050609070001050804" X-OriginalArrivalTime: 04 Dec 2012 18:52:58.0874 (UTC) FILETIME=[942BFDA0:01CDD250] Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-08.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: Tue, 04 Dec 2012 18:53:00 -0000 This is a multi-part message in MIME format. --------------000605050609070001050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Brian, all, I figured I might as well continue reading documents heading for the RFC-EDITOR :-/. Attached diffs from my super fast skim through the document. All minor. -Andrew On 11/19/2012 02:18 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol > Author(s) : Brian Trammell > Arno Wagner > Benoit Claise > Filename : draft-ietf-ipfix-a9n-08.txt > Pages : 57 > Date : 2012-11-19 > > 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-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-a9n-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------000605050609070001050804 Content-Type: text/plain; charset=UTF-8; name="a9n-08.diffs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a9n-08.diffs" *** draft-ietf-ipfix-a9n-08.txt 2012-12-04 13:45:53.936750314 -0500 --- draft-ietf-ipfix-a9n-08.acf 2012-12-04 13:42:15.926759008 -0500 *************** *** 482,488 **** Note that an Intermediate Aggregation Process which removes potentially sensitive information as identified in [RFC6235] may tend ! to have an anonymising effect on the Aggregated Flows as well; however, any application of aggregation as part of a data protection scheme should ensure that all the issues raised in [RFC6235] are addressed, specifically Section 4 "Anonymization of IP Flow Data", --- 482,488 ---- Note that an Intermediate Aggregation Process which removes potentially sensitive information as identified in [RFC6235] may tend ! to have an anonymizing effect on the Aggregated Flows as well; however, any application of aggregation as part of a data protection scheme should ensure that all the issues raised in [RFC6235] are addressed, specifically Section 4 "Anonymization of IP Flow Data", *************** *** 1309,1315 **** | src asn | dst asn | +---------+---------+ ! Aggregated Flow Keys (by source and dest ASN) Figure 8: Illustration of key aggregation by reduction and replacement --- 1309,1315 ---- | src asn | dst asn | +---------+---------+ ! Aggregated Flow Keys (by source and destination ASN) Figure 8: Illustration of key aggregation by reduction and replacement *************** *** 1377,1384 **** an effect on how meaningful either the conservative or non- conservative flow count will be during aggregation. In general, Original Exporters using the IPFIX Configuration Model SHOULD be ! configured to export Flows with equal or similar activeTimeout and ! inactiveTimeout configuration values, and the same cacheMode, as defined in [I-D.ietf-ipfix-configuration-model]. Original Exporters not using the IPFIX Configuration Model SHOULD be configured equivalently. --- 1377,1384 ---- an effect on how meaningful either the conservative or non- conservative flow count will be during aggregation. In general, Original Exporters using the IPFIX Configuration Model SHOULD be ! configured to export Flows with equal or similar flowActiveTimeout and ! flowIdleTimeout configuration values, and the same cacheMode, as defined in [I-D.ietf-ipfix-configuration-model]. Original Exporters not using the IPFIX Configuration Model SHOULD be configured equivalently. *************** *** 1658,1664 **** Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCount ElementId: TBD1 --- 1658,1664 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCounter ElementId: TBD1 *************** *** 1681,1687 **** Internet-Draft IPFIX Aggregation November 2012 ! Data Type Semantics: deltaCount ElementId: TBD2 --- 1681,1687 ---- Internet-Draft IPFIX Aggregation November 2012 ! Data Type Semantics: deltaCounter ElementId: TBD2 *************** *** 1693,1699 **** Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCount ElementId: TBD3 --- 1693,1699 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCounter ElementId: TBD3 *************** *** 1705,1711 **** Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCount ElementId: 3 --- 1705,1711 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: deltaCounter ElementId: 3 *************** *** 1725,1731 **** Abstract Data Type: unsigned64 ! Data Type Semantics: totalCount --- 1725,1731 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: totalCounter *************** *** 1749,1755 **** Abstract Data Type: unsigned64 ! Data Type Semantics: totalCount ElementId: TBD5 --- 1749,1755 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: totalCounter ElementId: TBD5 *************** *** 1760,1766 **** Abstract Data Type: unsigned32 ! Data Type Semantics: totalCount ElementId: TBD6 --- 1760,1766 ---- Abstract Data Type: unsigned32 ! Data Type Semantics: totalCounter ElementId: TBD6 *************** *** 1771,1777 **** Abstract Data Type: unsigned32 ! Data Type Semantics: totalCount ElementId: TBD7 --- 1771,1777 ---- Abstract Data Type: unsigned32 ! Data Type Semantics: totalCounter ElementId: TBD7 *************** *** 1795,1801 **** Abstract Data Type: unsigned64 ! Data Type Semantics: totalCount ElementId: TBD8 --- 1795,1801 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: totalCounter ElementId: TBD8 *************** *** 1808,1814 **** Abstract Data Type: unsigned64 ! Data Type Semantics: totalCount ElementId: TBD9 --- 1808,1814 ---- Abstract Data Type: unsigned64 ! Data Type Semantics: totalCounter ElementId: TBD9 --------------000605050609070001050804-- From paitken@cisco.com Tue Dec 4 12:11: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 0B4BD21F8CAC for ; Tue, 4 Dec 2012 12:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiyzGtJNyS+Q for ; Tue, 4 Dec 2012 12:11:53 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0621F8CBF for ; Tue, 4 Dec 2012 12:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1354651913; x=1355861513; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PBCFl1ftkY2X5jAgeNyF89nI4cvI6gxbl6lj+vfD0RA=; b=ktaQZMxVoEUqu7D2/GeJ5lLnf1lOGgzPoEgQ9dvGCXDzArsR6H9xmpZZ Z26FxlF3VkJJzRxMcMzuBROwjUWC39yffu7p6g2RNir1PgqDeUTNyRk7e 2DWZYhQ/mjVS5POfjyN/VqW6lUJUG6LvvZnqeNd+Op3acJMhJ5RqM4WQA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAJBXvlCQ/khR/2dsb2JhbABEg0e6aBZzgh4BAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAYgMDLAYkFMEjDeEQQOSUIMzhWuKXIJy X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="10144877" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 04 Dec 2012 20:11:50 +0000 Received: from [10.61.86.176] (ams3-vpn-dhcp5809.cisco.com [10.61.86.176]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB4KBnnW002415; Tue, 4 Dec 2012 20:11:50 GMT Message-ID: <50BE5905.4040504@cisco.com> Date: Tue, 04 Dec 2012 20:11:49 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Feren References: <20121125175952.D64A.C996B02F@orange.plala.or.jp> <20121125224113.262B.C996B02F@orange.plala.or.jp> <50BE3F81.1050105@plixer.com> In-Reply-To: <50BE3F81.1050105@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-03 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, 04 Dec 2012 20:11:54 -0000 Andrew, all, There's a loophole in both definitions: if a collector receives data records with export time = T2, then a Template with export time = T1 (where T1 <= T2), the Template applies to the previously-received data records. This could be due to UDP out of order, or delivery in different SCTP streams. However when the collector receives data records at T1 it doesn't know that a template is coming at T2, so its behaviour is unclear, especially if it already has a template for those data records. That could be an earlier template which no longer applies. So the definition might benefit from some words about reception order. P. On 04/12/12 18:22, Andrew Feren wrote: > Hi All, Atsushi, > > On 11/25/2012 08:41 AM, ATSUSHI KOBAYASHI wrote: >> Dear all, Nevil, >> >> I checked the draft, I found some comments and editorial issue. >> Please see in-line. >> >> Regards, Atsushi > [ snip ] >> Comment#3: >> >> I could not understand the following paragraph. If you want to describe >> another way, please explain it in more detail. > I think Atsushi makes a good point here. >>> Put another way, a Template only describes Records contained in >>> IPFIX >>> Messages with the same Export Time as the IPFIX Message containing >>> Template Record, or a subsequent export time. Likewise, a Template >>> Withdrawal is only in effect for IPFIX Messages with the same >>> Export >>> Time as the Template Withdrawal, or a subsequent Export Time. > Perhaps something like... > > Put another way, a Template only describes Data Records contained > in IPFIX Messages with the an Export Time greater than or equal to > the Export Time of the IPFIX Message containing Template Record. > Or until a Template Withdrawal is received. Likewise, a Template > Withdrawal is only in effect for IPFIX Messages with the an Export > Time greater than or equal to the Export Time of the IPFIX Message > containing Template Withdrawal. Or until a new Template with the > withdrawn Template ID is received. > > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Dec 5 02:59:38 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 99E4D21F872C for ; Wed, 5 Dec 2012 02:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSXSS5R6LVr1 for ; Wed, 5 Dec 2012 02:59:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF1921F8509 for ; Wed, 5 Dec 2012 02:59:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5C4ADD9321; Wed, 5 Dec 2012 11:59:33 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mTKrtlpDz-Gx; Wed, 5 Dec 2012 11:59:33 +0100 (MET) Received: from [192.168.1.10] (unknown [80.48.104.216]) (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 E9948D9310; Wed, 5 Dec 2012 11:59:32 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50BE5905.4040504@cisco.com> Date: Wed, 5 Dec 2012 11:59:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121125175952.D64A.C996B02F@orange.plala.or.jp> <20121125224113.262B.C996B02F@orange.plala.or.jp> <50BE3F81.1050105@plixer.com> <50BE5905.4040504@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-03 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, 05 Dec 2012 10:59:38 -0000 hi, Paul, Andrew, all, Agreed, though it is not clear to me how to really account for time at = receiver here. Actually, I think this makes more sense to explain in = terms of "template lifetime" as opposed to "time of effect of a template = or withdrawal"... How about the following? NEW: Put another way, a Template describes Data Records contained in IPFIX = Messages with an Export Time between the Export Time of the IPFIX Message = containing the Template Record and the end of the Transport Session, inclusive, if = that Template is not subsequently withdrawn. If a Template is subsequently withdrawn, then that Template describes = Data Records contained in IPFIX Messages with an Export Time between the = Export Time of the IPFIX Message containing the Template Record and the Export = Time of the IPFIX Message containing the Template Withdrawal, inclusive. Stepping back further, the real issue here is that you can only have two = of the following three things: (1) template identifier reuse, (2) template transmission without reliable ordering (i.e., templates in = multiple SCTP streams, or UDP as a transport protocol), (3) verifiably correct interpretation of data records. I strongly suspect this is why we have seen no interest in five years of = interoperability testing in (1), and interest in (2) only because IPFIX = is envisioned for deployment to replace UDP transport of older versions = of NetFlow, where the network is either provisioned to minimize loss, or = the processes around the collection and processing of the data have been = adjusted to the fact that UDP is simply not reliable. And it looks we fell into the trap again, just like we did in 2007 with = 5101, of trying to pretend this is a fixable problem. So I think in = addition we probably need a warning label on template reuse -- even if = you follow all these rules, a stream of IPFIX messages compliant with = the protocol may come out the other side of the network in an order = which makes it difficult to determine what the exporter meant, so = practically speaking reuse needs various knobs that admins can tune to = determine timing delays for reuse, and those admins need to be = conservative when tweaking them, or tolerant of lost or corrupted data. = I'd replace the final paragraph of section 8.2 with an actual warning; = something like: NEW: Note that, even if sent in-order, IPFIX Messages containing Template management actions could arrive at the Collecting Process = out-of-order, i.e. if sent via UDP or via different SCTP streams. Template = Withdrawals and subsequent reuse of Template IDs, in particular, can = significantly complicate the problem of determining Template lifetimes at the = Collecting Process. Therefore, Collecting Processes MAY implement a buffer to = handle out-of-order Template management events; this buffer, if = implemented, SHOULD be configurable to impart a delay on the order of the maximum reordering delay experienced at the Collecting Process. This, I think, handles the reception order problem, as well. Thoughts? Best regards, Brian On 4 Dec 2012, at 21:11, Paul Aitken wrote: > Andrew, all, >=20 > There's a loophole in both definitions: if a collector receives data = records with export time =3D T2, then a Template with export time =3D T1 = (where T1 <=3D T2), the Template applies to the previously-received data = records. This could be due to UDP out of order, or delivery in different = SCTP streams. >=20 > However when the collector receives data records at T1 it doesn't know = that a template is coming at T2, so its behaviour is unclear, especially = if it already has a template for those data records. That could be an = earlier template which no longer applies. >=20 > So the definition might benefit from some words about reception order. >=20 > P. >=20 >=20 >=20 > On 04/12/12 18:22, Andrew Feren wrote: >> Hi All, Atsushi, >>=20 >> On 11/25/2012 08:41 AM, ATSUSHI KOBAYASHI wrote: >>> Dear all, Nevil, >>>=20 >>> I checked the draft, I found some comments and editorial issue. >>> Please see in-line. >>>=20 >>> Regards, Atsushi >> [ snip ] >>> Comment#3: >>>=20 >>> I could not understand the following paragraph. If you want to = describe >>> another way, please explain it in more detail. >> I think Atsushi makes a good point here. >>>> Put another way, a Template only describes Records contained in = IPFIX >>>> Messages with the same Export Time as the IPFIX Message = containing >>>> Template Record, or a subsequent export time. Likewise, a = Template >>>> Withdrawal is only in effect for IPFIX Messages with the same = Export >>>> Time as the Template Withdrawal, or a subsequent Export Time. >> Perhaps something like... >>=20 >> Put another way, a Template only describes Data Records contained >> in IPFIX Messages with the an Export Time greater than or equal to >> the Export Time of the IPFIX Message containing Template Record. >> Or until a Template Withdrawal is received. Likewise, a Template >> Withdrawal is only in effect for IPFIX Messages with the an Export >> Time greater than or equal to the Export Time of the IPFIX Message >> containing Template Withdrawal. Or until a new Template with the >> withdrawn Template ID is received. >>=20 >> -Andrew >> _______________________________________________ >> 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 From trammell@tik.ee.ethz.ch Wed Dec 5 03:30: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 ED8D321F8973 for ; Wed, 5 Dec 2012 03:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+Q-mW5JA177 for ; Wed, 5 Dec 2012 03:30:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC7121F896F for ; Wed, 5 Dec 2012 03:30:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 840AFD9321; Wed, 5 Dec 2012 12:30:50 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1EEwxBuAdsT4; Wed, 5 Dec 2012 12:30:49 +0100 (MET) Received: from [192.168.1.10] (unknown [80.48.104.216]) (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 EFAFED94A1; Wed, 5 Dec 2012 12:30:48 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50BE468A.6000603@plixer.com> Date: Wed, 5 Dec 2012 12:31:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EDD4446-9F99-479D-8414-E97A0C06E4AF@tik.ee.ethz.ch> References: <20121119191834.9520.597.idtracker@ietfa.amsl.com> <50BE468A.6000603@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1499) Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-08.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, 05 Dec 2012 11:30:55 -0000 Hi, Andrew, The semantics typos were already corrected by IANA; the others are all = editorial, so I'll correct them during AUTH48. Thanks! Cheers, Brian On 4 Dec 2012, at 19:52, Andrew Feren wrote: > Hi Brian, all, >=20 > I figured I might as well continue reading documents heading for the = RFC-EDITOR :-/. Attached diffs from my super fast skim through the = document. All minor. >=20 > -Andrew >=20 >=20 > On 11/19/2012 02:18 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >>=20 >> Title : Flow Aggregation for the IP Flow Information = Export (IPFIX) Protocol >> Author(s) : Brian Trammell >> Arno Wagner >> Benoit Claise >> Filename : draft-ietf-ipfix-a9n-08.txt >> Pages : 57 >> Date : 2012-11-19 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-a9n-08 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > From bclaise@cisco.com Wed Dec 5 15:20: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 B84D121F8BEB for ; Wed, 5 Dec 2012 15:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 h6-2KVEQGLOW for ; Wed, 5 Dec 2012 15:20:54 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BA89D21F8AC1 for ; Wed, 5 Dec 2012 15:20:53 -0800 (PST) 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 qB5NCe2Q012909 for ; Thu, 6 Dec 2012 00:12:40 +0100 (CET) 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 qB5NCc5b005653 for ; Thu, 6 Dec 2012 00:12:38 +0100 (CET) Message-ID: <50BFD4E6.9040000@cisco.com> Date: Thu, 06 Dec 2012 00:12:38 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <201212052247.qB5Mli1D009765@sjc-wwpl-cpol2.cisco.com> In-Reply-To: <201212052247.qB5Mli1D009765@sjc-wwpl-cpol2.cisco.com> X-Forwarded-Message-Id: <201212052247.qB5Mli1D009765@sjc-wwpl-cpol2.cisco.com> Content-Type: multipart/mixed; boundary="------------060502060107070109090802" Subject: [IPFIX] Fwd: IPR Statement RE: draft-ietf-ipfix-protocol-rfc5101bis-03 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, 05 Dec 2012 23:20:54 -0000 This is a multi-part message in MIME format. --------------060502060107070109090802 Content-Type: multipart/alternative; boundary="------------010802030005080809090902" --------------010802030005080809090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, As I mentioned at the mic. during the last IETF ... So it should not be a surprise. The WG lunch during the last IETF was about IPRs. I asked the question about the applicability of IPRs for bis RFCs. I received the advice to declare the IPR on the bis RFC, just to be sure. So here it is. Note the same terms as the IPR on RFC 5101. Regards, Benoit (as a contributor) -------- Original Message -------- Subject: IPR Statement RE: draft-ietf-ipfix-protocol-rfc5101bis-03 Date: Wed, 5 Dec 2012 14:47:44 -0800 From: Rachel Albright Reply-To: ralbrigh@cisco.com To: ietf-ipr@ietf.org CC: bclaise@cisco.com, stbryant@cisco.com Cisco is the owner of US Patent Nos. 6,243,667, 6,308,148, 6,889,181, 6,590,894, 7,475,156, and 7,260,518 relating to the subject matter of "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information" . If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. The reasonable non-discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. Royalty-bearing licenses will be available to anyone who prefers that option. For information contact: Dan Lang Vice President and Deputy General Counsel Cisco Systems, Inc. +1 408-526-6672 standards-ipr@cisco.com --------------010802030005080809090902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

As I mentioned at the mic. during the last IETF ... So it should not be a surprise.
The WG lunch during the last IETF was about IPRs. I asked the question about the applicability of IPRs for bis RFCs.
I received the advice to declare the IPR on the bis RFC, just to be sure. So here it is.
Note the same terms as the IPR on RFC 5101.

Regards, Benoit (as a contributor)



-------- Original Message --------
Subject: IPR Statement RE: draft-ietf-ipfix-protocol-rfc5101bis-03
Date: Wed, 5 Dec 2012 14:47:44 -0800
From: Rachel Albright<ralbrigh@cisco.com>
Reply-To: ralbrigh@cisco.com
To: ietf-ipr@ietf.org
CC: bclaise@cisco.com, stbryant@cisco.com 


Cisco is the owner of US Patent Nos. 6,243,667, 6,308,148, 6,889,181, 6,590,894, 7,475,156, and 7,260,518 relating to the subject matter of "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information" <draft-ietf-ipfix-protocol-rfc5101bis-03>. 
 
If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard.
 
The reasonable non-discriminatory terms are:
 
If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard.
 
Royalty-bearing licenses will be available to anyone who prefers that option.

For information contact:
 
Dan Lang
Vice President and Deputy General Counsel 
Cisco Systems, Inc.
+1 408-526-6672
standards-ipr@cisco.com



--------------010802030005080809090902-- --------------060502060107070109090802 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------060502060107070109090802-- From ietf-ipr@ietf.org Thu Dec 6 09:50:47 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 6A49D21F880D; Thu, 6 Dec 2012 09:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 kdCDMULpmw-K; Thu, 6 Dec 2012 09:50:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6031C21F866F; Thu, 6 Dec 2012 09:50:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bclaise@cisco.com, trammell@tik.ee.ethz.ch X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206175046.21472.15639.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 09:50:46 -0800 Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, ipr-announce@ietf.org Subject: [IPFIX] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ipfix-protocol-rfc5101bis-03 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, 06 Dec 2012 17:50:47 -0000 Dear Benoit Claise, Brian Trammell: An IPR disclosure that pertains to your Internet-Draft entitled "Specifica= tion of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information" (draft-ietf-ipfix-protocol-rfc5101bis) was submitted to the IE= TF Secretariat on 2012-12-05 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1927/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-ip= fix- protocol-rfc5101bis-03.""); The IETF Secretariat From andrewf@plixer.com Fri Dec 7 09:10:02 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 1206E21F8A7C for ; Fri, 7 Dec 2012 09:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599] 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 UFuzJ5ynDI0r for ; Fri, 7 Dec 2012 09:10:01 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFFA21F865B for ; Fri, 7 Dec 2012 09:10:01 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 12:10:00 -0500 Message-ID: <50C222E8.1050201@plixer.com> Date: Fri, 07 Dec 2012 12:10:00 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: Paul Aitken References: <50BDE60A.9090503@cisco.com> In-Reply-To: <50BDE60A.9090503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2012 17:10:00.0527 (UTC) FILETIME=[B0D44DF0:01CDD49D] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 3550 jitter 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, 07 Dec 2012 17:10:02 -0000 Hi Paul, all, I've been giving this a bit of thought. I think your suggestion to use Extended Field Specifiers is absolutely the direction that we need to head in. I'm pretty sure jitter won't be the only IE that would benefit from some additional detail. For example it would be fantastic if IEs (any IEs, but particularly Enterprise specific IEs) came with type and semantic information. Currently I can decode new IEs, but then have to discard them as useless until I get additional information out of band. Being able to have users send new IEs and immediately be able to create useful reports would be great. I suspect that this opens up a number of other possibilities that I haven't considered yet. -Andrew PS in addition to jitter, something for latency would probably be useful. On 12/04/2012 07:01 AM, Paul Aitken wrote: > Andrew, > > This is a great point. It was also raised privately (off list) by one > other responder. > > Cisco already has a large number of jitter metrics which we export in > enterprise-specific fields. RFC 3550 jitter was the only one we > thought standardisable. I expect others have similar ES fields for > their own jitter metrics. > > One solution would be to use the same mechanism that I proposed for > MIB export, ie Extended Field Specifiers. > > ie, we'd have a single export ID for "jitter", to which an extension > can be applied indicating which jitter it is, which implies how it's > calculated. > > See slide 7 here: > http://tools.ietf.org/agenda/85/slides/slides-85-ipfix-2.pdf > > P. > >> Is it necessary to have an IE each possible jitter calculation and the >> document where that calculation is defined? Seems like we could end up >> with a huge pile of jitter IEs. Are there other calculated values that >> have need to specify how they were calculated? PSAMP has >> selectorAlgorithm etc., applicationId has an embedded Classification >> Engine ID, do we need some sort of calculationTypeId for calculated >> values >> like jitter? >> >> -Andrew >> >> On 11/28/12 12:30 PM, "Paul Aitken" wrote: >> >>> Dear all, >>> >>> I received feedback that the name should include "mean" and 'rfc3550', >>> since there are other jitter metrics which take into account all >>> samples >>> rather than running average based last 16 samples as done by RFC3550. >>> >>> So the proposed names could be rfc3550JitterMeanMilliseconds, >>> rfc3550JitterMeanMicroseconds, and rfc3550JitterMeanNanoseconds. >>> >>> P. >>> >>> >>> On 28/11/12 15:25, Paul Aitken wrote: >>>> Dear IPFIX experts, >>>> >>>> I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines >>>> a suitable "interarrival jitter". Unfortunately it's measured in >>>> "timestamp units": >>>> >>>> An estimate of the statistical variance of the RTP data packet >>>> interarrival time, measured in timestamp units and expressed >>>> as an >>>> unsigned integer. >>>> >>>> >>>> Therefore it seems we may need multiple IEs: one for units of >>>> milliseconds, one for microseconds, one for nanoseconds... >>>> Else comparison of two jitter values would be meaningless. >>>> >>>> So I request your feedback on the following: >>>> >>>> Name: interarrivalJitterMilliseconds >>>> Type: unsigned32 >>>> Semantic: quantity >>>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>>> 3550, measured in milliseconds. >>>> Units: milliseconds >>>> References: [RFC3550] >>>> >>>> Name: interarrivalJitterMicroseconds >>>> Type: unsigned32 >>>> Semantic: quantity >>>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>>> 3550, measured in microseconds. >>>> Units: microseconds >>>> References: [RFC3550] >>>> >>>> Name: interarrivalJitterNanoseconds >>>> Type: unsigned32 >>>> Semantic: quantity >>>> Description: interarrival jitter as defined in section 6.4.1 of RFC >>>> 3550, measured in nanoseconds. >>>> Units: nanoseconds >>>> References: [RFC3550] >>>> >>>> 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 > From andrewf@plixer.com Fri Dec 7 09:31: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 B857721F87B2 for ; Fri, 7 Dec 2012 09:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] 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 YNK9IcgVDiVO for ; Fri, 7 Dec 2012 09:31:16 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1321F8701 for ; Fri, 7 Dec 2012 09:31:15 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 12:31:15 -0500 Message-ID: <50C227E3.4090908@plixer.com> Date: Fri, 07 Dec 2012 12:31:15 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070806010808010606090509" X-OriginalArrivalTime: 07 Dec 2012 17:31:15.0403 (UTC) FILETIME=[A8B6F1B0:01CDD4A0] Subject: [IPFIX] exporterIPv4Address and exporterIPv6Address question 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, 07 Dec 2012 17:31:16 -0000 This is a multi-part message in MIME format. --------------070806010808010606090509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, So I wanted to recommend the following IEs to someone, but then I wasn't sure if their usage quite fit with the description. 130 exporterIPv4Address ipv4Address identifier current The IPv4 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy. 131 exporterIPv6Address ipv6Address identifier current The IPv6 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy. The short question is does the "exporter" in question necessarily have to be exporting IPFIX originally (or for that matter even be exporting)? What if I poll a bunch of SNMP and export that information as IPFIX to a collector? The polled devices are not necessarily exporters, but this seems to be the most appropriate IE. I don't see a situation where this would cause a problem, but maybe I am missing something. SNMP is just one example. Could be any source other than IPFIX. sFlow to PSAMP gateway, information gathered with WMI, etc. If this usage makes sense can we maybe add some text to the description? If not is there a better IE or should I propose one? Thanks, -Andrew --------------070806010808010606090509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

So I wanted to recommend the following IEs to someone, but then I wasn't sure if their usage quite fit with the description.
130 exporterIPv4Address ipv4Address identifier current

The IPv4 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy.
131 exporterIPv6Address ipv6Address identifier current

The IPv6 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy.

The short question is does the "exporter" in question necessarily have to be exporting IPFIX originally (or for that matter even be exporting)?

What if I poll a bunch of SNMP and export that information as IPFIX to a collector?  The polled devices are not necessarily exporters, but this seems to be the most appropriate IE.  I don't see a situation where this would cause a problem, but maybe I am missing something.

SNMP is just one example.  Could be any source other than IPFIX.  sFlow to PSAMP gateway, information gathered with WMI, etc.

If this usage makes sense can we maybe add some text to the description?

If not is there a better IE or should I propose one?

Thanks,
-Andrew
--------------070806010808010606090509-- From andrewf@plixer.com Fri Dec 7 10:11: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 B963B21F8997 for ; Fri, 7 Dec 2012 10:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] 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 Sy40Jekhmv97 for ; Fri, 7 Dec 2012 10:11:25 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29021F8806 for ; Fri, 7 Dec 2012 10:11:25 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 13:11:24 -0500 Message-ID: <50C2314C.20300@plixer.com> Date: Fri, 07 Dec 2012 13:11:24 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2012 18:11:24.0616 (UTC) FILETIME=[44B7AC80:01CDD4A6] Subject: [IPFIX] unobserved fields 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, 07 Dec 2012 18:11:25 -0000 Hi all, My earlier email about Extended Field Specifiers reminded me of an other draft (draft-aitken-ipfix-unobserved-fields) that doesn't seem to have gone anywhere, but that I would love to move forward. Having a standard way to know if field is unobserved/NULL for a given flow would be very valuable. Any other interest? -Andrew From paitken@cisco.com Fri Dec 7 11:01: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 8D30321F854D for ; Fri, 7 Dec 2012 11:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5qagQ5mCSBB for ; Fri, 7 Dec 2012 11:01:46 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6223421F8538 for ; Fri, 7 Dec 2012 11:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1051; q=dns/txt; s=iport; t=1354906904; x=1356116504; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mTGA1UoRv7HCp9oP3DbDNqG9/uYSsmSAnwplDn2rFxo=; b=MrFTPrBPCZaQ9gy0QzJ8UZGBfDogYHafd2nKtdDf3r2AliBawdO5Qw9W 5Z76zpM4gnbwpC5WMKyIISaRm6tOwY2UlXOJsTnrsE8lYan+6l0F/mi90 Z9ahM2C2W6EPVTQh2f5dfWQd1jXJxXXKk7p3DnunwidQl2sIWsg1pH7RB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcHAGs8wlCQ/khR/2dsb2JhbABEg0e6cxZzgh4BAQEDAThAAQULCyEWDwkDAgECAUUGDQEHAQGIBwbCJoxKhDgDlgWFa4pdgnOBbQ X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="78900660" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2012 19:01:43 +0000 Received: from [10.61.88.204] (ams3-vpn-dhcp6349.cisco.com [10.61.88.204]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7J1gRw008134; Fri, 7 Dec 2012 19:01:42 GMT Message-ID: <50C23D17.3030503@cisco.com> Date: Fri, 07 Dec 2012 19:01:43 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Feren References: <50C2314C.20300@plixer.com> In-Reply-To: <50C2314C.20300@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] unobserved fields 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, 07 Dec 2012 19:01:46 -0000 Andrew, > My earlier email about Extended Field Specifiers reminded me of an > other draft (draft-aitken-ipfix-unobserved-fields) that doesn't seem > to have gone anywhere, but that I would love to move forward. Having a > standard way to know if field is unobserved/NULL for a given flow > would be very valuable. It's not that this draft didn't go anywhere. Rather, I've written all I can for now, yet the WG isn't in a position to adopt the work. However it's a real issue that needs to be solved -in fact, we're already using some of the techniques in this document - so in my mind it's only "on hold" until I think of something to add and/or the WG can adopt it. You're right, Extended Field Specifiers would allow us to tag each field with an "Observed" attribute with advantages: - we wouldn't need to change fields to varlen just to report length = 0. - we could have a many-valued reason rather than a boolean. ie, we can report why the value is not available or not applicable. P. From paitken@cisco.com Fri Dec 7 11:19:19 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 33D4E21F8AE3 for ; Fri, 7 Dec 2012 11:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, 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 CTKRValKIJ-K for ; Fri, 7 Dec 2012 11:19:18 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C29D921F8ADF for ; Fri, 7 Dec 2012 11:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9021; q=dns/txt; s=iport; t=1354907957; x=1356117557; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OAJS62+mwy0XVfF1//4+VQsVFPfVRu/eMvTpTBjhx14=; b=Zg4pL9XkYEXSWbyV9pK/bzmuaZmQYiuMCoDKjQjpYPu3U+l12N8W9qFD LVBPYLJihxNuX4kSAyZxbb0w/Nejie3tNGeJMgtQdbXZHT6l2wuxgn+p6 JWbnUOt9B5V/48rwDImRe1GgZcD3r7+xSrfSj5oH0Vsizk8fvzmAWAv3Z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkHABRAwlCQ/khR/2dsb2JhbAA6AQmCSX66dxZzgh4BAQEDAQEBAWsKAQULCyEWDwkDAgECARUwBg0BAwICAQGIBwYMwhIEgkiKCAGEMQOWBYVril2Ccz8 X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="10238903" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 07 Dec 2012 19:19:16 +0000 Received: from [10.61.88.204] (ams3-vpn-dhcp6349.cisco.com [10.61.88.204]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7JJG3o011075; Fri, 7 Dec 2012 19:19:16 GMT Message-ID: <50C24135.4030406@cisco.com> Date: Fri, 07 Dec 2012 19:19:17 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Feren References: <50C227E3.4090908@plixer.com> In-Reply-To: <50C227E3.4090908@plixer.com> Content-Type: multipart/alternative; boundary="------------030704020500080708040807" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] exporterIPv4Address and exporterIPv6Address question 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, 07 Dec 2012 19:19:19 -0000 This is a multi-part message in MIME format. --------------030704020500080708040807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, > So I wanted to recommend the following IEs to someone, but then I > wasn't sure if their usage quite fit with the description. > 130 exporterIPv4Address ipv4Address identifier current > > The IPv4 address used by the Exporting Process. This is used by the > Collector to identify the Exporter in cases where the identity of the > Exporter may have been obscured by the use of a proxy. > > 131 exporterIPv6Address ipv6Address identifier current > > The IPv6 address used by the Exporting Process. This is used by the > Collector to identify the Exporter in cases where the identity of the > Exporter may have been obscured by the use of a proxy. > > > The short question is does the "exporter" in question necessarily have > to be exporting IPFIX originally (or for that matter even be exporting)? Well these are IPFIX Information Elements in the IPFIX Information Model... If the other context adopts the IPFIX infomodel, then I don't see why not. > What if I poll a bunch of SNMP and export that information as IPFIX to > a collector? The polled devices are not necessarily exporters, but > this seems to be the most appropriate IE. I don't see a situation > where this would cause a problem, but maybe I am missing something. In this case it seems that you'd want to report the addresses of the polled devices, ie the source(s) of the SNMP information, rather than the exporter's address. Anyway the exporter's address will be visible to the collector (unless it's NAT'd). So perhaps "sourceIPv4Address" would be appropriate? And we need to improve the definition for cases where packets aren't being observed, eg the exporting device is sending reports or alarms, or is being SNMP polled. P. > SNMP is just one example. Could be any source other than IPFIX. > sFlow to PSAMP gateway, information gathered with WMI, etc. > > If this usage makes sense can we maybe add some text to the description? > > If not is there a better IE or should I propose one? > > Thanks, > -Andrew > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------030704020500080708040807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

So I wanted to recommend the following IEs to someone, but then I wasn't sure if their usage quite fit with the description.
130 exporterIPv4Address ipv4Address identifier current

The IPv4 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy.
131 exporterIPv6Address ipv6Address identifier current

The IPv6 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy.

The short question is does the "exporter" in question necessarily have to be exporting IPFIX originally (or for that matter even be exporting)?

Well these are IPFIX Information Elements in the IPFIX Information Model... If the other context adopts the IPFIX infomodel, then I don't see why not.


What if I poll a bunch of SNMP and export that information as IPFIX to a collector?  The polled devices are not necessarily exporters, but this seems to be the most appropriate IE.  I don't see a situation where this would cause a problem, but maybe I am missing something.

In this case it seems that you'd want to report the addresses of the polled devices, ie the source(s) of the SNMP information, rather than the exporter's address. Anyway the exporter's address will be visible to the collector (unless it's NAT'd).

So perhaps "sourceIPv4Address" would be appropriate? And we need to improve the definition for cases where packets aren't being observed, eg the exporting device is sending reports or alarms, or is being SNMP polled.

P.


SNMP is just one example.  Could be any source other than IPFIX.  sFlow to PSAMP gateway, information gathered with WMI, etc.

If this usage makes sense can we maybe add some text to the description?

If not is there a better IE or should I propose one?

Thanks,
-Andrew


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

--------------030704020500080708040807-- From andrewf@plixer.com Fri Dec 7 11:49: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 DCEF921F88D9 for ; Fri, 7 Dec 2012 11:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0IxEevWIKUoB for ; Fri, 7 Dec 2012 11:49:33 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9921F88A1 for ; Fri, 7 Dec 2012 11:49:33 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 14:49:31 -0500 Message-ID: <50C2484A.3090608@plixer.com> Date: Fri, 07 Dec 2012 14:49:30 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: Paul Aitken References: <50C227E3.4090908@plixer.com> <50C24135.4030406@cisco.com> In-Reply-To: <50C24135.4030406@cisco.com> Content-Type: multipart/alternative; boundary="------------040204060503080002030304" X-OriginalArrivalTime: 07 Dec 2012 19:49:31.0142 (UTC) FILETIME=[F95C4260:01CDD4B3] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [QUAR] Re: exporterIPv4Address and exporterIPv6Address question 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, 07 Dec 2012 19:49:34 -0000 This is a multi-part message in MIME format. --------------040204060503080002030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, On 12/07/2012 02:19 PM, Paul Aitken wrote: > Andrew, [ snip ] >> What if I poll a bunch of SNMP and export that information as IPFIX >> to a collector? The polled devices are not necessarily exporters, >> but this seems to be the most appropriate IE. I don't see a >> situation where this would cause a problem, but maybe I am missing >> something. > > In this case it seems that you'd want to report the addresses of the > polled devices, ie the source(s) of the SNMP information, rather than > the exporter's address. Anyway the exporter's address will be visible > to the collector (unless it's NAT'd). > > So perhaps "sourceIPv4Address" would be appropriate? And we need to > improve the definition for cases where packets aren't being observed, > eg the exporting device is sending reports or alarms, or is being SNMP > polled. OK, what about this hypothetical example. Firewall reports via SNMP firewall events, and the IP address(es) involved. An agent polls that device to send this information (via IPFIX) to a collector for reporting. My original thinking was that you might send exporterIPv4Address, sourceIPv4Address, destinationIPv4Address, firewallEvent This seems equivalent to what you would get if (instead of polling) my hypothetical agent was a proxy for the same information being sent via IPFIX from my hypothetical device. Using sourceIPv4Address in place of exporterIPv4Address doesn't seem like the right choice here. -Andrew --------------040204060503080002030304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul,

On 12/07/2012 02:19 PM, Paul Aitken wrote:
Andrew,

[ snip ]
What if I poll a bunch of SNMP and export that information as IPFIX to a collector?  The polled devices are not necessarily exporters, but this seems to be the most appropriate IE.  I don't see a situation where this would cause a problem, but maybe I am missing something.

In this case it seems that you'd want to report the addresses of the polled devices, ie the source(s) of the SNMP information, rather than the exporter's address. Anyway the exporter's address will be visible to the collector (unless it's NAT'd).

So perhaps "sourceIPv4Address" would be appropriate? And we need to improve the definition for cases where packets aren't being observed, eg the exporting device is sending reports or alarms, or is being SNMP polled.

OK, what about this hypothetical example.

Firewall reports via SNMP  firewall events, and the IP address(es) involved.

An agent polls that device to send this information (via IPFIX) to a collector for reporting.

My original thinking was that you might send

exporterIPv4Address, sourceIPv4Address, destinationIPv4Address, firewallEvent

This seems equivalent to what you would get if (instead of polling) my hypothetical agent was a proxy for the same information being sent via IPFIX from my hypothetical device.

Using sourceIPv4Address in place of exporterIPv4Address doesn't seem like the right choice here.

-Andrew

--------------040204060503080002030304-- From j.schoenwaelder@jacobs-university.de Fri Dec 7 12: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 ECA3421F898B for ; Fri, 7 Dec 2012 12:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 fWWmxtEEBxLk for ; Fri, 7 Dec 2012 12:44:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB221F8980 for ; Fri, 7 Dec 2012 12:44:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E71320C24; Fri, 7 Dec 2012 21:44:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2ikWmHd5v1_B; Fri, 7 Dec 2012 21:44:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4464320C11; Fri, 7 Dec 2012 21:44:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6F6EE23529AA; Fri, 7 Dec 2012 21:45:01 +0100 (CET) Date: Fri, 7 Dec 2012 21:45:00 +0100 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20121207204500.GA43443@elstar.local> Mail-Followup-To: Paul Aitken , Andrew Feren , IETF IPFIX Working Group References: <50C227E3.4090908@plixer.com> <50C24135.4030406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C24135.4030406@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] exporterIPv4Address and exporterIPv6Address question X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:44:56 -0000 On Fri, Dec 07, 2012 at 07:19:17PM +0000, Paul Aitken wrote: > > In this case it seems that you'd want to report the addresses of the > polled devices, ie the source(s) of the SNMP information, rather > than the exporter's address. Anyway the exporter's address will be > visible to the collector (unless it's NAT'd). > According to SNMP's architectural model, data is scoped by the agent's snmpEngineID. Transport address may be plentiful and change more or less arbitrarily. Yes, I know that many manager implementations still do prefer dealing with IP addresses - but architecturally, the snmpEngineID is the correct application layer identifier for an SNMP agent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andrewf@plixer.com Fri Dec 7 14:10: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 D20EB21F8BBC for ; Fri, 7 Dec 2012 14:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7GzgnsKkOCSx for ; Fri, 7 Dec 2012 14:10:53 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 12D8521F8BBA for ; Fri, 7 Dec 2012 14:10:52 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 17:10:52 -0500 Message-ID: <50C2696C.9040606@plixer.com> Date: Fri, 07 Dec 2012 17:10:52 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070603090301080201080308" X-OriginalArrivalTime: 07 Dec 2012 22:10:52.0597 (UTC) FILETIME=[B8B39650:01CDD4C7] Subject: [IPFIX] latency reporting 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, 07 Dec 2012 22:10:53 -0000 This is a multi-part message in MIME format. --------------070603090301080201080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've been doing some review and clean up of my local IE database and I see around a dozen IEs related to latency and RTT from various exporters/vendors. This seems like a measurement that could use a standard IE for reporting. Here are my thoughts so far... Name: latencyMilliseconds Type: unsigned32 Semantic: quantity Description: latency measured in milliseconds. Units: milliseconds Name: roundTripTimeMilliseconds Type: unsigned32 Semantic: quantity Description: Round trip time measured in milliseconds. Units: milliseconds Perhaps the above needs to be fleshed out with some Extended Field Specifiers as has been discussed recently for jitter. On a related note an IE that I am not seeing from most of the exporters sending latency information, but which can be useful when diagnosing problems is out of order packet information. Name: outOfOrderPacketDeltaCount Type: unsigned64 Semantic: deltaCounter Description: The number of out of order packets since the previous report (if any) for this Flow at the Observation Point. Units: packets Name: outOfOrderPacketTotalCount Type: unsigned64 Semantic: totalCounter Description: The total number of out of order packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. Units: packets -Andrew --------------070603090301080201080308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I've been doing some review and clean up of my local IE database and I see around a dozen IEs related to latency and RTT from various exporters/vendors.  This seems like a measurement that could use a standard IE for reporting.  Here are my thoughts so far...

Name: latencyMilliseconds
Type: unsigned32
Semantic: quantity
Description: latency measured in milliseconds.
Units: milliseconds

Name: roundTripTimeMilliseconds
Type: unsigned32
Semantic: quantity
Description: Round trip time measured in milliseconds.
Units: milliseconds

Perhaps the above needs to be fleshed out with some Extended Field Specifiers as has been discussed recently for jitter.

On a related note an IE that I am not seeing from most of the exporters sending latency information, but which can be useful when diagnosing problems is out of order packet information.

Name: outOfOrderPacketDeltaCount
Type: unsigned64
Semantic: deltaCounter
Description: The number of out of order packets since the previous report (if any) for this Flow at the Observation Point.
Units: packets

Name: outOfOrderPacketTotalCount
Type: unsigned64
Semantic: totalCounter
Description: The total number of out of order packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
Units: packets

-Andrew
--------------070603090301080201080308-- From andrewf@plixer.com Fri Dec 7 14:54:27 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 17CAB21F8BC5 for ; Fri, 7 Dec 2012 14:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] 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 U5YfeR8KR0Nv for ; Fri, 7 Dec 2012 14:54:26 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 6234621F86DC for ; Fri, 7 Dec 2012 14:54:20 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 17:54:19 -0500 Message-ID: <50C2739B.90705@plixer.com> Date: Fri, 07 Dec 2012 17:54:19 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: Brian Trammell , Paul Aitken References: <20121125175952.D64A.C996B02F@orange.plala.or.jp> <20121125224113.262B.C996B02F@orange.plala.or.jp> <50BE3F81.1050105@plixer.com> <50BE5905.4040504@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2012 22:54:19.0820 (UTC) FILETIME=[CABA3EC0:01CDD4CD] Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-03 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, 07 Dec 2012 22:54:27 -0000 Hi Brian, all, That all makes sense. I particularly like the addition of a disclaimer. -Andrew On 12/05/2012 05:59 AM, Brian Trammell wrote: > hi, Paul, Andrew, all, > > Agreed, though it is not clear to me how to really account for time at receiver here. Actually, I think this makes more sense to explain in terms of "template lifetime" as opposed to "time of effect of a template or withdrawal"... How about the following? > > NEW: > > Put another way, a Template describes Data Records contained in IPFIX Messages > with an Export Time between the Export Time of the IPFIX Message containing the > Template Record and the end of the Transport Session, inclusive, if that > Template is not subsequently withdrawn. > > If a Template is subsequently withdrawn, then that Template describes Data > Records contained in IPFIX Messages with an Export Time between the Export Time > of the IPFIX Message containing the Template Record and the Export Time of the > IPFIX Message containing the Template Withdrawal, inclusive. > > Stepping back further, the real issue here is that you can only have two of the following three things: > > (1) template identifier reuse, > > (2) template transmission without reliable ordering (i.e., templates in multiple SCTP streams, or UDP as a transport protocol), > > (3) verifiably correct interpretation of data records. > > I strongly suspect this is why we have seen no interest in five years of interoperability testing in (1), and interest in (2) only because IPFIX is envisioned for deployment to replace UDP transport of older versions of NetFlow, where the network is either provisioned to minimize loss, or the processes around the collection and processing of the data have been adjusted to the fact that UDP is simply not reliable. > > And it looks we fell into the trap again, just like we did in 2007 with 5101, of trying to pretend this is a fixable problem. So I think in addition we probably need a warning label on template reuse -- even if you follow all these rules, a stream of IPFIX messages compliant with the protocol may come out the other side of the network in an order which makes it difficult to determine what the exporter meant, so practically speaking reuse needs various knobs that admins can tune to determine timing delays for reuse, and those admins need to be conservative when tweaking them, or tolerant of lost or corrupted data. I'd replace the final paragraph of section 8.2 with an actual warning; something like: > > NEW: > > Note that, even if sent in-order, IPFIX Messages containing Template > management actions could arrive at the Collecting Process out-of-order, > i.e. if sent via UDP or via different SCTP streams. Template Withdrawals > and subsequent reuse of Template IDs, in particular, can significantly > complicate the problem of determining Template lifetimes at the Collecting > Process. Therefore, Collecting Processes MAY implement a buffer to handle > out-of-order Template management events; this buffer, if implemented, > SHOULD be configurable to impart a delay on the order of the maximum > reordering delay experienced at the Collecting Process. > > This, I think, handles the reception order problem, as well. > > Thoughts? > > Best regards, > > Brian > > On 4 Dec 2012, at 21:11, Paul Aitken wrote: > >> Andrew, all, >> >> There's a loophole in both definitions: if a collector receives data records with export time = T2, then a Template with export time = T1 (where T1 <= T2), the Template applies to the previously-received data records. This could be due to UDP out of order, or delivery in different SCTP streams. >> >> However when the collector receives data records at T1 it doesn't know that a template is coming at T2, so its behaviour is unclear, especially if it already has a template for those data records. That could be an earlier template which no longer applies. >> >> So the definition might benefit from some words about reception order. >> >> P. >> >> >> >> On 04/12/12 18:22, Andrew Feren wrote: >>> Hi All, Atsushi, >>> >>> On 11/25/2012 08:41 AM, ATSUSHI KOBAYASHI wrote: >>>> Dear all, Nevil, >>>> >>>> I checked the draft, I found some comments and editorial issue. >>>> Please see in-line. >>>> >>>> Regards, Atsushi >>> [ snip ] >>>> Comment#3: >>>> >>>> I could not understand the following paragraph. If you want to describe >>>> another way, please explain it in more detail. >>> I think Atsushi makes a good point here. >>>>> Put another way, a Template only describes Records contained in IPFIX >>>>> Messages with the same Export Time as the IPFIX Message containing >>>>> Template Record, or a subsequent export time. Likewise, a Template >>>>> Withdrawal is only in effect for IPFIX Messages with the same Export >>>>> Time as the Template Withdrawal, or a subsequent Export Time. >>> Perhaps something like... >>> >>> Put another way, a Template only describes Data Records contained >>> in IPFIX Messages with the an Export Time greater than or equal to >>> the Export Time of the IPFIX Message containing Template Record. >>> Or until a Template Withdrawal is received. Likewise, a Template >>> Withdrawal is only in effect for IPFIX Messages with the an Export >>> Time greater than or equal to the Export Time of the IPFIX Message >>> containing Template Withdrawal. Or until a new Template with the >>> withdrawn Template ID is received. >>> >>> -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 trammell@tik.ee.ethz.ch Sat Dec 8 06:59:58 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 A8C5021F895B for ; Sat, 8 Dec 2012 06:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ie10jHG0R20 for ; Sat, 8 Dec 2012 06:59:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17621F895F for ; Sat, 8 Dec 2012 06:59:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6A461D9308; Sat, 8 Dec 2012 15:59:49 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IhT2JE7T12CE; Sat, 8 Dec 2012 15:59:49 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 0E568D9307; Sat, 8 Dec 2012 15:59:49 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <558AD82C-3885-4F98-8392-D44CD347CC98@cisco.com> Date: Sat, 8 Dec 2012 15:59:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87CCFC35-FEDC-46AC-8CFB-67010AEA611E@tik.ee.ethz.ch> References: <50AEF1D1.9010809@auckland.ac.nz> <50AF38DC.3090709@cisco.com> <50B61BFF.2060500@cisco.com> <558AD82C-3885-4F98-8392-D44CD347CC98@cisco.com> To: Andrew Johnson X-Mailer: Apple Mail (2.1283) Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.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: Sat, 08 Dec 2012 14:59:58 -0000 Hi, Andrew, all, (copying the list; as this conversation probably belongs there...) replies inline... On Dec 8, 2012, at 12:39 AM, Andrew Johnson wrote: > On 6 Dec 2012, at 21:03, Brian Trammell = wrote: >> On Dec 6, 2012, at 6:02 PM, Andrew Johnson wrote: >>=20 >>> Hi Brian >>>=20 >>> I'm working my way through the changes to RFC5101. For the most = part I like the clarifications and tweaks that have been made, but I = have a few niggles that hopefully you can straighten out for me. Sorry = for suddenly get involved at WGLC, but I'm pretty sure my comments are = minor, I'm just missing some of the background to why these things = changed. >>=20 >> The more review, and the more comments, the better, and "during WGLC" = is still on time, so thanks! >>=20 >>> 1. Will new collectors fail to recognise RFC5101 compliant Metering = Process >>> reports because of the new scope field? Should the new field be a = SHOULD >>> so that collecting processes have to treat it as optional? = (Alternatively, >>> "For exporting processes that are only dealing with a single = Metering >>> Process, the meteringProcessId scope fields MAY be omitted"?) >>>=20 >>> If this sort of thing is allowed because it's clear that the old = style >>> is RFC5101 and the new style is RFCXXXX, then I'm fine with the = change. >>=20 >> Hm. I'd submit that any collector that didn't allow for additional = fields in a "recognized template" was probably not very well designed, = but we don't say that anywhere in the documents. It's clear to me = because the specific reporting requirements are exporter-only, and the = collectors should be designed in such a way to handle anything an = exporter might reasonably throw at them. But maybe we could add some = text in these sections to say that these are the minimal IEs; exporters = may add other appropriate IEs to these templates as desired. Pre = 5101-bis collectors that required exactly those fields (in exactly that = order), though, would be out of luck. Personally, I don't find this = problematic, but that's just a matter of opinion on my part. >=20 > I don't have a problem with it either, as long is acceptable when = updating 5101. I also agree that collectors should be prepared to = accept additional elements in the reports, although I'd always thought = it would be additional non-scope extensions providing different stats, = rather than additional scope elements changing the specificity of where = the stats apply to. >=20 I'll suggest (this is a note to self, more than anything) adding a = sentence to each of these templates on this point, and default = assumptions to be made at collectors when new scope elements are added. >>> 2. The new text for the timestamps seems to prohibit interpreting a = rolled >>> over timestamp accurately. i.e. in 2036 dateTimeMicroseconds and >>> dateTimeNanoseconds become useless. NTP seems to be able to cope = just >>> fine with the rollover, and it seems pretty short sighted of us to >>> design a protocol that won't last another 25 years. >>=20 >> Hm. This depends on the assumptions you make. >=20 > The definition says "It can represent dates beginning between 1 = January 1900 and 8 February 2036". It doesn't say anything about = worrying about the era. True; it's precently implicitly an Era 0 date. >=20 >> In NTPv4, there's an "era" concept, which explicitly handles 64-bit = NTP wraparound. We should probably change these definitions to = incorporate this concept, stating that the era is implicit, and that = near era boundaries, the collector should make a presumption that eras = tend to be the current era, where current is defined by the current time = at the collector. >=20 > Agreed, the era idea needs to be included in the definition. In my = code I make the assumption that the times are in the past (or very near = future in case of clock skews). Usually it'll be pretty obvious but we = need to point out that it's possible. Adding implicit eras to the NTP types makes them work, and indeed, we = could add implicit eras to the other timestamp types, as well, in order = to allow more flexible interpretation thereof (maybe a specific = subsection on wraparound?).=20 >> This breaks horribly for files; if you want data archiving, you need = a way to store era number for these timestamps in the file. >=20 > Don't you have any timestamps in message parts that can guide the = interpretations. Maybe you can recommend opening a new file every = hundred years or so. Ah, wasn't concerned with lifetimes (and indeed a clever collector = should be able to handle a century-long file by keeping wrap counters on = a per-record basis); was more concerned with unambiguous interpretation = of files that have been stored for years, decades, or centuries.=20 >=20 >> This only fixes the issues with NTP timestamps. dateTimeSeconds and = Export Time in the header are still only good for another 95 years or so = (which is why I would _not_ base the era determination on the Export = Time). Sometime between now and February 8, 2106, we should probably = define new timestamp types which have representation independent from = epoch, with a 64-bit value somewhere for defining the epoch. >=20 > I've pencilled it into my diary for 1st April, 2099. Are you free? We've kicked the can down the road for another century, which I think is = good enough for me. Can I get back to you in late '98? >>> 3. In section 8, when sending the withdraw all templates message, = should >>> flowset ID 2 be used to contain the withdrawal of template ID 2? >>> Similarly, when withdrawing all options templates, does the message >>> have to be sent in flowset 3? >>=20 >> That's my interpretation of 5101. >=20 > It didn't seem to be explicitly stated, although it's how I'd have = chosen to do it. If everyone would just do it they way I would, we = wouldn't even need a standards body :). So we'll make this explicit in 5101bis as well. >>> 4. In section 8.2: "Since there is no guarantee of the ordering of >>> exported IPFIX, Messages across SCTP Streams". I thought PR-SCTP >>> allowed explicit ordering using an optional Stream-Sequence field. >>> Doesn't that mean the SCTP order can be assured for templates? >>>=20 >>> What happened to the requirement to use reliable, in-order delivery? >>=20 >> There's ordering within the stream, and ordering of sending across = streams, but you can't guarantee the ordering of processing, especially = if the collector is designed to handle streams independently. >=20 > Ah! I'd missed the across streams bit. There's an RFC somewhere that = recommends against that :) >=20 >=20 >>> 5. "Collecting Processes MAY implement a buffer to handle = out-of-order >>> Template management events" >>>=20 >>> It's a bit more complicated than a buffer. If a template is >>> redefined (withdrawn and re-used), data with an old timestamp will >>> need interpreted using the old template. I'm not suggesting you >>> add all the details to the document, just pointing out that >>> implementing a "buffer" would have some challenges :) >>=20 >> Absolutely. Would you suggest a better word than "buffer" here? = (Reading it again, I can see that there might be confusion between an = "event buffer" and a uint8_t*=85 >=20 > "Collecting Processes MAY store older versions of the template for a = time in order to handle out-of-order Template management events"? Hm. it's not just the templates they'll need to store; maybe they should = buffer sets, too; again, we don't necessarily want to constrain = collector implementors to do things a certain way, we just want to make = sure they might get stuff from exporters that it will be very easy to = interpret incorrectly... Cheers, Brian= From trammell@tik.ee.ethz.ch Sat Dec 8 07:54:26 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 EDFD621F8958 for ; Sat, 8 Dec 2012 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EdSw8kBtFdgm for ; Sat, 8 Dec 2012 07:54:26 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 084B121F871F for ; Sat, 8 Dec 2012 07:54:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3E21BD9308; Sat, 8 Dec 2012 16:54:20 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hay-bxAx--m1; Sat, 8 Dec 2012 16:54:20 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 F285DD9307; Sat, 8 Dec 2012 16:54:19 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <50C2696C.9040606@plixer.com> Date: Sat, 8 Dec 2012 16:54:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DF30BA2-E4D2-4B9D-A3D6-EF980F115310@tik.ee.ethz.ch> References: <50C2696C.9040606@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1283) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] latency reporting 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: Sat, 08 Dec 2012 15:54:27 -0000 Hi, Andrew, all, I think all of these are useful (indeed, many must think so if you're = seeing them from shipping exporters). However, just as with jitter, to = some extent, you'll see different Information Elements out there because = there are different ways to calculate things, and each of these = measurement methods actually is producing a different type of data. RTT = derived from synack measurement near the initiator gives you totally = different results than synack measurement near the responder (the latter = being essentially useless). RTT derived via TWAMP is something different = entirely, as you're not measuring application latency along with network = latency, and you know you have the whole path. So we have to be careful about precise definitions if we're going to end = up with data we can properly interpret. On that point, I'm not sure I = support the idea of having a single overarching "jitter" or "latency" or = "rtt" Information Element then selecting an algorithm externally, unless = that external selection was flexible enough to handle all the algorithm, = OP-placement, passive/active measurement, and other attributes/issues. = This seems like it could be a job for extended field specifiers, but = we'd have to think about where to draw the line between "IE attribute" = and "new IE" very, very carefully here. Jitter's another beast entirely, because there's such a variety of = definitions and algorithms that you can end up with broadly incomparable = numbers; at least with RTT everyone's kind of trying to get at the same = number. Indeed, this is a problem we'll most probably be addressing the semantic = side of, in part, in the IPPM working group.=20 One further point, inline: On Dec 7, 2012, at 11:10 PM, Andrew Feren wrote: > Hi all, >=20 > I've been doing some review and clean up of my local IE database and I = see around a dozen IEs related to latency and RTT from various = exporters/vendors. This seems like a measurement that could use a = standard IE for reporting. Here are my thoughts so far... >=20 > Name: latencyMilliseconds=20 > Type: unsigned32=20 > Semantic: quantity=20 > Description: latency measured in milliseconds.=20 > Units: milliseconds=20 >=20 > Name: roundTripTimeMilliseconds=20 > Type: unsigned32=20 > Semantic: quantity=20 > Description: Round trip time measured in milliseconds.=20 > Units: milliseconds=20 >=20 > Perhaps the above needs to be fleshed out with some Extended Field = Specifiers as has been discussed recently for jitter. >=20 > On a related note an IE that I am not seeing from most of the = exporters sending latency information, but which can be useful when = diagnosing problems is out of order packet information. >=20 > Name: outOfOrderPacketDeltaCount > Type: unsigned64 > Semantic: deltaCounter=20 > Description: The number of out of order packets since the previous = report (if any) for this Flow at the Observation Point.=20 > Units: packets This doesn't suffer _as much_ from OP-sensitivity (reordering = generally/often happens due to retransmission as opposed to routers = behaving badly) but there is a problem of definition: what is an out of = order packet? As with timing issues, there are a lot of little details = you have to work out in order to get comparable numbers; those details = should be explicitly explained in the definition. Cheers, Brian > Name: outOfOrderPacketTotalCount > Type: unsigned64 > Semantic: totalCounter=20 > Description: The total number of out of order packets for this Flow at = the Observation Point since the Metering Process (re-)initialization for = this Observation Point. > Units: packets >=20 > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Sun Dec 9 01:32: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 75ABC21F85D9 for ; Sun, 9 Dec 2012 01:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8SKaa8Ty9XU for ; Sun, 9 Dec 2012 01:32:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AEFA921F84BC for ; Sun, 9 Dec 2012 01:32:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 809BDD9310; Sun, 9 Dec 2012 10:32:11 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Mz1S+5IRsdN5; Sun, 9 Dec 2012 10:32:11 +0100 (MET) Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 08D9AD930C; Sun, 9 Dec 2012 10:32:11 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50C23D17.3030503@cisco.com> Date: Sun, 9 Dec 2012 10:32:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] unobserved fields 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: Sun, 09 Dec 2012 09:32:17 -0000 Hi, Paul, Andrew, I'm not sure I understand the proposed mechanism here... Observed/unobserved is a per-field/per-record attribute, while extended = field specifiers modify IEs per-column: every instance of a given IE in = a Template is "decorated" with its extension. =20 As I understand the requirements for -unobserved-fields, we want a way = to distinguish, from an MP: "I am capable of observing this attribute, = but it was not present in the observation" versus "I am not capable of = observing this attribute". We have the second already: simply leave the = IE out of the template. And, indeed, you can also use leaving things out = of the template to signify the first: the presence of a field in some = templates from an EP/MP combination implies that it's observable, its = absence in the other implies it's not observed. FWIW, YAF does this for = those things that haven't moved behind the 6313 curtain: no reverse = elements if it's not a biflow, for instance. Given that, how would you use a per-IE specifier to signal a per-record = attribute? What am I missing? Cheers, Brian On 7 Dec 2012, at 20:01, Paul Aitken wrote: > Andrew, >=20 >> My earlier email about Extended Field Specifiers reminded me of an = other draft (draft-aitken-ipfix-unobserved-fields) that doesn't seem to = have gone anywhere, but that I would love to move forward. Having a = standard way to know if field is unobserved/NULL for a given flow would = be very valuable. >=20 > It's not that this draft didn't go anywhere. Rather, I've written all = I can for now, yet the WG isn't in a position to adopt the work. However = it's a real issue that needs to be solved -in fact, we're already using = some of the techniques in this document - so in my mind it's only "on = hold" until I think of something to add and/or the WG can adopt it. >=20 > You're right, Extended Field Specifiers would allow us to tag each = field with an "Observed" attribute with advantages: >=20 > - we wouldn't need to change fields to varlen just to report length = =3D 0. >=20 > - we could have a many-valued reason rather than a boolean. > ie, we can report why the value is not available or not = applicable. >=20 > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Sun Dec 9 10: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 55D3E21F844E for ; Sun, 9 Dec 2012 10:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 DmNCwJyQJ+mF for ; Sun, 9 Dec 2012 10:01:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0721F8441 for ; Sun, 9 Dec 2012 10:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3740; q=dns/txt; s=iport; t=1355076100; x=1356285700; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EwTNsUuG/o0Bf5AVVhGen8+dcBGQ8Hz87wIjxPDzNF0=; b=PJS+UdDttHozN+CCQcs8psyHvLr/XbwiqH7P1HBFCBPsCYzOqCbOjicW MPgGJv1wXAE+07nPX6ERd+sUfGuLLvBwa+x/jgbB6FTDB4fPT9g7zn/qq iv+kCe2CVoJ71kjcyJa02byPi31Q2FHwI3hSh6Hkv8eiYhSnRtl5HWzjp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsIAErRxFCQ/khR/2dsb2JhbABEg0i7FhZzgh4BAQECAQEBAQE1NgoBBQsLGAkWDwkDAgECARUwBg0BBQIBAYgHBgy+V4w/C4Q4A5YGgRyET4pdgnOBbQ X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="148014107" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2012 18:01:39 +0000 Received: from [10.55.82.214] (dhcp-10-55-82-214.cisco.com [10.55.82.214]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB9I1cJr015116; Sun, 9 Dec 2012 18:01:38 GMT Message-ID: <50C4D203.3090204@cisco.com> Date: Sun, 09 Dec 2012 18:01:39 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> In-Reply-To: <88D44B6F-F10C-47FD-947C-A9171AD7F127@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] unobserved fields 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: Sun, 09 Dec 2012 18:01:41 -0000 Brian, > Hi, Paul, Andrew, > > I'm not sure I understand the proposed mechanism here... > > Observed/unobserved is a per-field/per-record attribute, while extended field specifiers modify IEs per-column: every instance of a given IE in a Template is "decorated" with its extension. Actually each EFS can contribute additional data within the template (ie, applying per column) and/or additional info within data records (ie, applying per row). Look at slide 7 here: http://tools.ietf.org/agenda/85/slides/slides-85-ipfix-2.pdf eg, within the template we'd want to indicate which OID is being exported, while we want to indicate indices per data-record. > As I understand the requirements for -unobserved-fields, we want a way to distinguish, from an MP: "I am capable of observing this attribute, but it was not present in the observation" Or, I don't (yet) have sufficient data to calculate a derived metric, eg average / min / max, count or time based metrics. > versus "I am not capable of observing this attribute". We have the second already: simply leave the IE out of the template. No. Leaving the metric out of the template does not actively indicate that the MP is not capable of measuring it. A CP cannot make any assumptions about metrics which the MP isn't reporting. Rather than this *passive* method, we're missing a way for the MP to *actively* inform the CP that although it's capable of measuring some metric, it's currently not able to provide any further information about the metric. > And, indeed, you can also use leaving things out of the template to signify the first: the presence of a field in some templates from an EP/MP combination implies that it's observable, its absence in the other implies it's not observed. No it doesn't. That's the whole point of -unobserved-fields! The MP could have observed it and between the MP and EP, decided not to export it. eg, certain IP addresses, user names, URLs, could be filtered from export stream for privacy or security. The absence of a field in the template isn't directly related to the field's observability. > FWIW, YAF does this for those things that haven't moved behind the 6313 curtain: no reverse elements if it's not a biflow, for instance. > > Given that, how would you use a per-IE specifier to signal a per-record attribute? What am I missing? EFS are also per-record, eg OID index. See the MIB draft. P. > On 7 Dec 2012, at 20:01, Paul Aitken wrote: > >> Andrew, >> >>> My earlier email about Extended Field Specifiers reminded me of an other draft (draft-aitken-ipfix-unobserved-fields) that doesn't seem to have gone anywhere, but that I would love to move forward. Having a standard way to know if field is unobserved/NULL for a given flow would be very valuable. >> It's not that this draft didn't go anywhere. Rather, I've written all I can for now, yet the WG isn't in a position to adopt the work. However it's a real issue that needs to be solved -in fact, we're already using some of the techniques in this document - so in my mind it's only "on hold" until I think of something to add and/or the WG can adopt it. >> >> You're right, Extended Field Specifiers would allow us to tag each field with an "Observed" attribute with advantages: >> >> - we wouldn't need to change fields to varlen just to report length = 0. >> >> - we could have a many-valued reason rather than a boolean. >> ie, we can report why the value is not available or not applicable. >> >> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Dec 10 01:19:26 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 9411121F8E32 for ; Mon, 10 Dec 2012 01:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxtt6pGCLaEu for ; Mon, 10 Dec 2012 01:19:26 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CCA4921F8E34 for ; Mon, 10 Dec 2012 01:19:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AFE41D930B; Mon, 10 Dec 2012 10:19:20 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fdJP0Ns0g61Y; Mon, 10 Dec 2012 10:19:20 +0100 (MET) Received: from [192.168.0.79] (unknown [195.101.98.59]) (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 A0A99D9308; Mon, 10 Dec 2012 10:19:04 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50C4D203.3090204@cisco.com> Date: Mon, 10 Dec 2012 10:18:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F3700A3-0562-47B0-8BEC-394951179E8C@tik.ee.ethz.ch> References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> <50C4D203.3090204@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] unobserved fields 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, 10 Dec 2012 09:19:26 -0000 hi, Paul, all, Ahhhh -- okay, so you'd be proposing using an indexing mechanism, as = with MIB objects, to explicitly link one IE in a record with another to = allow the "observation index" IE to expose the observation state of each = IE? I think an example illustrating this -- how MIB-style EFS would support = -unobserved-fields -- in the next rev of -unobserved-fields would be = very useful. A couple of other points inline... On 9 Dec 2012, at 19:01, Paul Aitken wrote: >> As I understand the requirements for -unobserved-fields, we want a = way to distinguish, from an MP: "I am capable of observing this = attribute, but it was not present in the observation" >=20 > Or, I don't (yet) have sufficient data to calculate a derived metric, = eg average / min / max, count or time based metrics. >=20 >=20 >> versus "I am not capable of observing this attribute". We have the = second already: simply leave the IE out of the template. >=20 > No. Leaving the metric out of the template does not actively indicate = that the MP is not capable of measuring it. A CP cannot make any = assumptions about metrics which the MP isn't reporting. Rather than this = *passive* method, we're missing a way for the MP to *actively* inform = the CP that although it's capable of measuring some metric, it's = currently not able to provide any further information about the metric. Absolutely agree; I'm pointing out the "way to do this today" -- which = is ambiguous. >> And, indeed, you can also use leaving things out of the template to = signify the first: the presence of a field in some templates from an = EP/MP combination implies that it's observable, its absence in the other = implies it's not observed. >=20 > No it doesn't. That's the whole point of -unobserved-fields! The MP = could have observed it and between the MP and EP, decided not to export = it. eg, certain IP addresses, user names, URLs, could be filtered from = export stream for privacy or security. The absence of a field in the = template isn't directly related to the field's observability. As above. I'm not saying this is the right way to do things; I'm saying = it's the de facto approach. >> FWIW, YAF does this for those things that haven't moved behind the = 6313 curtain: no reverse elements if it's not a biflow, for instance. >>=20 >> Given that, how would you use a per-IE specifier to signal a = per-record attribute? What am I missing? >=20 > EFS are also per-record, eg OID index. See the MIB draft. Okay, so EFS -- specificially, any extension applying an "indexing" = feature -- allows specifying that one IE in a Template is present to = modify another, so the per-record information still appears in the = record; it's just that EFS has allowed an explicit linkage between the = IEs, where before we'd have only an implicit linkage (bad, because it's = very easy to interpret incorrectly) or an explicit linkage keyed to a = specific function in the definition of the IE, e.g. flowKeyIndicator = (less bad but still bad, because continuing along these lines you run = out of IEs pretty quickly)...correct? Cheers, Brian From paitken@cisco.com Mon Dec 10 01:53:59 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 A1D0421F8E4F for ; Mon, 10 Dec 2012 01:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 l3YnksX+Ai8o for ; Mon, 10 Dec 2012 01:53:58 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D021F8E45 for ; Mon, 10 Dec 2012 01:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4161; q=dns/txt; s=iport; t=1355133238; x=1356342838; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BV9JwP1GNQKp6XtMT75V04hCDu2vL8AHs8zh88BITCo=; b=CALtGTTOQyThFb83eXfDZCStns/LlLTejdA8ImR4tn8tbX4o40IbdH/C RQg8laQiju1Sf1ygvkInEbC3t95wg+KcWkrQHRy2WfpgGIiJeUJ+hqLDt 5cBmO2lp5lLiaw+lvjoBX6DnbvqovilV5ss6R1aReygtIDiU1ekv8AXpU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwHAO+wxVCQ/khM/2dsb2JhbABEg0i7KRZzgh4BAQEDAThAAQULCxgJFg8JAwIBAgFFBg0BBQIBAYgHBrYMjD+EQwOWBoVril2Ccw X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="10299085" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 10 Dec 2012 09:53:37 +0000 Received: from [10.55.84.15] (dhcp-10-55-84-15.cisco.com [10.55.84.15]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBA9rbRi005110; Mon, 10 Dec 2012 09:53:37 GMT Message-ID: <50C5B121.1080007@cisco.com> Date: Mon, 10 Dec 2012 09:53:37 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> <50C4D203.3090204@cisco.com> <7F3700A3-0562-47B0-8BEC-394951179E8C@tik.ee.ethz.ch> In-Reply-To: <7F3700A3-0562-47B0-8BEC-394951179E8C@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] unobserved fields 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, 10 Dec 2012 09:53:59 -0000 Brian, > Ahhhh -- okay, so you'd be proposing using an indexing mechanism, as with MIB objects, to explicitly link one IE in a record with another to allow the "observation index" IE to expose the observation state of each IE? No. There's only one IE. In MIB export, the template effectively says "here is a MIB, with two extensions; the first defines the OID (in the template); the second defines the index (in the data records)". Appropriate sizes are given, and the template and data records are extended accordingly. So instead of getting a 4-byte value in the data record, there might be 6 bytes: the 4 bytes value followed by a 2-bytes index. However the index has no IE of its own, so each new extension does not require a new IE. In the unobserved fields scenario, the template would says "here is an IE, with an extension (in the data records)", and that extension would indicate the observability of the IE. So instead of 4 bytes of RTT time, there might be 5 bytes: 4 bytes of RTT (being zero, presumably), and 1 byte reporting "insufficient time". > I think an example illustrating this -- how MIB-style EFS would support -unobserved-fields -- in the next rev of -unobserved-fields would be very useful. Are MIBS ever unobserved? > A couple of other points inline... > > On 9 Dec 2012, at 19:01, Paul Aitken wrote: > >>> As I understand the requirements for -unobserved-fields, we want a way to distinguish, from an MP: "I am capable of observing this attribute, but it was not present in the observation" >> Or, I don't (yet) have sufficient data to calculate a derived metric, eg average / min / max, count or time based metrics. >> >> >>> versus "I am not capable of observing this attribute". We have the second already: simply leave the IE out of the template. >> No. Leaving the metric out of the template does not actively indicate that the MP is not capable of measuring it. A CP cannot make any assumptions about metrics which the MP isn't reporting. Rather than this *passive* method, we're missing a way for the MP to *actively* inform the CP that although it's capable of measuring some metric, it's currently not able to provide any further information about the metric. > Absolutely agree; I'm pointing out the "way to do this today" -- which is ambiguous. Great, we agree. >>> And, indeed, you can also use leaving things out of the template to signify the first: the presence of a field in some templates from an EP/MP combination implies that it's observable, its absence in the other implies it's not observed. >> No it doesn't. That's the whole point of -unobserved-fields! The MP could have observed it and between the MP and EP, decided not to export it. eg, certain IP addresses, user names, URLs, could be filtered from export stream for privacy or security. The absence of a field in the template isn't directly related to the field's observability. > As above. I'm not saying this is the right way to do things; I'm saying it's the de facto approach. Which has this huge gap... >>> FWIW, YAF does this for those things that haven't moved behind the 6313 curtain: no reverse elements if it's not a biflow, for instance. >>> >>> Given that, how would you use a per-IE specifier to signal a per-record attribute? What am I missing? >> EFS are also per-record, eg OID index. See the MIB draft. > Okay, so EFS -- specificially, any extension applying an "indexing" feature -- allows specifying that one IE in a Template is present to modify another, so the per-record information still appears in the record; it's just that EFS has allowed an explicit linkage between the IEs, where before we'd have only an implicit linkage (bad, because it's very easy to interpret incorrectly) or an explicit linkage keyed to a specific function in the definition of the IE, e.g. flowKeyIndicator (less bad but still bad, because continuing along these lines you run out of IEs pretty quickly)...correct? Sort of, except there's only one IE with additional data. I'm not proposing new IEs for every new attribute specified in an EFS. P. From trammell@tik.ee.ethz.ch Mon Dec 10 02:21:27 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 3F91021F8E5E for ; Mon, 10 Dec 2012 02:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieQaAA6Go+hI for ; Mon, 10 Dec 2012 02:21:26 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF121F8E57 for ; Mon, 10 Dec 2012 02:21:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 59763D9304; Mon, 10 Dec 2012 11:21:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qULxNAJKC-Vw; Mon, 10 Dec 2012 11:21:22 +0100 (MET) Received: from [192.168.0.79] (unknown [195.101.98.59]) (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 372BED930B; Mon, 10 Dec 2012 11:21:10 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50C5B121.1080007@cisco.com> Date: Mon, 10 Dec 2012 11:21:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8560F8F8-9EC3-4D0E-A3C0-14192CE04F61@tik.ee.ethz.ch> References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> <50C4D203.3090204@cisco.com> <7F3700A3-0562-47B0-8BEC-394951179E8C@tik.ee.ethz.ch> <50C5B121.1080007@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] unobserved fields 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, 10 Dec 2012 10:21:27 -0000 On 10 Dec 2012, at 10:53, Paul Aitken wrote: > Brian, >=20 >> Ahhhh -- okay, so you'd be proposing using an indexing mechanism, as = with MIB objects, to explicitly link one IE in a record with another to = allow the "observation index" IE to expose the observation state of each = IE? >=20 > No. There's only one IE. Ah. Okay. Got it. I'd missed something in my reading of the MIB draft, = then (or, rather, I'd paid the most attention to the IE-index-based = indexing, which looks the "most IPFIXish", to me anyway, and sort of = assumed the others looked the same...) > In MIB export, the template effectively says "here is a MIB, with two = extensions; the first defines the OID (in the template); the second = defines the index (in the data records)". Appropriate sizes are given, = and the template and data records are extended accordingly. So instead = of getting a 4-byte value in the data record, there might be 6 bytes: = the 4 bytes value followed by a 2-bytes index. However the index has no = IE of its own, so each new extension does not require a new IE. >=20 > In the unobserved fields scenario, the template would says "here is an = IE, with an extension (in the data records)", and that extension would = indicate the observability of the IE. So instead of 4 bytes of RTT time, = there might be 5 bytes: 4 bytes of RTT (being zero, presumably), and 1 = byte reporting "insufficient time". thinking aloud... so, the "insufficient time" not-IE is an entry in a = registry of "in-record IE decorator", like MIB index; there's an = extension for "in-record IE decorator" which points to this registry = entry; presumably, this decorator is "generic" enough to apply to most = or all IEs? (actually, I'd call it just "insufficient data"; maybe it = makes sense to combine this with other flags for per-record attributes, = for the sake of efficiency...) >> I think an example illustrating this -- how MIB-style EFS would = support -unobserved-fields -- in the next rev of -unobserved-fields = would be very useful. >=20 > Are MIBS ever unobserved? I'm not enough of an SMI geek to answer that question. I'd seen MIB = export as simply another source of information elements, so would ask = "why not?" but there may be reasons why not that I don't appreciate. (we've agreed to agree on the rest of the points, so ) Cheers, Brian From paitken@cisco.com Mon Dec 10 02:46:42 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 DE8DB21F8CDF for ; Mon, 10 Dec 2012 02:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 LZDIQmy-yQn2 for ; Mon, 10 Dec 2012 02:46:42 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E5A8A21F8E09 for ; Mon, 10 Dec 2012 02:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3227; q=dns/txt; s=iport; t=1355136401; x=1356346001; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Oqz4znzX1s4LplcpOAYI2qqx89tF8lhMA2kCfPvv/TM=; b=P6S1zSN2OSW63y4cyYrnCKp8MAhBO0dvvwGLswY7UaaiezkkPKrDPvBk 5ypxcuFtmfiWybgBLlti92QdM+n0t4A4HwDSxxRMFBhf9NUdDRACdxOu3 m68+/+azy31RXV0bZrE+/yRYbHV/xW2okfwfg5blahizOnk2NZsoZf0eS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwHABO8xVCQ/khM/2dsb2JhbABEg0i7KRZzgh4BAQEDAThAAQULCxgJFg8JAwIBAgFFBg0BBQIBAYgHBrYNjD+EQwOWBoVril2Ccw X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="10300239" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 10 Dec 2012 10:46:38 +0000 Received: from [10.55.84.15] (dhcp-10-55-84-15.cisco.com [10.55.84.15]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBAAkcJV014288; Mon, 10 Dec 2012 10:46:38 GMT Message-ID: <50C5BD8F.9060707@cisco.com> Date: Mon, 10 Dec 2012 10:46:39 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> <50C4D203.3090204@cisco.com> <7F3700A3-0562-47B0-8BEC-394951179E8C@tik.ee.ethz.ch> <50C5B121.1080007@cisco.com> <8560F8F8-9EC3-4D0E-A3C0-14192CE04F61@tik.ee.ethz.ch> In-Reply-To: <8560F8F8-9EC3-4D0E-A3C0-14192CE04F61@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] unobserved fields 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, 10 Dec 2012 10:46:43 -0000 Brian, > On 10 Dec 2012, at 10:53, Paul Aitken wrote: > >> Brian, >> >>> Ahhhh -- okay, so you'd be proposing using an indexing mechanism, as with MIB objects, to explicitly link one IE in a record with another to allow the "observation index" IE to expose the observation state of each IE? >> No. There's only one IE. > Ah. Okay. Got it. I'd missed something in my reading of the MIB draft, then (or, rather, I'd paid the most attention to the IE-index-based indexing, which looks the "most IPFIXish", to me anyway, and sort of assumed the others looked the same...) > >> In MIB export, the template effectively says "here is a MIB, with two extensions; the first defines the OID (in the template); the second defines the index (in the data records)". Appropriate sizes are given, and the template and data records are extended accordingly. So instead of getting a 4-byte value in the data record, there might be 6 bytes: the 4 bytes value followed by a 2-bytes index. However the index has no IE of its own, so each new extension does not require a new IE. >> >> In the unobserved fields scenario, the template would says "here is an IE, with an extension (in the data records)", and that extension would indicate the observability of the IE. So instead of 4 bytes of RTT time, there might be 5 bytes: 4 bytes of RTT (being zero, presumably), and 1 byte reporting "insufficient time". > thinking aloud... so, the "insufficient time" not-IE is an entry in a registry of "in-record IE decorator", like MIB index; there's an extension for "in-record IE decorator" which points to this registry entry; presumably, this decorator is "generic" enough to apply to most or all IEs? (actually, I'd call it just "insufficient data"; maybe it makes sense to combine this with other flags for per-record attributes, for the sake of efficiency...) Yes, there's a 16-bit type field in the EFS which specifies what the field attribute is (eg, OID, index, unobserved, ...). Actually I've been wonder whether there are any EFS which require data in both the template and the data record; if not then the topmost type bit could indicate this, so there'd only need to be one length field (rather than one for template info + one for data record info). Since the "unobserved" field needs to be at least 8 bits (since IPFIX deals with bytes rather than bits), we can run to 255 "unobserved" reasons (plus zero for "observed"). So although we could start with just a few generic reasons, we can afford to call out exactly why no data was available. eg, "insufficient" could be due to insufficient time (eg, RTT or 1-minute average) or insufficient data (eg, average / mean). P. >>> I think an example illustrating this -- how MIB-style EFS would support -unobserved-fields -- in the next rev of -unobserved-fields would be very useful. >> Are MIBS ever unobserved? > I'm not enough of an SMI geek to answer that question. I'd seen MIB export as simply another source of information elements, so would ask "why not?" but there may be reasons why not that I don't appreciate. > > (we've agreed to agree on the rest of the points, so ) > > Cheers, > > Brian > > From paitken@cisco.com Mon Dec 10 06:59:49 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 867D921F8500 for ; Mon, 10 Dec 2012 06:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 Q9sjiggWdFYw for ; Mon, 10 Dec 2012 06:59:49 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6A25A21F84FD for ; Mon, 10 Dec 2012 06:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=379983; q=dns/txt; s=iport; t=1355151583; x=1356361183; h=message-id:date:from:mime-version:to:subject; bh=/f36KKTPO/0w6GKdPWJgsL6cizFVEdMmrBZ2JvoSzuo=; b=f0tcg6jv9TQf0dGryIcQhX0I5OxwcgLuDHAODEAV6GGLbIa8nWVBsMhz utddTFGtapb5Vqp3dUTf0CRe2whpsSjv+1mCcjHY2UlDjax0FkovPUvnt VQaNA4wN1T4xHk9fIY0+H6915C8lzZCwcjWYgdGeflw8eiHwSPuRk8ygH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4HAGj4xVCQ/khL/2dsb2JhbACEDYhOsn5z X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="10297524" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Dec 2012 14:59:32 +0000 Received: from [10.55.84.15] (dhcp-10-55-84-15.cisco.com [10.55.84.15]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBAExNZi018212 for ; Mon, 10 Dec 2012 14:59:24 GMT Message-ID: <50C5F8CC.5070609@cisco.com> Date: Mon, 10 Dec 2012 14:59:24 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------080303060203060507050408" Subject: [IPFIX] WGLC for draft-ietf-ipfix-protocol-rfc5101bis-03 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, 10 Dec 2012 14:59:49 -0000 This is a multi-part message in MIME format. --------------080303060203060507050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here's a comprehensive review of draft-ietf-ipfix-protocol-rfc5101bis-03 : > > > > > Network Working Group B. Claise, Ed. > Internet Draft Cisco Systems, Inc. > Obsoletes: 5101 B. Trammell, Ed. > Category: Standards Track ETH Zurich > Expires: May 24, 2013 November 20, 2012 > > > Specification of the IP Flow Information eXport (IPFIX) Protocol > for the Exchange of Flow Information > draft-ietf-ipfix-protocol-rfc5101bis-03 > > > Abstract > > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting Traffic Flow information over > the network. In order to transmit Traffic Flow information from an > Exporting Process to an information Collecting Process, a common > representation of flow data and a standard means of communicating > them is required. This document describes how the IPFIX Data and > Template Records are carried over a number of transport protocols > from an IPFIX Exporting Process to an IPFIX Collecting Process. This > document obsoletes RFC 5101. > > 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 March 23, 2012. Then it's expired already. Can we run a valid WGLC on an expired version? > > Copyright Notice > > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. == The copyright year in the IETF Trust and authors Copyright Line does not match the current year > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > > > > Standards Track [Page 1] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > (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. > > > > > Table of Contents > > 1.1. Changes since RFC 5101 . . . . . . . . . . . . . . . . . . 4 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 11 > 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 11 > 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 14 > 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 15 > 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 16 > 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 16 > 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 17 > 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 18 > 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 18 > 3.4.2. Options Template Record Format . . . . . . . . . . . . 20 > 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 21 > 3.4.2.2. Options Template Record Format . . . . . . . . . . 22 > 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 24 > 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 25 > 4.1. The Metering Process Statistics Options Template . . . . . 25 > 4.2. The Metering Process Reliability Statistics Options > Template . . . . . . . . . . . . . . . . . . . . . . . . . 26 > 4.3. The Exporting Process Reliability Statistics Options > Template . . . . . . . . . . . . . . . . . . . . . . . . . 28 > 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 29 > 5. IPFIX Message Header Export Time and Flow Record Time . . . . 30 > 6. Linkage with the Information Model . . . . . . . . . . . . . . 30 > 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31 > 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31 > 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31 > 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31 > 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31 > 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 31 > 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 31 > 6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 31 > 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 32 > 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 32 > > > > Standards Track [Page 2] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 32 > 6.2. Reduced Size Encoding . . . . . . . . . . . . . . . . . . 33 > 7. Variable-Length Information Element . . . . . . . . . . . . . 34 > 8. Template Management . . . . . . . . . . . . . . . . . . . . . 36 > 8.1. Template Withdrawal and Redefinition . . . . . . . . . . . 37 > 8.2 Sequencing Template Management Actions . . . . . . . . . . 39 > 8.3. Additional considerations for Template Management over > SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 > 8.4. Additional considerations for Template Management over > UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 > 9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 41 > 9.1. Additional considerations for SCTP Collecting Processes . 42 > 9.2. Additional considerations for UDP Collecting Processes . . 42 > 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 42 > 10.1. Transport Compliance and Transport Usage . . . . . . . . 44 > 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 44 > 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 44 > 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 44 > 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45 > 10.2.4. Association Establishment and Shutdown . . . . . . . 45 > 10.2.5. Failover . . . . . . . . . . . . . . . . . . . . . . 46 > 10.2.6. Streams . . . . . . . . . . . . . . . . . . . . . . . 46 > 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 > 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 46 > 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 46 > 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 47 > 10.3.4. Session Establishment and Shutdown . . . . . . . . . 47 > 10.3.5. Failover and Session Duplication . . . . . . . . . . 47 > 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 > 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 48 > 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 49 > 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 49 > 10.4.4. Connection Establishment, Shutdown, and Restart . . . 49 > 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 50 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 > 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 51 > 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 52 > 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 52 > 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 53 > 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 54 > 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 55 > 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 55 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 > Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 56 > A.1. Message Header Example . . . . . . . . . . . . . . . . . . 56 > A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 57 > A.2.1. Template Set Using IETF-Specified Information > Elements . . . . . . . . . . . . . . . . . . . . . . . 57 > > > > Standards Track [Page 3] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A.2.2. Template Set Using Enterprise-Specific Information > Elements . . . . . . . . . . . . . . . . . . . . . . . 57 > A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 59 > A.4. Options Template Set Examples . . . . . . . . . . . . . . 60 > A.4.1. Options Template Set Using IETF-Specified > Information Elements . . . . . . . . . . . . . . . . . 60 > A.4.2. Options Template Set Using Enterprise-Specific > Information . . . . . . . . . . . . . . . . . . . . . 60 > A.4.3. Options Template Set Using an Enterprise-Specific > Scope . . . . . . . . . . . . . . . . . . . . . . . . 61 > A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 62 > A.5. Variable-Length Information Element Examples . . . . . . . 63 > A.5.1. Example of Variable-Length Information Element with > Length . . . . . . . . . . . . . . . . . . . . . . . . 63 > A.5.2. Example of Variable-Length Information Element with > 3 Octet Length Encoding . . . . . . . . . . . . . . . 63 > References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 > Normative References . . . . . . . . . . . . . . . . . . . . . . . 63 > Informative References . . . . . . . . . . . . . . . . . . . . . . 64 > Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 > > > > > 1. Introduction > > Traffic on a data network can be seen as consisting of flows passing > through network elements. It is often interesting, useful, or even > necessary to have access to information about these flows that pass > through the network elements for administrative or other purposes. A > collecting process should be able to receive the flow information The earlier Abstract uses capitalised "Collecting Process". > passing through multiple network elements within the data network. > This requires uniformity in the method of representing the flow > information and the means of communicating the flows from the network > elements to the collection point. This document specifies a protocol > to achieve these aforementioned requirements. This document specifies > in detail the representation of different flows, the additional data > required for flow interpretation, packet format, transport mechanisms > used, security concerns, etc. > > 1.1. Changes since RFC 5101 This section says *what* changes were made. However, it's missing a statement on *why* 5101 had to be rewritten. What were the main reasons for rewriting 5101? > This document obsoletes the Proposed Standard revision of the IPFIX > Protocol Specification [RFC5101]. The protocol specified by this > document is interoperable with the protocol as specified in > [RFC5101]. The following changes have been made to this document with > respect to the previous document: > > > > Standards Track [Page 4] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > - EDITOR'S NOTE: not sure if we need to this information > Errata ID: 1655 (technical) > Errata ID: 2791 (technical) > Errata ID: 2814 (editorial) > Errata ID: 1818 (editorial) > Errata ID: 2792 (editorial) > Errata ID: 2888 (editorial) > Errata ID: 2889 (editorial) > Errata ID: 2890 (editorial) > Errata ID: 2891 (editorial) > Errata ID: 2892 (editorial) > Errata ID: 2903 (editorial) > Errata ID: 2761 (editorial) > Errata ID: 2762 (editorial) > Errata ID: 2763 (editorial) > Errata ID: 2764 (editorial) > Errata ID: 2852 (editorial) > Errata ID: 2857 (editorial) > > - The encoding of the dateTimeSeconds, dateTimeMilliseconds, > dateTimeMicroseconds, and dateTimeNanoseconds data types, and the > related encoding of the IPFIX Message Header Export Time field, have > been clarified, especially with respect to the epoch upon which the > timestamp data types are based. > > - Clarifications on encoding, especially in Section 6: all IPFIX > values encoded big-endian. > > - Template management in section 8 has been simplified, and made as > independent of transport protocol as is interoperably possible, by > relaxing restrictions on template management actions. > > - Editorial changes, including structural changes to sections 8, 9, > and 10 to improve readability. > > > 1.2. IPFIX Documents Overview > > The IPFIX protocol provides network administrators with access to IP > flow information. The architecture for the export of measured IP > flow information out of an IPFIX Exporting Process to a Collecting > Process is defined in [RFC5470], per the requirements defined in > [RFC3917]. This document specifies how IPFIX data records and > templates are carried via a number of transport protocols from IPFIX > Exporting Processes to IPFIX Collecting Processes. > > Four IPFIX optimizations/extensions are currently specified: a > bandwidth saving method for the IPFIX protocol in [RFC5473], an > > > > Standards Track [Page 5] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > efficient method for exporting bidirectionalflow in [RFC5103], a "flows" > method for the definition and export of complex data structures in > [RFC6313], and the specification of the Protocol for IPFIX Mediations > [IPFIX-MED-PROTO] based on theIPIFX Mediation Framework [RFC6183]. Although "IP InFormation eXport" is arguably a better name, the current name is "IPFIX". > > IPFIX has a formal description of IPFIX Information Elements, their > name, type and additional semantic information, as specified in > [RFC5102bis], with the export of the Information Element types > specified in [RFC5610]. > > [IPFIX-CONF] specifies a data model for configuring and monitoring RFC6728. > IPFIX and PSAMP compliant devices using the NETCONF protocol, while > the [RFC5815bis] specifies a MIB module for monitoring. remove "the". > > In terms of development, [RFC5153] provides guidelines for the > implementation and use of the IPFIX protocol, while [RFC5471] > provides guidelines for testing. > > Finally, [RFC5472] describes what type of applications can use the > IPFIX protocol and how they can use the information provided. It > furthermore shows how the IPFIX framework relates to other > architectures and frameworks. > > 2. Terminology > > 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]. > > The definitions of the basic terms like Traffic Flow, Exporting > Process, Collecting Process, Observation Points, etc. are > semantically identical to those found in the IPFIX requirements > document [RFC3917]. Some of the terms have been expanded for more > clarity when defining the protocol. Additional terms required for > the protocol have also been defined. Definitions in this document > and in [RFC5470] are equivalent, except that definitions that are > only relevant to the IPFIX protocol only appear here. > > The terminology summary table in Section 2.1 gives a quick overview > of the relationships between some of the different terms defined. > > Observation Point > > An Observation Point is a location in the network where packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. > > > > Standards Track [Page 6] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Point > may be a superset of several other Observation Points. For > example, one Observation Point can be an entire line card. That > would be the superset of the individual Observation Points at the > line card's interfaces. > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IPFIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain IDs > also be unique per IPFIX Device. > > Traffic Flow or Flow > > There are several definitions of the term 'flow' being used by the > Internet community. Within the context of IPFIX we use the > following definition: > > A Flow is defined as a set of packets passing an Observation Point > in the network during a certain time interval. All packets > belonging to a particular Flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. one or more packet header fields (e.g., destination IP > address), transport header fields (e.g., destination port > number), or application header fields (e.g., RTP header > fields [RFC3550]). > > 2. one or more characteristics of the packet itself (e.g., > number of MPLS labels, etc...). > > 3. one or more of fields derived from packet treatment (e.g., > next hop IP address, the output interface, etc...). > > A packet is defined as belonging to a Flow if it completely > satisfies all the defined properties of the Flow. > > Note that the set of packets represented by a Flow may be empty; > > > > Standards Track [Page 7] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > that is, a Flow may represent zero or more packets. Note also that > as sampling is a packettreatent, this definition includes packets "treatment" > selected by a sampling mechanism. "also" seems to be in the wrong place. Consider: "Note also that as sampling is a packet treatment, this definition also includes packets selected by a sampling mechanism." > > Flow Key > > Each of the fields that: > > 1. belong to the packet header (e.g., destination IP address), > > 2. are a property of the packet itself (e.g., packet length), > > 3. are derived from packet treatment (e.g., Autonomous System > (AS) number), > > and that are used to define a Flow are termed Flow Keys. There's an implicit OR between 1, 2, and 3 that's confused by the final "and that". Putting ", or" at the end of 1 and 2 might help. > > Flow Record > > A Flow Record contains information about a specific Flow that was > observed at an Observation Point. A Flow Record contains measured > properties of the Flow (e.g., the total number of bytes for all > the Flow's packets) and usually characteristic properties of the > Flow (e.g., source IP address). Say, "and usually contains characteristic properties", else the statement is that "A FR contains ... usually characteristic properties", which is something else entirely. > > Metering Process > > The Metering Process generates Flow Records. Inputs to the > process are packet headers and characteristics observed at an > Observation Point, and packet treatment at the Observation Point > (for example, the selected output interface). The inputs could come from multiple OPs, and the packet treatment could be at a distinct OP from where the characteristics were observed. eg, suppose a sampler and a filter. That's two treatment OPs. From the earlier definition, "one Observation Point may be a superset of several other Observation Points". However, it's may not be obvious to the IPFIX novice that this applies here. > > The Metering Process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, and > maintaining Flow Records. > > The maintenance of Flow Records may include creating new records, > updating existing ones, computing Flow statistics, deriving > further Flow properties, detecting Flow expiration, passing Flow > Records to the Exporting Process, and deleting Flow Records. > > Exporting Process > > The Exporting Process sends Flow Records to one or more Collecting Consider "zero or more", so the EP can be present but disabled or inactive, not have a reachable CP, or can be filtering what it exports. Else, if it's unable to export or decides not to export a particular FR, it's technically not longer a 5101bis-compliant EP :-( Consider "sends Flow Records and Templates". > Processes. The Flow Records are generated by one or more Metering > Processes. > > Exporter > > > > Standards Track [Page 8] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A device that hosts one or more Exporting Processes is termed an > Exporter. > > IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting Processes and arbitrary numbers of Observation > Points and Metering Processes. > > Collecting Process > > A Collecting Process receives Flow Records from one or more > Exporting Processes. The Collecting Process might process or So it's not actually a CP until it receives data? ie, if it doesn't receive anything, then it's not a CP? > store received Flow Records, but such actions are out of scope for > this document. > > Collector > > A device that hosts one or more Collecting Processes is termed a > Collector. > > Template > > A Template is an ordered sequence of pairs used to > completely specify the structure and semantics of a particular set > of information that needs to be communicated from an IPFIX Device > to a Collector. Each Template is uniquely identifiable by means > of a Template ID. We're moving away from this with SD where type and semantics are contained in data records. Potentially similarly with EFS. > > IPFIX Message > > An IPFIX Message is a message originating at the Exporting Process > that carries the IPFIX records of this Exporting Process and whose > destination is a Collecting Process. An IPFIX Message is > encapsulated at the transport layer. > > Message Header > > The Message Header is the first part of an IPFIX Message, which > provides basic information about the message, such as the IPFIX > version, length of the message, message sequence number, etc. > > Template Record > > A Template Record defines the structure and interpretation of > fields in a Data Record. > > Data Record > > > > Standards Track [Page 9] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A Data Record is a record that contains values of the parameters > corresponding to a Template Record. Clarify the difference between "Flow Record" and "Data Record" ? > > Options Template Record > > An Options Template Record is a Template Record that defines the > structure and interpretation of fields in a Data Record, including > defining how to scope the applicability of the Data Record. > > Set > > Set is a generic term for a collection of records that have a > similar structure. In an IPFIX Message, one or more Sets follow > the Message Header. Then is a header with no sets an invalid IPFIX Message? Maybe it's a new exporter informing the CP that it's there; maybe it's a connectivity test. It's an empty Message, but it's still a Message. > > There are three different types of Sets: Template Set, Options > Template Set, and Data Set. > > Template Set > > A Template Set is a collection of one or more Template Records > that have been grouped together in an IPFIX Message. > > Options Template Set > > An Options Template Set is a collection of one or more Options > Template Records that have been grouped together in an IPFIX > Message. > > Data Set > > A Data Set is one or more Data Records, of the same type, that are > grouped together in an IPFIX Message. Each Data Record is > previously defined by a Template Record or an Options Template > Record. > > Information Element > > An Information Element is a protocol and encoding-independent > description of an attribute that may appear in an IPFIX Record. > The IPFIX information model [RFC5102bis] defines the base set of > Information Elements for IPFIX. The type associated with an Not any more. > Information Element indicates constraints on what it may contain > and also determines the valid encoding mechanisms for use in > IPFIX. > > Transport Session > > > > > Standards Track [Page 10] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > In Stream Control Transmission Protocol (SCTP), the transport > session is known as the SCTP association, which is uniquely > identified by the SCTP endpoints [RFC4960]; in TCP, the transport > session is known as the TCP connection, which is uniquely > identified by the combination of IP addresses and TCP ports used. > In UDP, the transport session is known as the UDP session, which > is uniquely identified by the combination of IP addresses and UDP > ports used. > > 2.1. Terminology Summary Table > > +------------------+---------------------------------------------+ > | | contents | > | +--------------------+------------------------+ > | Set | Template |record | Why isn't "record" capitalised? > +------------------+--------------------+------------------------+ > | Data Set | / | Data Record(s) | > +------------------+--------------------+------------------------+ > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ > | Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > > Figure A: Terminology Summary Table Figure A is unreferenced, ie there's no text saying "Figure A summarises IPFIX terminology". > > A Data Set is composed of Data Record(s). No Template Record is > included. A Template Record or an Options Template Record defines > the Data Record. > > A Template Set contains only Template Record(s). > > An Options Template Set contains only Options Template Record(s). > > 3. IPFIX Message Format > > An IPFIX Message consists of a Message Header, followed by one or > more Sets. The Sets can be any of the possible three types: Data > Set, Template Set, or Options Template Set. > > The format of the IPFIX Message is shown in Figure B. > > +----------------------------------------------------+ > | Message Header | > +----------------------------------------------------+ > | Set | > +----------------------------------------------------+ > | Set | > > > > Standards Track [Page 11] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > +----------------------------------------------------+ > ... > +----------------------------------------------------+ > | Set | > +----------------------------------------------------+ > > Figure B: IPFIX Message Format > > The Exporter MUST encode all integers in the Message Header and the > Set Headers in network byte order (also known as big-endian byte > order). > > Following are some examples of IPFIX Messages: > > 1. An IPFIX Message consisting of interleaved Template, Data, and > Options Template Sets --A newly created Template is exported as > soon as possible. So, if there is already an IPFIX Message with a > Data Set that is being prepared for export, the Template and > Options Template Sets are interleaved with this information, > subject to availability of space. These are implementation details. If "A newly created Template is exported as soon as possible" then the Message would have been exported before the following Data and Options sets could be added. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Standards Track [Page 12] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > +--------+--------------------------------------------------------+ > | | +----------+ +---------+ +-----------+ +---------+ | > |Message | | Template | | Data | | Options | | Data | | > | Header | | Set | | Set | ... | Template | | Set | | > | | | | | | | Set | | | | > | | +----------+ +---------+ +-----------+ +---------+ | > +--------+--------------------------------------------------------+ > > Figure C: IPFIX Message, Example 1 Figure C is unreferenced. If it's not required, then remove it. If it's required, then add some text to say why it's here. > > 2. An IPFIX Message consisting entirely of Data Sets -- After the > appropriate Template Records have been defined and transmitted to > the Collecting Process, the majority of IPFIX Messages consist > solely of Data Sets. > > +--------+----------------------------------------------+ > | | +---------+ +---------+ +---------+ | > |Message | | Data | | Data | | Data | | > | Header | | Set | ... | Set | ... | Set | | > | | +---------+ +---------+ +---------+ | > +--------+----------------------------------------------+ > > Figure D: IPFIX Message, Example 2 Figure D is unreferenced. > > 3. An IPFIX Message consisting entirely of Template and Options > Template Sets. Is there nothing to be said about this, unlike (1) and (2) ? > > +--------+-------------------------------------------------+ > | | +----------+ +----------+ +----------+ | > |Message | | Template | | Template | | Options | | > | Header | | Set | ... | Set | ... | Template | | > | | | | | | | Set | | > | | +----------+ +----------+ +----------+ | > +--------+-------------------------------------------------+ > > Figure E: IPFIX Message, Example 3 Figure E is unreferenced. Why is it here? What does it show? > > > > > > > > > > > > > > > > Standards Track [Page 13] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 3.1. Message Header Format > > The format of the IPFIX Message Header is shown in Figure F. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure F: IPFIX Message Header Format > > Message Header Field Descriptions: > > Version > > Version ofFlow Record format exported in this message. The value Consider "IPFIX" instead of "Flow Record format", because if the Header, Template IDs, or Set IDs are changed, the version would have to change although the FR format may be unchanged. > of this field is 0x000a for the current version, incrementing by > one the version used in the NetFlow services export version 9 > [RFC3954]. > > Length > > Total length of the IPFIX Message, measured in octets, including > Message Header and Set(s). > > Export Time > > Time at which the IPFIX Message Header leaves the Exporter, > expressed in seconds since the UNIX epoch of 1 January 1970 at > 00:00 UTC, encoded as an unsigned 32-bit integer. > > Sequence Number > > Incremental sequence counter modulo 2^32 of all IPFIX Data Records > sent in a the current stream from the current Observation Domain > by the Exporting Process. Each SCTP Stream counts sequence numbers > separately, while all messages in a TCP connection or UDP > transport session are considered to be part of the same stream. > This value SHOULD be used by the Collecting Process to identify > whether any IPFIX Data Records have been missed. Template and > Options Template Records do not increase the Sequence Number. > > > > Standards Track [Page 14] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > The "Observation Domain ID" title is missing here. > A 32-bit identifier of the Observation Domain that is locally > unique to the Exporting Process. The Exporting Process uses the > Observation Domain ID to uniquely identify to the Collecting > Process the Observation Domain that metered the Flows. It is > RECOMMENDED that this identifier also be unique per IPFIX Device. > Collecting Processes SHOULD use the Transport Session and the > Observation Domain ID field to separate different export streams > originating from the same Exporter. The Observation Domain ID > SHOULD be 0 when no specific Observation Domain ID is relevant for > the entire IPFIX Message, for example, when exporting the > Exporting Process Statistics, or in case of a hierarchy of > Collectors when aggregated Data Records are exported. > > 3.2. Field Specifier Format > > Vendors need the ability to define proprietary Information Elements, > because, for example, they are delivering a pre-standards product, or > the Information Element is, in some way, commercially sensitive. > This section describes the Field Specifier format for both > IETF-specified Information Elements [RFC5102bis] and enterprise- > specific Information Elements. NB this text is inconsistent with the texts under Figure K, and above Figure O. > > The Information Elements are identified by the Information Element > identifier. When the Enterprise bit is set to 0, the corresponding > Information Element identifierwill report an IETF-specified Why future tense? "reports" would be fine. > Information Element, and the Enterprise Number MUST NOT be present. > When the Enterprise bit is set to 1, the corresponding Information > Element identifierwill report an enterprise-specific Information As above. > Element; the Enterprise Number MUST be present. An example of this > is shown in Section A.4.2. A.2.2 is the first (and more obvious) example. > > The Field Specifier format is shown in Figure G. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure G: Field Specifier Format > > > > > > > > > > Standards Track [Page 15] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Where: > > E > > Enterprise bit. This is the first bit of the Field Specifier. "Field Specifier" is double-spaced. > If this bit is zero, the Information Element Identifier "Element Identifier" is double-spaced. > identifies an IETF-specified Information Element, and the four- "Element, and" is double-spaced. > octet Enterprise Number field MUST NOT be present. If this bit is > one, the Information Element identifier identifies an enterprise- > specific Information Element, and the Enterprise Numberfiled "Information Element" is double-spaced. s/filed/field/ > MUST be present. > > Information Element identifier > > A numeric value that represents the type of Information Element. > Refer to [RFC5102bis]. Not any more. > > > Field Length > > The length of the corresponding encoded Information Element, in "Element, in" is double-spaced. > octets.Refer to [RFC5102bis]. The field length may be smaller > than the definition in [RFC5102bis] ifthe reduced size encoding Which definition is that? Remove "the". > is used (see Section 6.2). The value 65535 is reserved for > variable-length Information Elements (see Section 7). > > Enterprise Number > > IANA enterprise number [PEN] of the authority defining the > Information Element identifier in this Template Record. > > 3.3. Set and Set Header Format > > A Set is a generic term for a collection of records that have a > similar structure. There are three different types of Sets: Template > Sets, Options Template Sets, and Data Sets. Each of these Sets > consists of a Set Header and one or more records. The Set Format and > the Set Header Format are defined in the following sections. > > 3.3.1. Set Format > > A Set has the format shown in Figure H. The record types can be > either Template Records, Options Template Records, or Data Records. > The record types MUST NOT be mixed within a Set. > > > > > > > > > Standards Track [Page 16] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > +--------------------------------------------------+ > | Set Header | > +--------------------------------------------------+ > | record | > +--------------------------------------------------+ > | record | > +--------------------------------------------------+ > ... > +--------------------------------------------------+ > | record | > +--------------------------------------------------+ > | Padding (opt.) | > +--------------------------------------------------+ > > Figure H: Set Format > > The Set Field Definitions are as follows: > > Set Header > > The Set Header Format is defined in Section 3.3.2. > > Record > > One of the record Formats: Template Record, Options Template > Record, or Data Record Format. > > Padding > > The Exporting Process MAY insert some padding octets, so that the > subsequent Set starts at an aligned boundary. For security > reasons, the padding octet(s) MUST be composed of zero (0) valued > octets. The padding length MUST be shorter than any allowable > record in this Set. If padding of the IPFIX Message is desired in > combination with very short records, then the padding Information > Element'paddingOctets' [RFC5102bis] can be used for padding 5102bis isn't a reference for PO. > records such that their length is increased to a multiple of 4 or > 8 octets. Because Template Sets are always 4-octet aligned by > definition, padding is only needed in case of other alignments > e.g., on 8-octet boundaries. > > 3.3.2. Set Header Format > > Every Set contains a common header. This header is defined in Figure > I. Make a non-breaking space in "Figure I". > > > > > > > Standards Track [Page 17] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure I: Set Header Format > > The Set Header Field Definitions are as follows: > > Set ID > > Set ID value identifies the Set. A value of 2 is reserved for the > Template Set. A value of 3 is reserved for the Options Template > Set. All other values from 4 to 255 are reserved for future use. > Values above 255 are used for Data Sets. The Set ID values of 0 "The Set" is double-spaced. > and 1 are not used for historical reasons [RFC3954]. "reasons [RFC3954]" is double-spaced. Add a comma to avoid mis-parsing: "The Set ID values of 0 and 1 are not used, for historical reasons" or re-order: "For historical reasons, Set ID values of 0 and 1 are not used". As it is, the existing text says they're not used for historical reasons, but any other reason is fine. > > Length > > Total length of the Set, in octets, including the Set Header, all > records, and the optional padding. Because an individual Set MAY > contain multiple records, the Length value MUST be used to > determine the position of the next Set. > > 3.4. Record Format > > IPFIX defines three record formats, defined in the next sections: the > Template Record Format, the Options Template Record Format, and the > Data Record Format. > > 3.4.1. Template Record Format > > One of the essential elements in the IPFIX record format is the > Template Record. Templates greatly enhance the flexibility of the > record format because they allow the Collecting Process to process > IPFIX Messages without necessarily knowing the interpretation of all > Data Records. A Template Record contains any combination of > IANA-assigned and/or enterprise-specific InformationElements s/Elements/Element/ (singular) > identifiers. > > The format of the Template Record is shown in Figure J. It consists > of a Template Record Header and one or more Field Specifiers. The > definition of the Field Specifiers is given in Figure G above. > > > > > > > > Standards Track [Page 18] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > +--------------------------------------------------+ > | Template Record Header | > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > ... > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > > Figure J: Template Record Format > > The format of the Template Record Header is shown in Figure K. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID (> 255) | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure K: Template Record Header Format > > The Template Record Header Field Definitions are as follows: > > Template ID > > Each of the newly generated Template Records is given a unique > Template ID. This uniqueness is local to the Transport Session > and Observation Domain that generated the Template ID. Template > IDs 0-255 are reserved for Template Sets, Options Template Sets, > and other reserved Sets yet to be created. Template IDs of Data > Sets are numbered from 256 to 65535. There are no constraints > regarding the order of the Template ID allocation. See note in section 4 about Template IDs. > > Field Count > > Number of fields in this Template Record. > > The example in Figure L shows a Template Setwith mixed standard and > enterprise-specific Information Elements. It consists of a Set > Header, a Template Header, and several Field Specifiers. NB this text is inconsistent with the similar texts in section 3.2, and above Figure O. > > > > > > > > > Standards Track [Page 19] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Information Element id. 1.1 | Field Length 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element id. 1.2 | Field Length 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Information Element id. 1.N | Field Length 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 257 | Field Count = M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element id. 2.1 | Field Length 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Information Element id. 2.2 | Field Length 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Information Element id. 2.M | Field Length 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Enterprise Number x.y" is double-spaced in each case. > > Figure L: Template Set Example > > Information Element Identifiers 1.2 and 2.1 are defined by the IETF > (Enterprise bit = 0) and, therefore, do not need an Enterprise Number > to identify them. > > 3.4.2. Options Template Record Format > > Thanks to the notion of scope,The Options Template Record gives the s/The/the". > Exporter the ability to provide additional information to the > Collector that would not be possible with Flow Records alone. > > > > > Standards Track [Page 20] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > One Options Template Record example is the "Flow Keys", which reports > the Flow Keys for a Template, which is defined as the scope. Another > example is the"Template configuration", which reports the > configuration sampling parameter(s) for the Template, which is > defined as the scope. Possibly the "sampling configuration" reports the configured sampling params ? s/configuration/configured/ "Flow Keys" is in 4.4, but "Template configuration" (or in fact, anything to do with sampling) isn't. > > 3.4.2.1. Scope > > The scope, which is only available in the Options Template Set, gives > the context of the reported Information Elements in the Data Records. > Note that the IPFIX Message Header already contains the Observation NB wrong indentation. > Domain ID (the identifier of the Observation Domain). If not zero, > this Observation Domain ID can be considered as an implicit scope for > the Data Records in the IPFIX Message. The Observation Domain ID > MUST be zero when the IPFIX Message contains Data Records with > different Observation Domain ID values defined as scopes. Not necessarily. I can't think of a great example, but it allows OD#n to report on other ODs in a way that's not possible if n must be in the DR with all the other ODs. > > > Multiple Scope Fields MAY be present in the Options Template Record, > in which case, the composite scope is the combination of the scopes. > For example, if the two scopes are defined as "metering process" and > "template", the combined scope is this Template for this Metering Why are these terms lowercase? Should they be IE names? > Process. The order of the Scope Fields, as defined in the Options > Template Record, is irrelevant in this case. However, if the order > of the Scope Fields in the Options Template Record is relevant, the > order of the Scope Fields MUST be used. For example, if the first > scope defines the filtering function, while the second scope defines > the sampling function, the order of the scope is important. Applying > the sampling function first, followed by the filtering function, > would lead to potentially different Data Records than applying the > filtering function first, followed by the sampling function. In this > case, the Collector deduces the function order by looking at the > order of the scope in the Options Template Record. So how does the EP / CP / whoever determine that the order is important? Why not do away with the ambiguity and simply say that the scope order is always to be regarded? > > The scope is an Information Element specified in the IPFIX > Information Model[RFC5102bis]. An IPFIX-compliant implementation of > the Collecting Process SHOULD support this minimum set of Information > Elements as scope: LineCardId, TemplateId, exporterIPv4Address, > exporterIPv6Address, and ingressInterface. Note that other > Information Elements, such as meteringProcessId, exportingProcessId, > observationDomainId, etc. are also valid scopes. The IPFIX protocol > doesn't prevent the use of any Information Elements for scope. > However, some Information Element types don't make sense if specified > as scope; for example, the counter Information Elements. > > Finally, note that the Scope Field Count MUST NOT be zero. > > > > > > > Standards Track [Page 21] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 3.4.2.2. Options Template Record Format > > An Options Template Record contains any combination of IANA-assigned > and/or enterprise-specific InformationElements identifiers. s/Elements/Element/ (singular) > > The format of the Options Template Record is shown in Figure M. It > consists of an Options Template Record Header and one or more Field > Specifiers. The definition of the Field Specifiers is given in > Figure G above. > > +--------------------------------------------------+ > | Options Template Record Header | > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > ... > +--------------------------------------------------+ > | Field Specifier | > +--------------------------------------------------+ > > Figure M: Options Template Record Format > > The format of the Options Template Record Header is shown in Figure > N. Make a non-breaking space in "Figure N". > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID (> 255) | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure N: Options Template Record Header Format Q: can we deprecate regular Templates (per section 3.4.1) - so everything is in "options template" format - and allow the SFC to be zero for non-scoped (data) Templates? > > The Options Template Record Header Field Definitions are as follows: > > Template ID > > Template ID of this Options Template Record. This value is greater > than 255. > > > > > > > > > Standards Track [Page 22] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Field Count > > Number of all fields in this Options Template Record, including the > Scope Fields. > > Scope Field Count > > Number of scope fields in this Options Template Record. The Scope "The Scope" is double-spaced. > Fields are normal Fields except that they are interpreted as scope at > the Collector. The Scope Field Count MUST NOT be zero. "Count MUST" is double-spaced. > > The example in Figure O shows an Options Template Set with mixed IETF > and enterprise-specific Information Elements. It consists of a Set > Header, an Options Template Header, and several Field Specifiers. NB this text is inconsistent with similar texts in section 3.2, and under Figure K. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 258 | Field Count = N + M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = N |0| Scope 1 Infor. Element Id. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 2 Field Length | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... |1| Scope N Infor. Element Id. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope N Field Length | Scope N Enterprise Number ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option 1 Field Length | Option 1 Enterprise Number ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... Option 1 Enterprise Number | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... |0| Option M Infor. Element Id. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option M Field Length | Padding (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure O: Options Template Set Example > > > > > > > > Standards Track [Page 23] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 3.4.3. Data Record Format > > The Data Records are sent in Data Sets. The format of the Data > Record is shown in Figure P. It consists only of one or more Field > Values. The Template ID to which the Field Values belong is encoded > in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". > > +--------------------------------------------------+ > | Field Value | > +--------------------------------------------------+ > | Field Value | > +--------------------------------------------------+ > ... > +--------------------------------------------------+ > | Field Value | > +--------------------------------------------------+ > > Figure P: Data Record Format > > Note that Field Values do not necessarily have a length of 16 bits. > Field Values are encoded according to their data typespecified in > [RFC5102bis]. Not any more. > > Interpretation of the Data Record format can be done only if the > Template Record corresponding to the Template ID is available at the > Collecting Process. > > The example in Figure Q shows a Data Set. It consists of a Set Header > and several Field Values. > > > > > > > > > > > > > > > > > > > > > > > Standards Track [Page 24] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = Template ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 1 - Field Value 1 | Record 1 - Field Value 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 1 - Field Value 3 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 2 - Field Value 1 | Record 2 - Field Value 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 2 - Field Value 3 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 3 - Field Value 1 | Record 3 - Field Value 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 3 - Field Value 3 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Padding (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure Q: Data Set, Containing Data Records s/Containing/containing/ (lowercase). > > 4. Specific Reporting Requirements > > Some specific Options Templates and Options Template Records are > necessary to provide extra information about the Flow Records and > about the Metering Process. > > The Options Template and Options Template Records defined in these > subsections, which impose some constraints on the Metering Process > and Exporting Process implementations, MAY be implemented. If > implemented, the specific Options Templates SHOULD be implemented as > specified in these subsections. > > The minimum set of Information Elements is always specified in these > Specific IPFIX Options Templates. Nevertheless, extra Information > Elements may be used in these specific Options Templates. > > The Collecting Process MUST check the possible combinations of > Information Elements within the Options Template Records to correctly > interpret the following Options Templates. This is true of all Templates. ie, a CP MUST not assume that Template ID N has any particular meaning. I have been asked about static allocations, so I'd like to see this explicitly stated, eg in section 3.4.1. > > 4.1. The Metering Process Statistics Options Template > > The Metering Process Statistics Options Template specifies the > structure of a Data Record for reporting Metering Process statistics. > It SHOULD contain the following Information Elements that are NB wrong indent. > defined in [RFC5102bis]: Not any more. > > > > Standards Track [Page 25] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > (scope) observationDomainId > An identifier of an Observation Domain that > is locally unique to the Exporting Process. > This Information Element MUST be defined as a > Scope Field. > > (scope) meteringProcessId > An identifier of the Metering Process for > which statistics are reported. This > Information Element MUST be defined as a > Scope Field. > > exportedMessageTotalCount > The total number of IPFIX Messages that the > Exporting Processsuccessfully sent to the > Collecting Process since the Exporting > Process re-initialization. > > exportedFlowRecordTotalCount > The total number of Flow Records that the > Exporting Processsuccessfully sent to the > Collecting Process since the Exporting > Process re-initialization. > > exportedOctetTotalCount > The total number of octets that the Exporting > Processsuccessfully sent to the Collecting > Process since the Exporting Process re- > initialization. How does the EP know these Messages / Records / Octets were successfully sent? eg, they may be handed off to a transport layer which doesn't report back on send status. > > The Exporting Process SHOULD export the Data Record specified by the > Metering Process Statistics Options Template on a regular basis or > based on some export policy. This periodicity or export policy > SHOULD be configurable. > > Note that if several Metering Processes are available on the Exporter > Observation Domain, the Information ElementmeteringProcessId MUST be > specified as an additional Scope Field. How does the collector determine the meaning of the meteringProcessId ? > > 4.2. The Metering Process Reliability Statistics Options Template > > The Metering Process Reliability Options Template specifies the > structure of a Data Record for reporting lack of reliability in the > Metering Process. It SHOULD contain the following Information > Elementsthat are defined in [RFC5102bis]: Not any more. > > > > > > > Standards Track [Page 26] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > (scope) observationDomainId > An identifier of an Observation Domain that > is locally unique to the Exporting Process. > This Information Element MUST be defined as a > Scope Field. > > (scope) meteringProcessId > The identifier of the Metering Process for > whichlack of reliability is reported. This Why "lack of"? This isn't the "Metering Process Unreliability Statistics"! > Information Element MUST be defined as a > Scope Field. > > ignoredPacketTotalCount > The total number of IP packets that the > Metering Process did not process. > > ignoredOctetTotalCount > The total number of octets in observed > packets that the Metering Process did not > process. > > time first packet ignored > The timestamp of the first packet that was > ignored by the Metering Process. For this "Metering Process" is double-spaced. > timestamp, any of the followingtimestamp can "timestamps" plural. > be used: observationTimeSeconds, > observationTimeMilliseconds, > observationTimeMicroseconds, or > observationTimeNanoseconds. > > time last packet ignored > The timestamp of the last packet that was > ignored by the Metering Process. For this "Metering Process" is double-spaced. > timestamp, any of the followingtimestamp can "timestamps" plural. > be used: observationTimeSeconds, > observationTimeMilliseconds, > observationTimeMicroseconds, or > observationTimeNanoseconds. > > The Exporting Process SHOULD export the Data Record specified by the > Metering Process Reliability Statistics Options Template on a regular > basis or based on some export policy. This periodicity or export > policy SHOULD be configurable. > > Note that if several Metering Processes are available on the Exporter > Observation Domain, the Information Element meteringProcessId MUST be > specified as an additional Scope Field. > > > > > Standards Track [Page 27] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Since the Metering Process Reliability Option Template will logically > contain two identical timestamp Information Elements,and since the > order of the Information Elements in the Template Records is not > guaranteed, the Collecting Process MUST determine which is the oldest It's defined as { first, last }, ie the semantic is derived from the position which is defined in the RFC. See section 8. > and the most recent timestamp in order the determine the right > semantic behind the time first packet ignored and time last packet > ignored Information Elements.Note that the counters wrap-around for > the timestamps SHOULD also be taken into account. You're making this hard for no reason. First, Last, in order, "MUST" -> it's easy. > > 4.3. The Exporting Process Reliability Statistics Options Template > > The Exporting Process Reliability Options Template specifies the > structure of a Data Record for reporting lack of reliability in the > Exporting process. It SHOULD contain the following Information > Elements that are defined in[RFC5102bis]: > > (scope) Exporting Process ID > The identifier of the Exporting Process for > which lack of reliability is reported. There > are three Information Elements specified in > [RFC5102bis] that can be used for this purpose: > exporterIPv4Address, exporterIPv6Address, or > exportingProcessId. This Information Element > MUST be defined as a Scope Field. How does the collector understand "exportingProcessId" ? > > notSentFlowTotalCount > The total number of Flows that were generated by > the Metering Process and dropped by the Metering > Process or by the Exporting Process instead of > being sent to the Collecting Process. > > notSentPacketTotalCount > The total number of packets in Flow Records that > were generated by the Metering Process and > dropped by the Metering Process or by the > Exporting Process instead of being sent to the > Collecting Process. > > notSentOctetTotalCount > The total number of octets in packets in Flow > Records that were generated by the Metering > Process and dropped by the Metering Process or > by the Exporting Process instead of being sent > to the Collecting Process. > > > > > > > > Standards Track [Page 28] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > time first flow dropped > The time at which the first Flow Record was > dropped by the Exporting Process. For this > timestamp, any of the following timestamp can be > used: observationTimeSeconds, > observationTimeMilliseconds, > observationTimeMicroseconds, or > observationTimeNanoseconds. > > time last flow dropped > The time at which the last Flow Record was > dropped by the Exporting Process. For this > timestamp, any of the following timestamp can be > used: observationTimeSeconds, > observationTimeMilliseconds, > observationTimeMicroseconds, or > observationTimeNanoseconds. > > The Exporting Process SHOULD export the Data Record specified by the > Exporting Process Reliability Statistics Options Template on a > regular basis or based on some export policy. This periodicity or > export policy SHOULD be configurable. > > Since the Exporting Process Reliability Option Template will > logically contain two identical timestamp Information Elements, and > since the order of the Information Elements in the Template Records > is not guaranteed, the Collecting Process MUST determine which is the > oldest and the most recent timestamp in order the determine the right > semantic behind the time first packet ignored and time last packet > ignored Information Elements.Note that the counters wrap-around for > the timestamps SHOULD also be taken into account. See comments in 4.2 and section 8. > > 4.4. The Flow Keys Options Template > > The Flow Keys Options Template specifies the structure of a Data > Record for reporting the Flow Keys of reported Flows. A Flow Keys > Data Record extends a particular Template Record that is referenced > by its templateId identifier. The Template Record is extended by > specifying which of the Information Elements contained in the > corresponding Data Records describe Flow properties that serve as > Flow Keys of the reported Flow. > > The Flow Keys Options Template SHOULD contain the following > Information Elements that are defined in [RFC5102bis]: Not any more they're not. > > > > > > > > Standards Track [Page 29] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > (scope) templateId An identifier of a Template. This > Information Element MUST be defined as a > Scope Field. > > flowKeyIndicator Bitmap with the positions of the Flow Keys in > the Data Records. > > 5. IPFIX Message Header Export Time and Flow Record Time > > The IPFIX Message Header Export Time field is the time at which the > IPFIX Message Header leaves the Exporter, expressed in seconds since > the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded in an unsigned > 32-bit integer. > > Certain time-related Information Elements may be expressed as an > offset from this Export Time. For example, Data Records requiring a > microsecond precision can export the flow start and end times with > the flowStartMicroseconds and flowEndMicroseconds Information > Elements [RFC5102bis], which encode the absolute time in microseconds > in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit > field. An alternate solution is to export the > flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information > Elements[RFC5102bis] in the Data Record, which respectively report > the flow start and end time as negative offsets from the Export Time, > as an unsigned 32-bit integer. This latter solution lowers the export > bandwidth requirement, saving two bytes per timestamp, while > increasing the load on the Exporter, as the Exporting Process must > calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds > of every single Data Record before exporting the IPFIX Message. > > It must be noted that timestamps based on the Export Time impose some > time constraints on the Data Records contained within the IPFIX > Message. In the example of flowStartDeltaMicroseconds and > flowEndDeltaMicroseconds Information Elements[RFC5102bis], the Data > Record can only contain records with timestamps within 71 minutes of > the Export Time. Otherwise, the 32-bit counter would not be > sufficient to contain the flow start time offset. > > > 6. Linkage with the Information Model > > As with values in the IPFIX Message Header and Set Header, values of > all Information Elements[RFC5102bis], except for those of the string This is potentially a _valid_ citation of 5102bis. I won't mention it any more. > and octetArray data types, are encoded in canonical format in network > byte order (also known as big-endian byte ordering). > > > > > > > Standards Track [Page 30] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 6.1. Encoding of IPFIX Data Types > > The following sectionswill define the encoding of the data types > specified in [RFC5102bis]. Will they? Or do they? Just remove "will". > > 6.1.1. Integral Data Types > > Integral data types -- octet, signed8, unsigned16, signed16, > unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded > using the default canonical format in network byte order. Signed > Integral data types are represented in two's complement notation. > > 6.1.2. Address Types > > Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be > encoded the same way as the integral data types, as six, four, and > sixteen octets in network byte order, respectively. > > 6.1.3. float32 > > The float32 data type MUST be encoded as an IEEE single-precision > 32-bit floating point-type, as specified in [IEEE.754.1985], in > network byte order. > > 6.1.4. float64 > > The float64 data type MUST be encoded as an IEEE double-precision 64- > bit floating point-type, as specified in [IEEE.754.1985], in network > byte order. > > 6.1.5. boolean > > The boolean data type is specified according to the TruthValue in > [RFC2579]. It is encoded as a single-octet integer in network byte > order, as in Section 6.1.1., with the value 1 for true and a value 2 > for false. Every other value is undefined. > > 6.1.6. string and octetArray > > The data type string represents a finite length string of valid > characters of the Unicode character encoding set. The string data > type MUST be encoded inUTF-8 format. RFC3629 ? > The string is sent asan array > of octets using an Information Element of fixed or variable length. Where "array" also allows for zero and one octet. > The data type octetArray has no encoding rules; it represents a raw > array of octets, with theintepretation of the octets defined in the "interpretation". > Information Element definition. > > 6.1.7. dateTimeSeconds > > > > Standards Track [Page 31] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > The data type dateTimeSeconds is an unsigned 32-bit integer in > network byte order containing the number of seconds since the UNIX > epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. > dateTimeSeconds is encoded identically to the IPFIX Message Header > Export Time field. It can represent dates between 1 January 1970 and > 8 February 2106. > > 6.1.8. dateTimeMilliseconds > > The data type dateTimeMilliseconds is an unsigned 64-bit integer in > network byte order, containing the number of milliseconds since the > UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It > can represent dates beginning on 1 January 1970 for approximately the > next 500 billion years. > > 6.1.9 dateTimeMicroseconds > > The data type dateTimeMicroseconds is a 64-bit field encoded > according to the NTP Timestamp format as defined in section 6 of > [RFC5905]. This field is made up of two unsigned 32-bit integers in > network byte order, Seconds and Fraction. The Seconds field is the > number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. > The Fraction field is the fractional number of seconds in units of > 1/(2^32) seconds (approximately 233 picoseconds). It can represent > dates beginning between 1 January 1900 and 8 February 2036. Since we're already over 80% through that range, it seems worth moving the epoch to 1/1/2000. > > Note that dateTimeMicroseconds and dateTimeNanoseconds share an > identical encoding. The dataTimeMicroseconds data type is intended > only to represent timestamps of microsecond precision.Therefore, the > bottom 11 bits of the fraction field MAY contain any value and MUST > be ignored for all Information Elements of this data type (as 2^11 x > 233 picoseconds = .477 microseconds). Why not say, the bottom 11 bits must be zero? > > 6.1.10 dateTimeNanoseconds > > The data type dateTimeNanoseconds is a 64-bit field encoded according > to the NTP Timestamp format as defined in section 6 of [RFC5905]. > This field is made up of two unsigned 32-bit integers in network byte > order, Seconds and Fraction. The Seconds field is the number of > seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The > Fraction field is the fractional number of seconds in units of > 1/(2^32) seconds (approximately 233 picoseconds). It can represent > dates beginning between 1 January 1900 and 8 February 2036. > > Note that dateTimeMicroseconds and dateTimeNanoseconds share an > identical encoding. There is no restriction on the interpretation of > the Fraction field for the dateTimeNanoseconds data type. > > > > > Standards Track [Page 32] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 6.2. Reduced Size Encoding > > Information Elements encoded as signed, unsigned, or float data types > MAY be encoded using fewer octets than those implied by their type in > the information model definition [RFC5102bis], based on the > assumption that the smaller size is sufficient to carry any value the > Exporter may need to deliver. This reduces the network bandwidth > requirement between the Exporter and the Collector. Note that the > Information Element definitions [RFC5102bis] will always define the > maximum encoding size. > > For instance, the information model [RFC5102bis] defines > octetDeltaCount as an unsigned64 type, which would require 64 bits. > However, if the Exporter will never locally encounter the need to > send a value larger than 4294967295, it may chose to send the value > instead as an unsigned32. For example, a core router would require an > unsigned64 byteCount, while an unsigned32 might be sufficient for an > access router. > > This behavior is indicated by the Exporter by specifying a size in > the Template with a smaller length than that associated with the > assigned type of the Information Element. In the example above, the > Exporter would place a length of 4 versus 8 in the Template. > > If reduced size encoding MAY be be applied to the following integer > types: unsigned64, signed64, unsigned32, signed32, unsigned16, and > signed16. The signed versus unsigned property of the reported value > MUST be preserved. The reduction in size can be to any number of > octets smaller than the original type if the data value still fits, > i.e., so that only leading zeroes are dropped. For example, an > unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). > > Reduced size encoding MAY be used to reduce float64 to float32. The > float32 not only has a reduced number range, but due to the smaller > mantissa, is also less precise. In this case, the float64 would be > reduced in size to 4 octets. > > Reduced size encoding MUST NOT be applied to any other data type > defined in [RFC5102bis] that implies a fixed length, as these types Again, this is a potentially _valid_ 5102bis citation - so a simple s/5102bis/IANA/ isn't appropriate. > either have internal structure (such as ipv4Address or > dateTimeMicroseconds) or restricted ranges that are not suitable for > reduced length encoding (such as dateTimeMilliseconds). > > Information Elements of type octetArray and string may be exported > using any length, subject to restrictions on length specific to each > Information Element, as noted in that Information Element's > description. > > > > > Standards Track [Page 33] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 7. Variable-Length InformationElement Shouldn't it be "elements" ? > > The IPFIX Template mechanism is optimized for fixed-length > Information Elements [RFC5102bis]. Where an Information Element has > a variable length, the following mechanism MUST be used to carry the > length information for both the IETF and proprietary Information > Elements. > > In the Template Set, the Information Element Field Length is recorded > as 65535. This reserved length value notifies the Collecting Process > that length of the Information Element will be carried in the > Information Element content itself. > > In most cases, the length of the Information Element will be less > than 255 octets. The following length-encoding mechanism optimizes > the overhead of carrying the Information Element length in this > majority case. The length is carried in the octet before the > Information Element, as shown in Figure R. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length (< 255)| Information Element | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure R: Variable-Length Information Element (length < 255 octets) > > The length may also be encoded into 3 octets before the Information > element allowing the length of the Information Element to be greater > than or equal to 255 octets. In this case, first octet of the Length > field MUST be 255, and the length is carried in the second and third > octets, as shown in Figure S. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | IE | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure S: Variable-Length Information Element (length 0 to 65535 > octets) > > The octets carrying the length (either the first or the first three > octets) MUST NOT be included in the length of the Information > > > > Standards Track [Page 34] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Element. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Standards Track [Page 35] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 8. Template Management > > This section describes the management of Templates and Options > Templates at the Exporting and Collecting Processes. The goal of > Template management is to ensure,to the extent possible, that the What does that mean / add? > Exporting Process and Collecting Process have a consistent view of > the Templates and Options Templates used to encode and decode the > Records sent from the Exporting Process to the Collecting Process. > Achieving this goal is complicated somewhat by two factors: 1. the > need to support the reuse of Template IDs within a Transport Session > and 2. the need to support unreliable transmission for templates when > UDP is used as the transport protocol for IPFIX Messages. > > The Template Management mechanisms defined in this section apply to > IPFIX Message export on any supported Transport Protocol. Additional > considerations specific to SCTP and UDP transport are given in > sections 8.3 and 8.4, respectively. > > The Exporting Process assigns and maintains the Template IDs per > Transport Session for the Exporter's Observation Domains. A newly Arguably Exporters do not observe, therefore ODs don't belong to Exporters. > created Template Record is assigned an unused Template ID by the > Exporting Process. The Collecting Process MUST store all received > Template Record information for the duration of each Transport > Session until reuse or withdrawal as in section 8.1, except as noted > in section 8.4, so that it can interpret the corresponding Data > Records that are received in subsequent Data Sets. The Collecting > Process MUST NOT assume that the Template IDs from a given Exporting > Process refer to the same Templates as they did in previous Transport > Sessions from the same Exporting Process.When a Transport Session is > closed, the Collecting Process MUST discard all Templates received > over that association and stop decoding IPFIX Messages that use those > Templates. Only if it's doing real-time decode. If it's storing Templates and Records in a database (file) then you absolutely do not want it to discard all the received Templates. > > If a specific Information Element is required by a Template, but is > not present in observed packets, the Exporting ProcessMAY choose to > export Flow Records without this Information Element in a Data Record > defined by a new Template. MAY... else, what are its choices? > > If an Information Element is required more than once in a Template, > the different occurrences of this Information Element SHOULD follow > the logical order of their treatments by the Metering Process. For > example, if a selected packet goes through two hash functions, and if > the two hash values are sent within a single Template, the first > occurrence of the hash value should belong to the first hash function > in the Metering Process. For example, when exporting the two source > IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address > Information Element occurrence should be the IPv4 address of the > outer header, while the second occurrence should be the address of > > > > Standards Track [Page 36] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > the inner header. Collecting processes MUST properly handle Templates > with multiple identical Information Elements. NB this section applies to { first, last } in sections 4.2 and 4.3. > > The Exporting Process SHOULD transmit the Template Set and Options > Template Set in advance of any Data Sets that use that (Options) > Template ID, to help ensure that the Collector has the Template > Record before receiving the first Data Record. Data Records that > correspond to a Template Record MAY appear in the same and/or > subsequent IPFIX Message(s). > > This ensures that the Collecting Process normally receives Template > Records from the Exporting Process before receiving Data Records. > However, if the Template Records have not been received at the time > Data Records are received,the Collecting Process MAY store the Data > Records for a short period of time and decode them after the Template > Records are received. In any case, a Collecting Process MUST NOT > assume that the Data Set and the associated Template Set (or Options > Template Set) are exported in the same IPFIX Message. Store-and-wait only works for reliable and in-order transports. With an unreliable or out-of-order transport, an intervening TWM could have been lost (or still be pending), so the subsequently received Template doesn't apply to the previously received Data Records. So perhaps we should do away with this MAY. Section 8.2 says that Data Records MUST NOT be sent before Templates - although that has no bearing on their arrival time. > > Different Observation Domains from the same Transport Session MAY use > the same Template ID value to refer to different Templates; > Collecting Processes MUST properly handle this case. > > Options Templates and Templates which are related or interdependent > (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent > together in the same IPFIX Message. > > 8.1. Template Withdrawal and Redefinition > > Since a Template may have a lifetime at the Exporting Process > independent of the Transport Session, IPFIX provides a mechanism for > the withdrawal of templates and for the reuse of template IDs. This > mechanism does not apply when UDP is used to transport IPFIX > messages; for this case, see Section 8.4. > > Templates that will not be used further by an Exporting Process MUST > be withdrawn by sending a Template Withdrawal Message.After > receiving a Template Withdrawal, a Collecting Process MUST discard > the Template and stop using it to interpret Data Sets. It mustn't use the Template to interpret further Data Sets. However, it could keep the Template and use it to interpret previously-received Data Sets. > > A Template Withdrawal consists of a Template Record for the Template > ID to be with a Field Count of 0. The format of aTemplate Withdrawal > is shown in Figure T. "A Template Withdrawal Message consists of a Template Record for the Template ID to be withdrawn, with a Field Count of 0." "format of a Template Withdrawal Message..." > > > > > > > > > Standards Track [Page 37] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = (2 or 3) | Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID N | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID ... | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID M | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure T: Template Withdrawal Set Format > > > The Set ID field MUST contain the value 2 forTemplate Set Withdrawal > and the value 3 forOptions Template Set Withdrawal. Multiple We're not withdrawing the (options) Template Set, but rather, the specified (options) Template itself. Inconsistent terminology: "Template Withdrawal Set" (used three times, in the titles of Figures T, U, and V) "Template Set Withdrawal" (used twice here) "Template Withdrawal Message" (used seven times in the text). > Template IDs MAY be withdrawn with a single Template Withdrawal, in > that case, padding MAY be used. This is a comma-splice; it should be a separate sentence. Anyway, why would a TWM be padded? > > A Template Withdrawal Message is an IPFIX Message containing Template > Withdrawals. It withdraws Template IDs for the Observation Domain ID > specified in the IPFIX Message Header.It MUST NOT contain new > Template or Options Template Records, or any Data Sets. The Exporting Why not? A Template could be withdrawn, redefined, used in a new Data Set, then withdrawn again all within a single Message, without any ambiguity. > Process SHOULD NOT send a Template Withdrawal Message until > sufficient time has elapsed to allow receipt and processing of and > Data Records described by the withdrawn Templates; see section 8.2 > for more information on sequencing Template Withdrawals. > > The end of a Transport Session implicitly withdraws all the Templates > used within the Transport Session, and Templates must be resent > during subsequent Transport Sessions between an Exporting Process and > Collecting Process. All Templates for a given Observation Domain MAY > also be withdrawn using an All Templates Withdrawal, which withdraws "All Templates Withdrawal Message" > the special Template ID 2; this is shown in Figure U. All Options No it doesn't. > Templates for a given observation Domain MAY likewise be withdrawn > using an All Options Templates Withdrawal,which withdraws the > special Template ID 3. Each of these Withdrawals MUST appear in a No it doesn't. Template IDs 2 and 3 have particular meanings in IPFIX, they're part of a reserved range (section 3.4.1). Exporters do not send Templates 2 and 3, so these cannot be withdrawn. Also, Template IDs 2 and 3 aren't "special", they're "reserved". > Template Withdrawal Message with no other Withdrawals. > > > > > > > > > > > > > Standards Track [Page 38] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 2 | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure U: All Templates Withdrawal Set Format > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 3 | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure V: All Options Templates Withdrawal Set Format Figure V is unreferenced. > > > Template IDs MAY be reused for new Templates by sending a new > Template Record or Options Template Record for a given Template ID > after withdrawing the Template. > > If a Collecting Process receives a new Template Record or Options > Template Record for an already-allocated Template ID, without having > received awithdrawal, it MUST ignore thenew Template Record and This should say, "a TWM for that (options) Template Record". "it MUST ignore the new (options) Template Record and" > discard the old Template Record for the allocated ID; it SHOULD log "discard the old (options) Template Record" So this is basically a DoS vector? ie, if I can inject bogus Templates towards the collector, then it must discard both the bogus Template and the perfectly good Template, and therefore stop collecting data. > the error. > > If a Collecting Process receives aTemplate Withdrawal for a Template "Template Withdrawal Message" > or Options Template it does not presently have stored, it MUST ignore > theTemplate Withdrawal and SHOULD log the error. "Template Withdrawal Message" > > 8.2 Sequencing Template Management Actions > > Since there is no guarantee of the ordering of exported IPFIX > Messages across SCTP Streams or over UDP, an Exporting Process MUST > sequence all template management actions (i.e., Template Records > defining new templates andTemplate Withdrawals withdrawing them) "Template Withdrawal Messages" > using the Export Time field in the IPFIX Message Header. So CPs must respect the Export Time rather than the delivery (arrival) order? Is there some sort of time flux going on here? > > An Exporting Process MUST NOT export a Data Set described by a new > Template in an IPFIX Message with an Export Time before the Export > Time of the IPFIX Message containing that Template. If a new Template In simpler words, Templates must be sent before Data Sets. Or if they're not, then at least the later-sent Templates must have earlier Export Times. OK, I see how the time flux works. Except, this contradicts store-and-wait in Section 8. Unless we're talking about the corner-corner case of Template is sent, CP restarts, Data is sent. > and a Data Set described by it appear in the same IPFIX Message, the > > > > Standards Track [Page 39] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Template Set containing the Template MUST appear before the Data Set > in the Message. > > An Exporting Process MUST NOT export any Data Sets described by a > withdrawn Template in IPFIX Messages with an Export Time after the > Export Time of theIPFIX Message containing the Template Withdrawal "Export Time of the TWM". > withdrawing that Template. Flux capacitor to the rescue again: you're saying that such Data Sets can be sent after the TWM provided their Export Time is earlier. > > Put another way, a Template only describes Records contained in IPFIX Because the previous way was too complicated for mortals to comprehend :-( > Messages with the same Export Time as the IPFIX Message containing > Template Record, or a subsequent export time. Likewise,a Template > Withdrawal is only in effect for IPFIX Messages with the same Export > Time as the Template Withdrawal, or a subsequent Export Time. No, a TWM does not withdraw subsequent templates. > Collecting Processes MAY implement a buffer to handle out-of-order > Template management events. How exactly do you envisage that working? Put events in the buffer, sorted by time, and pop the topmost event after allowing some time delta? This whole section became too confusing and unclear, so even I can barely understand it :-( > > 8.3. Additional considerations for Template Management over SCTP > > Template Sets and Options Template Sets MAY be sent on any SCTP > stream. Data Sets sent on a given SCTP stream MAY be represented by > Template Records exported on any SCTP stream. xref RFC6526 (per stream) here. > > Template Sets and Options Template Sets MUST be sent reliably andin > order. Why must they be in order? As long as they arrive before their corresponding Data Sets - unless an option is scoped to another option or a Template? > > Template Withdrawal Messages MAY be sent on any SCTP stream. Template > Withdrawal Messages MUST be sent reliably, usingSCTP-ordered Why is that hyphenated? > delivery. Template IDs MAY be reused by sending a Template Withdrawal > Message and/or a new Template Record on a different SCTP stream than > the stream on which the original Template was sent. No. A Template can't be redefined simply by sending a new Template definition on another stream. With SCTP, the EP must explicitly withdraw the template before redefining it. > > Additional Template Management considerations are given in [IPFIX- > PER-SCTP-STREAM], which specifies an extension to explicitly link RFC6526. > Templates with SCTP streams. In exchange for more restrictive rules > on the assignment of Template Records to SCTP streams, this extension > allows fast, reliable reuse of Template IDs and estimation of Data > Record loss per Template. > > 8.4. Additional considerations for Template Management over UDP > > Since UDP provides no method for reliable transmission of Templates, > Exporting Processes using UDP as the Transport Protocol MUST > periodically retransmit each active Template at regular intervals. > The template retransmission interval MUST be configurable, as via the > the templateRefreshTimeout and optionsTemplateRefreshTimeout defined > in [IPFIX-CONF]. Default settings for these values are deployment- > and application-specific. > > > > Standards Track [Page 40] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Before exporting any Data Records described by a given Template > Record or Options Template Record, especially in the case of Template > ID reuse as in section 8.1, the Exporting Process SHOULD send > multiple copies of the Template Record in separate IPFIXMessage, in > order to help ensure the Collecting Process has received it. "Messages" plural. Or more simply, prefix the Data Set with the corresponding Template. > > In order to minimize resource requirements for templates which have > expired at the Exporting Process without being withdrawn, or in cases > when the Template Withdrawal Message was lost between the Exporting > Process and the Collecting Process, the Collecting Process MAY > associate a lifetime with each Template received in a UDP Transport > Session. Templates not refreshed by the Exporting Process within the > lifetime can then be discarded by the Collecting Process. The > template lifetime at the Collecting Process MAY be exposed by a > configuration parameter, or MAY be derived from observation of the > interval of periodic Template retransmissions from the Exporting > Process. In this latter case, the Template lifetime SHOULD default to > at least 3 times the observed retransmission rate. The EP should export an option indicating the template lifetime it's using. > > As template IDs are unique per UDP session and per Observation > Domain, at any given time, the Collecting Process SHOULD maintain the > following for all the current Template Records and Options Template > Records: ID, Template ID, Template Definition,Last Received>. "IPFIX Device" == Exporter source address? "Last Received" - is this the last received template definition, a byte count, a boolean, a timestamp, or some combination of these? > > 9. The Collecting Process's Side > > This section describes the handling of the IPFIX Protocol at the > Collecting Process common to all Transport Protocols. Additional > considerations for SCTP and UDP are given in Sections 9.1 and 9.2 > respectively. Template management at Collecting Processes is covered > in Section 8. > > The Collecting Process MUST listen for association requests / > connections to start new Transport Sessions from the Exporting > Process. > > The Collecting Process MUST note the Information Element identifier > of any Information Element that it does not understand and MAY > discard that Information Element fromthe Flow Record. From Flow Records, plural. > > The Collecting Process MUST accept padding in Data Records and > Template Records. The padding size is the Set Length minus the size > of the Set Header (4 octets for the Set ID and the Set Length), > modulo the Record size deduced from the Template Record. Is this shown in any figures? > > The IPFIX protocol has a Sequence Number field in the Export header > that increases with the number of IPFIX Data Records in the IPFIX > > > > Standards Track [Page 41] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Message. The Collecting Process MAY detect out-of-sequence, dropped, > or duplicate IPFIX Messages using this the Sequence Number. If it > supports this mechanism, the Collecting Process SHOULD log > out-of-sequence IPFIX Messages, as these could indicate resource > exhaustion at the Exporting Process or the Collecting Process, an > Exporting Process reset, packet loss due to congestion between the > Exporting Process and the Collecting Process, or message injection. > > If the Collecting Process receives a malformed IPFIX Message, it MUST > discard the IPFIX Message and SHOULD log the error. Note that non- > zero Set padding does not constitute a malformed IPFIX Message. What does constitute a malformed message? Some examples would be useful. > > 9.1. Additional considerations for SCTP Collecting Processes > > The Exporting Process requests a number of streams to use for export > at association setup time. An Exporting Process MAY request and > support more than one stream per SCTP association. > > 9.2. Additional considerations for UDP Collecting Processes > > A Transport Session for IPFIX Messages transported over UDP is > defined from the point of view of the Exporting Process, and roughly > corresponds to the time during which a given Exporting Process sends > IPFIX messages over UDP to a given Collecting Process. Since this is > difficult to detect at the Collecting Process,the Collecting Process > MAY expire all Transport Session state after no IPFIX Messages are > received from a given Exporting Process during a configurable idle > timeout. That's not quite accurate: the EP may have multiple transport sessions. The CP may expire a particular transport session's state regardless of whether IPFIX Messages continue to be exported for other transport sessions from the EP. > > The Collecting Process SHOULD accept Data Records without the > associated Template Record (or other definitions) required to decode > the Data Record. If the Template Records (or other definitions such > as Common Properties) have not been received at the time Data Records > are received, the Collecting Process SHOULD store the Data Records > for a short period of time and decode them after the Template Records > (or other definitions) are received. The short period of time MUST > be lower than the lifetime of definitions associated with identifiers > considered unique within the UDP session. Per earlier comments, I think this is dangerous and we should do away with it. > 10. Transport Protocol > > The IPFIX Protocol Specification has been designed to be transport > protocol independent. Note that the Exporter can export to multiple > Collecting Processes using independent transport protocols. > > The IPFIX Message Header 16-bit Length field limits the length of an > IPFIX Message to 65535 octets, including the header. A Collecting > Process MUST be able to handle IPFIX Message lengths of up to 65535 > > > > Standards Track [Page 42] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > octets. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Standards Track [Page 43] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 10.1. Transport Compliance and Transport Usage > > SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] > MUST be implemented by all compliant implementations. UDP [UDP] MAY > also be implemented by compliant implementations. TCP [TCP] MAY also > be implemented by compliant implementations. > > SCTP SHOULD be used in deployments where Exporters and Collectors are > communicating over links that are susceptible to congestion. PR-SCTP > is capable of providing any required degree of reliability. > > TCP MAY be used in deployments where Exporters and Collectors > communicate over links that are susceptible to congestion, but SCTP > is preferred due to its ability to limit back pressure on Exporters > and its message versus stream orientation. > > UDP MAY be used, although it is not a congestion-aware protocol. > However, in this case the IPFIX traffic between Exporter and > Collector MUST be separately contained or provisioned to minimize the > risk of congestion-related loss. > > 10.2. SCTP > > This section describes how IPFIX is transported over SCTP [RFC4960] > using the PR-SCTP [RFC3758] extension. > > 10.2.1. Congestion Avoidance > > The SCTP transport protocol provides the required level of congestion > avoidance by design. > > SCTP will detect congestion in the end-to-end path between the IPFIX > Exporting Process and the IPFIX Collecting Process, and limit the > transfer rate accordingly. When an IPFIX Exporting Process has > records to export, but detects that transmission by SCTP is > temporarily impossible, it can either wait until sending is possible > again, or it can decide to drop the record. In the latter case, the > dropped export data MUST be accounted for, so that the amount of > dropped export data can be reported. Say where it's accounted, ie in the Exporting Process Reliability Statistics Options Template (section 4.3). > > 10.2.2. Reliability > > The SCTP transport protocol is by default reliable, but has the > capability to deliver messages with partial reliability [RFC3758]. > > Using reliable SCTP messages for the IPFIX export is not in itself a > guarantee that all Data Records will be delivered. If there is > congestion on the link from the Exporting Process to the Collecting > > > > Standards Track [Page 44] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Process, or if a significant number of retransmissions are required, > the send queues on the Exporting Process may fill up; the Exporting > Process MAY either suspend, export, or discard the IPFIX Messages. > If Data Records are discarded the IPFIX Sequence Numbers used for > export MUST reflect the loss of data. > > 10.2.3. MTU > > SCTP provides the required IPFIX Message fragmentation service based > on path MTU discovery. > > 10.2.4. Association Establishment and Shutdown > > The IPFIX Exporting Process SHOULD initiate an SCTP association with > the IPFIX Collecting Process. By default, the Collecting Process > listens for connections onSCTP port 4739. By default, the > Collecting Process listens for secure connections onSCTP port 4740 xref IANA for the ports. ie, http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml > (refer to the Security Considerations section). By default, the > Exporting Process tries to connect to one of these ports.It MUST be > possible to configure both the Exporting and Collecting Processes to > use a different SCTP port. A different port from the default; not a different port from each other! Since this paragraph is repeated for UDP and TCP, why not put it in the generic section above? > > The Exporting Process MAY establish more than one association > (connection "bundle" in SCTP terminology) to the Collecting Process. > > An Exporting Process MAY support more than one active association to > different Collecting Processes (including the case of different > Collecting Processes on the same host). > > When an Exporting Process is shut down, it SHOULD shut down the SCTP > association. > > When a Collecting Process no longer wants to receive IPFIX Messages, > it SHOULD shut down its end of the association. The Collecting > Process SHOULD continue to receive and process IPFIX Messages until > the Exporting Process has closed its end of the association. > > When a Collecting Process detects that the SCTP association has been > abnormally terminated, it MUST continue to listen for a new > association establishment. > > When an Exporting Process detects that the SCTP association to the > Collecting Process is abnormally terminated, it SHOULD try to > re-establish the association. > > Association timeouts SHOULD be configurable. > > > > > > Standards Track [Page 45] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 10.2.5. Failover > > If the Collecting Process does not acknowledge the attempt by the > Exporting Process to establish an association, the Exporting Process > should retry using the SCTP exponential backoff feature. The > Exporter MAY log an alarm if the time to establish the association > exceeds a specified threshold, configurable on the Exporter. > > If Collecting Process failover is supported by the Exporting Process, > a second SCTP association MAY be opened in advance. > > 10.2.6. Streams > > An Exporting Process MAY request more than one SCTP stream per > association. Each of these streams may be used for the transmission > of IPFIX Messages containing Data Sets, Template Sets, and/or Options > Template Sets. > > Depending on the requirements of the application, the Exporting > Process may send Data Sets with full or partial reliability, using > ordered or out-of-order delivery, over any SCTP stream established > during SCTP Association setup. > > An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as > per Section 4 of the PR-SCTP [RFC3758] specification when using > partial reliability to transmit IPFIX Messages containing only Data > Sets. > > However, Exporting Processes SHOULD mark such IPFIX Messages for > retransmission for as long as resource or other constraints allow. > > 10.3. UDP > > This section describes how IPFIX is transported over UDP [UDP]. > > 10.3.1. Congestion Avoidance > > UDP has no integral congestion-avoidance mechanism. Its use over > congestion-sensitive network paths is therefore not recommended. UDP > MAY be used in deployments where Exporters and Collectors always > communicate over dedicated links that are not susceptible to > congestion, i.e., links that are over-provisioned compared to the > maximum export rate from the Exporters. > > 10.3.2. Reliability > > UDP is not a reliable transport protocol, and cannot guarantee > delivery of messages. IPFIX Messages sent from the Exporting Process > > > > Standards Track [Page 46] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > to the Collecting Process using UDP may therefore be lost. UDP MUST > NOT be used unless the application can tolerate some loss of IPFIX > Messages. > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the UDP Transport Session > prior to the receipt of this IPFIX Message, modulo 2^32. A Collector > SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages > by tracking the Sequence Number. Templates sent from the Exporting > Process to the Collecting Process using UDP as a transport MUST be > re-sent at regular intervals, in case previous copies were lost. Or in case the CP (re)started. > > Exporting Processes exporting IPFIX Messages via UDP MUST include a > valid UDP checksum. > > 10.3.3. MTU > > The maximum size of exported messages MUST be configured such that > the total packet size does not exceed the path MTU. If the path MTU > is unknown, a maximum packet size of 512 octets SHOULD be used. > > 10.3.4. Session Establishment and Shutdown > > By default, the Collecting Process listens on the UDP port 4739. By > default, the Collecting Process listens for secure connections on UDP > port 4740 (refer to the "Security Considerations" section). By > default, the Exporting Process tries to connect to one of these > ports. It MUST be possible to configure both the Exporting and > Collecting Processes to use a different UDP port. This is just repetition of 10.2.4. > > As UDP is a connectionless protocol, there is no real session > establishment or shutdown for IPFIX over UDP. An Exporting Process > starts sending IPFIX Messages to a Collecting Process at one point in > time, and stops sending them at another point in time. This leads to > some complications in template management, which are outlined in > Section 8.4 above. > > 10.3.5. Failover and Session Duplication > > Because UDP is not a connection-oriented protocol, the Exporting > Process is unable to determine from the transport protocol that the > Collecting Process is no longer able to receive the IPFIX Messages. > Therefore, it cannot invoke a failover mechanism. However, the > Exporting Process MAY duplicate the IPFIX Message to several > Collecting Processes. > > > > > Standards Track [Page 47] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 10.4. TCP > > The IPFIX Exporting Process initiates a TCP connection to the > Collecting Process. By default, the Collecting Process listens for > connections on TCP port 4739. By default, the Collecting Process > listens for secure connections on TCP port 4740 (refer to the > Security Considerations section). By default, the Exporting Process > tries to connect to one of these ports. It MUST be possible to > configure both the Exporting Process and the Collecting Process to > use a different TCP port. This is just repetition of 10.2.4 and 10.3.4. > > An Exporting Process MAY support more than one active connection to > different Collecting Processes (including the case of different > Collecting Processes on the same host). > > The Exporter MAY log an alarm if the time to establish the connection > exceeds a specified threshold, configurable on the Exporter. > > 10.4.1. Congestion Avoidance > > TCP controls the rate at which data can be sent from the Exporting > Process to the Collecting Process, using a mechanism that takes into > account both congestion in the network and the capabilities of the > receiver. > > Therefore, an IPFIX Exporting Process may not be able to send IPFIX > Messages at the rate that the Metering Process generates it, either > because of congestion in the network or because the Collecting > Process cannot handle IPFIX Messages fast enough. As long as > congestion is transient, the Exporting Process can buffer IPFIX > Messages for transmission. But such buffering is necessarily limited, > both because of resource limitations and because of timeliness > requirements, so ongoing and/or severe congestion may lead to a > situation where the Exporting Process is blocked. If IPFIX Messages are delayed (whether in the EP, or in the network stack), should/must their header Export Time be rewritten? In the latter (stack) case, this may not even be possible. > > When an Exporting Process has Data Records to export but the > transmission buffer is full, and it wants to avoid blocking, it can > decide to drop some Data Records.The dropped Data Records MUST be > accounted for, so that the number of lost records can later be > exported as in Section 4.3. Say how they're accounted. > > When an Exporting Process finds that the rate at which records should > be exported is consistently higher than the rate at which TCP sending > permits, it SHOULD provide back pressure to the Metering Processes. > The Metering Process could then adapt by temporarily reducing the > amount of data it generates, for example, using sampling or > aggregation. That has it's own issues, eg sampling is introduced or sampling rate changes -> data records can't be aggregated with previous records at the collector, until they're normalised. Anyway, although sampling means the counts will be lower, the flow records will still exist - so the export bandwidth won't change much. The EP needs less flow records, as opposed to smaller counts within each record. > > > > > Standards Track [Page 48] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 10.4.2. Reliability > > TCP ensures reliable delivery of data from the Exporting Process to > the Collecting Process. > > In the case of TCP, the IPFIX Sequence Number contains the total > number of IPFIX Data Records sent from this TCP connection, from the > current Observation Domain by the Exporting Process, prior to the > receipt of this IPFIX Message, modulo 2^32. This is called out as if it's somehow different, which is misleading: this is unchanged regardless of transport, so it should be stated once generically. > 10.4.3. MTU > > As TCP offers a stream service instead of a datagram or sequential > packet service, IPFIX Messages transported over TCP are instead > separated using the Length field in the IPFIX Message Header. The > Exporting Process can choose any valid length for exported IPFIX > Messages, as TCP handles segmentation. > > However, if an Exporting Process exports data from multiple > Observation Domains, it should be careful to choose IPFIX Message > lengths appropriatelyto minimize head-of-line blocking between > different Observation Domains. Multiple TCP connections MAY be used > to avoid head-of-line blocking between different Observation Domains. > > 10.4.4. Connection Establishment, Shutdown, and Restart > > The IPFIX Exporting Process initiates a TCP connection to the > Collecting Process. By default, the Collecting Process listens for > connections on TCP port 4739. By default, the Collecting Process > listens for secure connections on TCP port 4740 (refer to the > Security Considerations section). By default, the Exporting Process > tries to connect to one of these ports. It MUST be possible to > configure both the Exporting Process and the Collecting Process to > use a different TCP port. This is unnecessary repetition of 10.2.4, 10.3.4, and 10.4. > > An Exporting Process MAY support more than one active connection to > different Collecting Processes (including the case of different > Collecting Processes on the same host). > > The Exporter MAY log an alarm if the time to establish the connection > exceeds a specified threshold, configurable on the Exporter. > > When an Exporting Process is shut down, it SHOULD shut down the TCP > connection. > > When a Collecting Process no longer wants to receive IPFIX Messages, > it SHOULD close its end of the connection. The Collecting Process > SHOULD continue to read IPFIX Messages until the Exporting Process > > > > Standards Track [Page 49] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > has closed its end. > > When a Collecting Process detects that the TCP connection to the > Exporting Process has terminated abnormally, it MUST continue to > listen for a new connection. > > When an Exporting Process detects that the TCP connection to the > Collecting Process has terminated abnormally, it SHOULD try to > re-establish the connection. Connection timeouts and retry schedules > SHOULD be configurable. In the default configuration, an Exporting > Process MUST NOT attempt to establish a connection more frequently > than once per minute. > > 10.4.5. Failover > > If the Collecting Process does not acknowledge the attempt by the > Exporting Process to establish a connection, it will retry using the > TCP exponential backoff feature. > > If Collecting Process failover is supported by the Exporting Process, > a second TCP connection MAY be opened in advance. > > 11. Security Considerations > > The security considerations for the IPFIX protocol have been derived > from an analysis of potential security threats, as discussed in the > "Security Considerations" section of IPFIX requirements [RFC3917]. > The requirements for IPFIX security are as follows: > > 1. IPFIX must provide a mechanism to ensure the confidentiality of > IPFIX data transferred from an Exporting Process to a Collecting > Process, in order to prevent disclosure of Flow Records > transported via IPFIX. > > 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX > data transferred from an Exporting Process to a Collecting > Process, in order to prevent the injection of incorrect data or > control information (e.g., Templates) into an IPFIX Message > stream. > > 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting > and Exporting Processes, to prevent the collection of data from an > unauthorized Exporting Process or the export of data to an > unauthorized Collecting Process. > > Because IPFIX can be used to collect information for network > forensics and billing purposes, attacks designed to confuse, disable, > or take information from an IPFIX collection system may be seen as a > > > > Standards Track [Page 50] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > prime objective during a sophisticated network attack. > > An attacker in a position to inject false messages into an IPFIX > Message stream can either affect the application using IPFIX (by > falsifying data), or the IPFIX Collecting Process itself (by > modifying or revoking Templates, or changing options); for this > reason, IPFIX Message integrity is important. > > The IPFIX Messages themselves may also contain information of value > to an attacker, including information about the configuration of the > network as well as end-user traffic and payload data, so care must be > taken to confine their visibility to authorized users. When an > Information Element containing end-user payload information is > exported, it SHOULD be transmitted to the Collecting Process using a > means that secures its contents against eavesdropping. Suitable > mechanisms include the use of either a direct point-to-point > connection or the use of an encryption mechanism. It is the > responsibility of the Collecting Process to provide a satisfactory > degree of security for this collected data, including, if necessary, > anonymization of any reported data. > > 11.1. Applicability of TLS and DTLS > > Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer > Security (DTLS) [RFC4347] were designed to provide the > confidentiality, integrity, and authentication assurances required by > the IPFIX protocol, without the need for pre-shared keys. > > With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC4347] > MUST be implemented. If UDP is selected as the IPFIX transport > protocol, DTLS [RFC4347] MUST be implemented. If TCP is selected as > the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. > > Note that DTLS is selected as the security mechanism for SCTP. > Though TLS bindings to SCTP are defined in [RFC3436], they require > all communication to be over reliable, bidirectional streams, and > require one TLS connection per stream. This arrangement is not > compatible with the rationale behind the choice of SCTP as an IPFIX > transport protocol. > > Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man > in the middle may attempt to take data out of an association and fool > the sender into thinking that the data was actually received by the > peer. In generic TLS for SCTP (and/or TCP), this is not possible. > This means that the removal of a message may become hidden from the > sender or receiver. Another vulnerability of using SCTP with DTLS is > that someone could inject SCTP control information to shut down the > SCTP association, effectively generating a loss of IPFIX Messages if > > > > Standards Track [Page 51] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > those are buffered outside of the SCTP association. Techniques such > as [RFC6083] could be used to overcome these vulnerabilities. > > When using DTLS over SCTP, the Exporting Process MUST ensure that > each IPFIX Message is sent over the same SCTP stream that would be > used when sending the same IPFIX Message directly over SCTP. Note > that DTLS may send its own control messages on stream 0 with full > reliability; however, this will not interfere with the processing of > stream 0 IPFIX Messages at the Collecting Process, because DTLS > consumes its own control messages before passing IPFIX Messages up to > the application layer. > > When using DTLS over SCTP or UDP, the HeartbeatExtention [RFC6520] Extension. > SHOULD be used, especially on long-lived Transport Sessions, to > ensure that the association remains active. > > 11.2. Usage > > The IPFIX Exporting Process initiates the communication to the IPFIX > Collecting Process, and acts as a TLS or DTLS client according to NB wrong indentation. > [RFC5246] and [RFC4347], while the IPFIX Collecting Process acts as a > TLS or DTLS server. The DTLS client opens a secure connection on the > SCTP port 4740 of the DTLS server if SCTP is selected as the > transport protocol. The TLS client opens a secure connection on the > TCP port 4740 of the TLS server if TCP is selected as the transport > protocol. The DTLS client opens a secure connection on the UDP port > 4740 of the DTLS server if UDP is selected as the transport > protocol. Cite IANA for port 4740. > > 11.3. Authentication > > IPFIX Exporting Processes and IPFIX Collecting Processes are > identified by the fully qualified domain name of the interface on > which IPFIX Messages are sent or received, for purposes of X.509 > client and server certificates as in [RFC5280]. > > To prevent man-in-the-middle attacks from impostor Exporting or > Collecting Processes, the acceptance of data from an unauthorized > Exporting Process, or the export of data to an unauthorized > Collecting Process, strong mutual authentication via asymmetric keys > MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and > Collecting Processes MUST verify the identity of its peer against its > authorized certificates, and MUST verify that the peer's certificate > matches its fully qualified domain name, or, in the case of SCTP, the > fully qualified domain name of one of its endpoints. > > > > > > > Standards Track [Page 52] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > The fully qualified domain name used to identify an IPFIX Collecting > Process or Exporting Process may be stored either in a subjectAltName > extension of type dNSName, or in the most specific Common Name field > of the Subject field of the X.509 certificate. If both are present, > the subjectAltName extension is given preference. > > Internationalized domain names (IDN) in either the subjectAltName > extension of type dNSName or the most specific Common Name field of > the Subject field of the X.509 certificate MUST be encoded using > Punycode [RFC3492] as described in [RFC5891], "Conversion > Operations". > > 11.4. Protection against DoS Attacks > > An attacker may mount a denial-of-service (DoS) attack against an > IPFIX collection system either directly, by sending large amounts of > traffic to a Collecting Process, or indirectly, by generating large > amounts of traffic to be measured by a Metering Process. > > Direct denial-of-service attacks can also involve state exhaustion, > whether at the transport layer (e.g., by creating a large number of > pending connections), or within the IPFIX Collecting Process itself > (e.g., by sending Flow Records pending Template or scope information, > a large amount of Options Template Records, etc.). > > SCTP mandates a cookie-exchange mechanism designed to defend against > SCTP state exhaustion denial-of-service attacks. Similarly, TCP > provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN > cookies SHOULD be used by any Collecting Process accepting TCP > connections. DTLS also provides cookie exchange to protect against > DTLS server state exhaustion. > > The reader should note that there is no way to prevent fake IPFIX > Message processing (and state creation) for UDP & SCTP communication. > The use of TLS and DTLS can obviously prevent the creation of fake NB wrong indentation. > states, but they are themselves prone to state exhaustion attacks. > Therefore, Collector rate limiting SHOULD be used to protect TLS & > DTLS (like limiting the number of new TLS or DTLS session per second > to a sensible number). > > IPFIX state exhaustion attacks can be mitigated by limiting the rate > at which new connections or associations will be opened by the > Collecting Process, the rate at which IPFIX Messages will be accepted > by the Collecting Process, and adaptively limiting the amount of > state kept, particularly records waiting on Templates. These rate > and state limits MAY be provided by a Collecting Process; if > provided, the limits SHOULD be user configurable. > > > > > Standards Track [Page 53] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Additionally, an IPFIX Collecting Process can eliminate the risk of > state exhaustion attacks from untrusted nodes by requiring TLS or > DTLS mutual authentication, causing the Collecting Process to accept > IPFIX Messages only from trusted sources. > > With respect to indirect denial of service, the behavior of IPFIX > under overload conditions depends on the transport protocol in use. > For IPFIX over TCP, TCP congestion control would cause the flow of > IPFIX Messages to back off and eventually stall, blinding the IPFIX > system. SCTP improves upon this situation somewhat, as some IPFIX > Messages would continue to be received by the Collecting Process due > to the avoidance of head-of-line blocking by SCTP's multiple streams > and partial reliability features, possibly affording some visibility > of the attack. The situation is similar with UDP, as some datagrams > may continue to be received at the Collecting Process, effectively > applying sampling to the IPFIX Message stream, implying that some > forensics may be left. > > To minimize IPFIX Message loss under overload conditions, some > mechanism for service differentiation could be used to prioritize > IPFIX traffic over other traffic on the same link. Alternatively, > IPFIX Messages can be transported over a dedicated network. In this > case, care must be taken to ensure that the dedicated network can > handle the expected peak IPFIX Message traffic. > > 11.5. When DTLS or TLS Is Not an Option > > The use of DTLS or TLS might not be possible in some cases due to > performance issues or other operational concerns. > > Without TLS or DTLS mutual authentication, IPFIX Exporting Processes > and Collecting Processes can fall back on using IP source addresses > to authenticate their peers. A policy of allocating Exporting > Process and Collecting Process IP addresses from specified address > ranges, and using ingress filtering to prevent spoofing, can improve > the usefulness of this approach. Again, completely segregating IPFIX > traffic on a dedicated network, where possible, can improve security > even further. In any case, the use of open Collecting Processes > (those that will accept IPFIX Messages from any Exporting Process > regardless of IP address or identity) is discouraged. > > Modern TCP and SCTP implementations are resistant to blind insertion > attacks (see [RFC1948], [RFC4960]); however, UDP offers no such > protection. For this reason, IPFIX Message traffic transported via > UDP and not secured via DTLS SHOULD be protected via segregation to a > dedicated network. > > > > > > Standards Track [Page 54] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > 11.6. Logging an IPFIX Attack > > IPFIX Collecting Processes MUST detect potential IPFIX Message > insertion or loss conditions by tracking the IPFIX Sequence Number, > and SHOULD provide a logging mechanism for reporting out-of-sequence > messages. Note that an attacker may be able to exploit the handling > of out-of-sequence messages at the Collecting Process, so care should > be taken in handling these conditions. For example, a Collecting > Process that simply resets the expected Sequence Number upon receipt > of a later Sequence Number could be temporarily blinded by deliberate > injection of later Sequence Numbers. > > IPFIX Exporting and Collecting Processes SHOULD log any connection > attempt that fails due to authentication failure, whether due to > being presented an unauthorized or mismatched certificate during TLS > or DTLS mutual authentication, or due to a connection attempt from an > unauthorized IP address when TLS or DTLS is not in use. > > IPFIX Exporting and Collecting Processes SHOULD detect and log any > SCTP association reset or TCP connection reset. > > 11.7. Securing the Collector > > The security of the Collector and its implementation is important to > achieve overall security. However, it is outside the scope of this > document. > > 12. IANA Considerations > > IPFIX Messages use two fields with assigned values. These are the > IPFIX Version Number, indicating which version of the IPFIX Protocol > was used to export an IPFIX Message, and the IPFIX Set ID, indicating > the type for each set of information within an IPFIX Message. > > The IPFIX Version Number value of 10 is reserved for the IPFIX > protocol specified in this document. Set ID values of 0 and 1 are > not used for historical reasons [RFC3954]. The Set ID value of 2 is Again, "not used for historical reasons" is ambiguous (ie, could be used for other reasons). > reserved for the Template Set. The Set ID value of 3 is reserved for > the Options Template Set. All other Set ID values from 4 to 255 are > reserved for future use. Set ID values above 255 are used for Data > Sets. > > New assignments in either IPFIX Version Number or IPFIX Set ID > assignments require a Standards Action [RFC5226], i.e., they are to > be made via Standards Track RFCs approved by the IESG. > > > > > > > Standards Track [Page 55] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Appendix A. IPFIX Encoding Examples > > This appendix, which is a not a normative reference, contains IPFIX > encoding examples. > > Let's consider the example of an IPFIX Message composed of a > Template Set, a Data Set (which contains three Data Records), an > Options Template Set and a Data Set (which contains 2 Data Records > related to the previous Options Template Record). > > IPFIX Message: > > +--------+------------------------------------------. . . > | | +--------------+ +------------------+ > |Message | | Template | | Data | > | Header | | Set | | Set | . . . > | | | (1 Template) | | (3 Data Records) | > | | +--------------+ +------------------+ > +--------+------------------------------------------. . . > > . . .-------------------------------------------+ > +------------------+ +------------------+ | > | Options | | Data | | > . . . | Template Set | | Set | | > | (1 Template) | | (2 Data Records) | | > +------------------+ +------------------+ | > . . .-------------------------------------------+ > > A.1. Message Header Example > > The Message Header is composed of: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 0x000a | Length = 152 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Standards Track [Page 56] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A.2. Template Set Examples > > A.2.1. Template Set Using IETF-Specified Information Elements > > > We want to report the following Information Elements: > > - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], > with a length of 4 octets > > - The IPv4 destination IP address: destinationIPv4Address in > [RFC5102bis], with a length of 4 octets > > - The next-hop IP address (IPv4): ipNextHopIPv4Address in > [RFC5102bis], with a length of 4 octets > > - The number of packets of the Flow: packetDeltaCount in > [RFC5102bis], with a length of 4 octets > > - The number of octets of the Flow: octetDeltaCount in > [RFC5102bis], with a length of 4 octets > > Therefore, the Template Set will be composed of the following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 28 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ipNextHopIPv4Address = 15 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetDeltaCount = 2 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A.2.2. Template Set Using Enterprise-Specific Information Elements > > We want to report the following Information Elements: > > - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with > a length of 4 octets > > > > Standards Track [Page 57] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > - The IPv4 destination IP address: destinationIPv4Address in > [RFC5102bis], with a length of 4 octets > > - An enterprise-specific Information Element representing > proprietary information, with a type of 15 and a length of 4 > > - The number of packets of the Flow: packetDeltaCount in > [RFC5102bis], with a length of 4 octets > > - The number of octets of the Flow: octetDeltaCount in [RFC5102bis], "in [RFC" is double-spaced. > with a length of 4 octets > > Therefore, the Template Set will be composed of the following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 32 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 257 | Field Count = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Information Element Id. = 15| Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetDeltaCount = 2 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > > > > > > > > Standards Track [Page 58] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A.3. Data Set Example > > In this example, we report the following three Flow Records: > > Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets > | | | Number | Number > ------------------------------------------------------------------ > 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 > 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 > 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 64 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.254 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5009 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5344385 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.27 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.23 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 748 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 388934 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.56 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.65 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 6534 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that padding is not necessary in this example. > > > > Standards Track [Page 59] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A.4. Options Template Set Examples > > A.4.1. Options Template Set Using IETF-Specified Information Elements > > > Per line card (the router being composed of two line cards), we want > to report the following Information Elements: > > - Total number of IPFIX Messages: exportedMessageTotalCount > [RFC5102bis], with a length of 2 octets > > - Total number of exported Flows: exportedFlowRecordTotalCount > [RFC5102bis], with a length of 2 octets > > The line card, which is represented by the lineCardId Information > Element [RFC5102bis], is used as the Scope Field. > > Therefore, the Options Template Set will be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 258 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| lineCardId = 141 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A.4.2. Options Template Set Using Enterprise-Specific Information > Elements > > Per line card (the router being composed of two line cards), we want > to report the following Information Elements: > > - Total number of IPFIX Messages: exportedMessageTotalCount > [RFC5102bis], with a length of 2 octets > > - An enterprise-specific number of exported Flows, with a type of > 42 and a length of 4 octets > > The line card, which is represented by the lineCardId Information > > > > Standards Track [Page 60] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Element [RFC5102bis], is used as the Scope Field. > > The format of the Options Template Set is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 28 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 259 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| lineCardId = 141 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |1|Information Element Id. = 42 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | Enterprise number ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... Enterprise number | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A.4.3. Options Template Set Using an Enterprise-Specific Scope > > In this example, we want to export the same information as in the > example in Section A.4.1: > > - Total number of IPFIX Messages: exportedMessageTotalCount > [RFC5102bis], with a length of 2 octets > > - Total number of exported Flows: exportedFlowRecordTotalCount > [RFC5102bis], with a length of 2 octets > > But this time, the information pertains to a proprietary scope, > identified by enterprise-specific Information Element number 123. > > > > > > > > > > > > > > > > > Standards Track [Page 61] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > The format of the Options Template Set is now as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 28 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 260 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Field Length = 4 | Enterprise Number ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... Enterprise Number |0|exportedMessageTotalCount=41 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A.4.4. Data Set Using an Enterprise-Specific Scope > > In this example, we report the following two Data Records: > > Enterprise field 123 | IPFIX Message | Exported Flow Records > ------------------------------------------------------------------- > 1 | 345 | 10201 > 2 | 690 | 20402 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 260 | Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 345 | 10201 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 690 | 20402 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Standards Track [Page 62] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > A.5. Variable-Length Information Element Examples > > A.5.1. Example of Variable-Length Information Element with Length > Inferior to 255 Octets > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5 | 5 octet Information Element | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A.5.2. Example of Variable-Length Information Element with 3 Octet > Length Encoding > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | 1000 | IE ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1000 octet Information Element | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... IE | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > References > > Normative References FYI (for the RFC editor) the following-lines indent is off by one in all the following citations: > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport > Layer Security over Stream Control Transmission > Protocol", RFC 3436, December 2002. > > [RFC3492] Costello, A., "Punycode: A Bootstring encoding of > Unicode for Internationalized Domain Names in > Applications (IDNA)", RFC 3492, March 2003. > > [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. > Conrad, "Stream Control Transmission Protocol (SCTP) > Partial Reliability Extension", RFC 3758, May 2004. > > > > > Standards Track [Page 63] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport > Layer Security", RFC 4347, April 2006. ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) > > [RFC4960] Stewart, R., Ed., "Stream Control Transmission > Protocol", RFC 4960, September 2007. > > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing > an IANA Considerations Section in RFCs", BCP 26, RFC > 5226, May 2008. > > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer > Security (TLS) Protocol Version 1.2", RFC 5246, > August 2008. > > [RFC5280] Cooper, D., Santesson, S., Farrell, S. Boeyen, S. > Housley, R., and W. Polk, "Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation > List (CRL) Profile", RFC 5280, April 2008. > > [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and > W. Kasch, "Network Time Protocol Version 4: Protocol > and Algorithms Specification", RFC 5905, June 2010 > > [RFC5891] J. Klensin, "Internationalized Domain Names in > Applications (IDNA): Protocol", RFC 5891, August > 2010. > > [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., > "Transport Layer Security (TLS) and Datagram > Transport Layer Security (DTLS) Heartbeat Extension", > RFC 6520, February 2012. > > [TCP] Postel, J., "Transmission Control Protocol", STD 7, > RFC 793, September 1981. > > [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, > August 1980. > > [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information > Export", draft-claise-ipfix-information-model- > rfc5102bis-01.txt, Work in Progress, October 2011. -- Possible downref: Normative reference to a draft: ref. 'RFC5102bis' > > Informative References > > [PEN] IANA Private Enterprise Numbers registry > http://www.iana.org/assignments/enterprise-numbers. > > > > > Standards Track [Page 64] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > [RFC1948] Bellovin, S., "Defending Against Sequence Number > Attacks", RFC 1948, May 1996. -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) > > [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, > "Textual Conventions for SMIv2", STD 58, RFC 2579, > April 1999. > > [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. > Jacobson, "RTP: A Transport Protocol for Real-Time > Applications", STD 64, RFC 3550, July 2003. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export > (IPFIX)", RFC 3917, October 2004. > > [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services > Export Version 9", RFC 3954, October 2004. > > [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP > Flow Information Export (IPFIX)", RFC 5103, January > 2008. > > [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP > Flow Information Export (IPFIX) Protocol for the > Exchange of IP Traffic Flow Information", RFC 5101, > January 2008. > > [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP > Flow Information Export (IPFIX) Implementation > Guidelines", RFC5153, April 2008 > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. > Quittek, "Architecture for IP Flow Information > Export", RFC5470, March 2009. > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, > "IP Flow Information Export (IPFIX) Applicability", > RFC5472, March 2009. > > [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines > for IP Flow Information Export (IPFIX) Testing", > RFC5471, March 2009 > > [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing > Redundancy in IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Reports", RFC5473, March 2009 > > [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, > > > > Standards Track [Page 65] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > "Exporting Type Information for IP Flow Information > Export (IPFIX) Information Elements", July 2009. > > [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram > Transport Layer Security (DTLS) for Stream Control > Transmission Protocol (SCTP)", RFC6083, January 2011. > > [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, > "Export of Structured Data in IP Flow Information > Export (IPFIX)", RFC6313, July 2011. > > [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, > "IP Flow Information Export (IPFIX) Mediation: > Framework", RFC6183, April 2011. > > [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information > Technology - Portable Operating System Interface, > IEEE, 2008. > > [IEEE.754.1985] Institute of Electrical and Electronics Engineers, > "Standard for Binary Floating-Point Arithmetic", IEEE > Standard 754, August 1985. > > [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken, "Configuration > Data Model for IPFIX and PSAMP", draft-ietf-ipfix- > configuration-model-10, Work in Progress, July 2011. == Outdated reference: draft-ietf-ipfix-configuration-model has been published as RFC 6728 > > [IPFIX-PER-SCTP-STREAM] Claise, B., Aitekn, P., Johnson, A. and G. > Muenz, "IPFIX Export per SCTP Stream", draft-ietf- > ipfix-export-per-sctp-stream-08, Work in Progress, > May 2010. == Outdated reference: draft-ietf-ipfix-export-per-sctp-stream has been published as RFC 6526 P. > > [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, > "Specification of the Protocol for IPFIX Mediations", > draft-claise-ipfix-mediation-protocol-04, Work in > Progress, July 2011. > > [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, > "Definitions of Managed Objects for IP Flow > Information Export", draft-dkcm-ipfix-rfc5815bis- > 00.txt, Work in Progress, October 2011. > > Acknowledgments > > We would like to thank the following persons: Ganesh Sadasivan for > his significant contribution during the initial phases of the > protocol specification; Juergen Quittek for the coordination job > within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and > > > > Standards Track [Page 66] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Andrew Johnson for the thorough reviews; Randall Stewart and Peter > Lei for their SCTP expertise and contributions; Martin Djernaes for > the first essay on the SCTP section; Michael Behringer and Eric > Vyncke for their advice and knowledge in security; Michael Tuexen for > his help regarding the DTLS section; Elisa Boschi for her > contribution regarding the improvement of SCTP sections; Mark > Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter > Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul > Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical > reviews and feedback. > > Authors' Addresses > > Benoit Claise (Ed.) > Cisco Systems > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > > Phone: +32 2 704 5622 > EMail: bclaise@cisco.com > > > Brian Trammell (Ed.) > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > EMail: trammell@tik.ee.ethz.ch > > > Stewart Bryant > Cisco Systems, Inc. > 250, Longwater, > Green Park, > Reading, RG2 6GB, > United Kingdom > > Phone: +44 (0)20 8824-8828 > EMail: stbryant@cisco.com > > > > > > > > > > Standards Track [Page 67] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Simon Leinen > SWITCH > Werdstrasse 2 > P.O. Box > 8021 Zurich > Switzerland > > Phone: +41 44 268 1536 > EMail: simon.leinen@switch.ch > > > Thomas Dietz > NEC Europe Ltd. > NEC Laboratories Europe > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg > Germany > > Phone: +49 6221 4342-128 > EMail: Thomas.Dietz@nw.neclab.eu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Standards Track [Page 68] --------------080303060203060507050408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit draft-ietf-ipfix-protocol-rfc5101bis-03 Dear all,

Here's a comprehensive review of draft-ietf-ipfix-protocol-rfc5101bis-03 :


 



Network Working Group                                     B. Claise, Ed.
Internet Draft                                       Cisco Systems, Inc.
Obsoletes: 5101                                         B. Trammell, Ed.
Category: Standards Track                                     ETH Zurich
Expires: May 24, 2013                                  November 20, 2012


   Specification of the IP Flow Information eXport (IPFIX) Protocol 
                  for the Exchange of Flow Information
                draft-ietf-ipfix-protocol-rfc5101bis-03
                                    

Abstract 

   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting Traffic Flow information over
   the network.  In order to transmit Traffic Flow information from an
   Exporting Process to an information Collecting Process, a common
   representation of flow data and a standard means of communicating
   them is required.  This document describes how the IPFIX Data and
   Template Records are carried over a number of transport protocols
   from an IPFIX Exporting Process to an IPFIX Collecting Process.  This
   document obsoletes RFC 5101.

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 March 23, 2012.

Then it's expired already. Can we run a valid WGLC on an expired version?



Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

== The copyright year in the IETF Trust and authors Copyright Line does not match the current year



   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
 


<Claise, et al.>            Standards Track                     [Page 1]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   (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.




Table of Contents

     1.1.  Changes since RFC 5101 . . . . . . . . . . . . . . . . . .  4
     1.2.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Terminology Summary Table  . . . . . . . . . . . . . . . . 11
   3.  IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Message Header Format  . . . . . . . . . . . . . . . . . . 14
     3.2.  Field Specifier Format . . . . . . . . . . . . . . . . . . 15
     3.3.  Set and Set Header Format  . . . . . . . . . . . . . . . . 16
       3.3.1.  Set Format . . . . . . . . . . . . . . . . . . . . . . 16
       3.3.2.  Set Header Format  . . . . . . . . . . . . . . . . . . 17
     3.4.   Record Format . . . . . . . . . . . . . . . . . . . . . . 18
       3.4.1.  Template Record Format . . . . . . . . . . . . . . . . 18
       3.4.2.  Options Template Record Format . . . . . . . . . . . . 20
         3.4.2.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . 21
         3.4.2.2.  Options Template Record Format . . . . . . . . . . 22
       3.4.3.  Data Record Format . . . . . . . . . . . . . . . . . . 24
   4.  Specific Reporting Requirements  . . . . . . . . . . . . . . . 25
     4.1.  The Metering Process Statistics Options Template . . . . . 25
     4.2.  The Metering Process Reliability Statistics Options 
           Template . . . . . . . . . . . . . . . . . . . . . . . . . 26
     4.3.  The Exporting Process Reliability Statistics Options
           Template . . . . . . . . . . . . . . . . . . . . . . . . . 28
     4.4.  The Flow Keys Options Template . . . . . . . . . . . . . . 29
   5.  IPFIX Message Header Export Time and Flow Record Time  . . . . 30
   6.  Linkage with the Information Model . . . . . . . . . . . . . . 30
     6.1.  Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31
       6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31
       6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31
       6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31
       6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31
       6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 31
       6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 31
       6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 31
       6.1.8. dateTimeMilliseconds  . . . . . . . . . . . . . . . . . 32
       6.1.9  dateTimeMicroseconds  . . . . . . . . . . . . . . . . . 32
 


<Claise, et al.>            Standards Track                     [Page 2]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


       6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 32
     6.2.  Reduced Size Encoding  . . . . . . . . . . . . . . . . . . 33
   7.  Variable-Length Information Element  . . . . . . . . . . . . . 34
   8.  Template Management  . . . . . . . . . . . . . . . . . . . . . 36
     8.1. Template Withdrawal and Redefinition  . . . . . . . . . . . 37
     8.2   Sequencing Template Management Actions . . . . . . . . . . 39
     8.3.  Additional considerations for Template Management over
           SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
     8.4.  Additional considerations for Template Management over
           UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
   9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 41
     9.1.  Additional considerations for SCTP Collecting Processes  . 42
     9.2.  Additional considerations for UDP Collecting Processes . . 42
   10.  Transport Protocol  . . . . . . . . . . . . . . . . . . . . . 42
     10.1.  Transport Compliance and Transport Usage  . . . . . . . . 44
     10.2.  SCTP  . . . . . . . . . . . . . . . . . . . . . . . . . . 44
       10.2.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 44
       10.2.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 44
       10.2.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45
       10.2.4.  Association Establishment and Shutdown  . . . . . . . 45
       10.2.5.  Failover  . . . . . . . . . . . . . . . . . . . . . . 46
       10.2.6.  Streams . . . . . . . . . . . . . . . . . . . . . . . 46
     10.3.  UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
       10.3.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 46
       10.3.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 46
       10.3.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 47
       10.3.4.  Session Establishment and Shutdown  . . . . . . . . . 47
       10.3.5.  Failover and Session Duplication  . . . . . . . . . . 47
     10.4.  TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
       10.4.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 48
       10.4.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 49
       10.4.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 49
       10.4.4.  Connection Establishment, Shutdown, and Restart . . . 49
       10.4.5.  Failover  . . . . . . . . . . . . . . . . . . . . . . 50
   11.  Security Considerations . . . . . . . . . . . . . . . . . . . 50
     11.1.  Applicability of TLS and DTLS . . . . . . . . . . . . . . 51
     11.2.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     11.3.  Authentication  . . . . . . . . . . . . . . . . . . . . . 52
     11.4.  Protection against DoS Attacks  . . . . . . . . . . . . . 53
     11.5.  When DTLS or TLS Is Not an Option . . . . . . . . . . . . 54
     11.6.  Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 55
     11.7.  Securing the Collector  . . . . . . . . . . . . . . . . . 55
   12.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
   Appendix A.  IPFIX Encoding Examples . . . . . . . . . . . . . . . 56
     A.1.  Message Header Example . . . . . . . . . . . . . . . . . . 56
     A.2.  Template Set Examples  . . . . . . . . . . . . . . . . . . 57
       A.2.1.  Template Set Using IETF-Specified Information 
               Elements . . . . . . . . . . . . . . . . . . . . . . . 57
 


<Claise, et al.>            Standards Track                     [Page 3]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


       A.2.2.  Template Set Using Enterprise-Specific Information
               Elements . . . . . . . . . . . . . . . . . . . . . . . 57
     A.3.  Data Set Example . . . . . . . . . . . . . . . . . . . . . 59
     A.4.  Options Template Set Examples  . . . . . . . . . . . . . . 60
       A.4.1.  Options Template Set Using IETF-Specified 
               Information Elements . . . . . . . . . . . . . . . . . 60
       A.4.2.  Options Template Set Using Enterprise-Specific
               Information  . . . . . . . . . . . . . . . . . . . . . 60
       A.4.3.  Options Template Set Using an Enterprise-Specific 
               Scope  . . . . . . . . . . . . . . . . . . . . . . . . 61
       A.4.4.  Data Set Using an Enterprise-Specific Scope  . . . . . 62
     A.5.  Variable-Length Information Element Examples . . . . . . . 63
       A.5.1.  Example of Variable-Length Information Element with 
               Length . . . . . . . . . . . . . . . . . . . . . . . . 63
       A.5.2.  Example of Variable-Length Information Element with 
               3 Octet Length Encoding  . . . . . . . . . . . . . . . 63
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 63
   Informative References . . . . . . . . . . . . . . . . . . . . . . 64
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 66
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67




   1.  Introduction 

   Traffic on a data network can be seen as consisting of flows passing
   through network elements. It is often interesting, useful, or even
   necessary to have access to information about these flows that pass
   through the network elements for administrative or other purposes. A
   collecting process should be able to receive the flow information

The earlier Abstract uses capitalised "Collecting Process".


   passing through multiple network elements within the data network.
   This requires uniformity in the method of representing the flow
   information and the means of communicating the flows from the network
   elements to the collection point. This document specifies a protocol
   to achieve these aforementioned requirements. This document specifies
   in detail the representation of different flows, the additional data
   required for flow interpretation, packet format, transport mechanisms
   used, security concerns, etc.

1.1.  Changes since RFC 5101

This section says *what* changes were made. However, it's missing a statement on *why* 5101 had to be rewritten. What were the main reasons for rewriting 5101?


   This document obsoletes the Proposed Standard revision of the IPFIX
   Protocol Specification [RFC5101]. The protocol specified by this
   document is interoperable with the protocol as specified in
   [RFC5101]. The following changes have been made to this document with
   respect to the previous document:
 


<Claise, et al.>            Standards Track                     [Page 4]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   - EDITOR'S NOTE: not sure if we need to this information
      Errata ID: 1655 (technical)
      Errata ID: 2791 (technical)
      Errata ID: 2814 (editorial) 
      Errata ID: 1818 (editorial)
      Errata ID: 2792 (editorial)
      Errata ID: 2888 (editorial)
      Errata ID: 2889 (editorial)
      Errata ID: 2890 (editorial)
      Errata ID: 2891 (editorial)
      Errata ID: 2892 (editorial)
      Errata ID: 2903 (editorial)
      Errata ID: 2761 (editorial)
      Errata ID: 2762 (editorial)
      Errata ID: 2763 (editorial)
      Errata ID: 2764 (editorial)
      Errata ID: 2852 (editorial)
      Errata ID: 2857 (editorial)

   - The encoding of the dateTimeSeconds, dateTimeMilliseconds,
   dateTimeMicroseconds, and dateTimeNanoseconds data types, and the
   related encoding of the IPFIX Message Header Export Time field, have
   been clarified, especially with respect to the epoch upon which the
   timestamp data types are based.

   - Clarifications on encoding, especially in Section 6: all IPFIX
   values encoded big-endian.

   - Template management in section 8 has been simplified, and made as
   independent of transport protocol as is interoperably possible, by
   relaxing restrictions on template management actions.

   - Editorial changes, including structural changes to sections 8, 9,
   and 10 to improve readability.


1.2.  IPFIX Documents Overview 

   The IPFIX protocol provides network administrators with access to IP
   flow information.  The architecture for the export of measured IP
   flow information out of an IPFIX Exporting Process to a Collecting
   Process is defined in [RFC5470], per the requirements defined in
   [RFC3917].  This document specifies how IPFIX data records and
   templates are carried via a number of transport protocols from IPFIX
   Exporting Processes to IPFIX Collecting Processes.  

   Four IPFIX optimizations/extensions are currently specified: a
   bandwidth saving method for the IPFIX protocol in [RFC5473], an
 


<Claise, et al.>            Standards Track                     [Page 5]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   efficient method for exporting bidirectional flow in [RFC5103], a

"flows"


   method for the definition and export of complex data structures in
   [RFC6313], and the specification of the Protocol for IPFIX Mediations
   [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183].

Although "IP InFormation eXport" is arguably a better name, the current name is "IPFIX".



   IPFIX has a formal description of IPFIX Information Elements, their
   name, type and additional semantic information, as specified in
   [RFC5102bis], with the export of the Information Element types
   specified in [RFC5610].

   [IPFIX-CONF] specifies a data model for configuring and monitoring

RFC6728.


   IPFIX and PSAMP compliant devices using the NETCONF protocol, while
   the [RFC5815bis] specifies a MIB module for monitoring.

remove "the".



   In terms of development, [RFC5153] provides guidelines for the
   implementation and use of the IPFIX protocol, while [RFC5471]
   provides guidelines for testing.   

   Finally, [RFC5472] describes what type of applications can use the
   IPFIX protocol and how they can use the information provided.  It
   furthermore shows how the IPFIX framework relates to other
   architectures and frameworks.  

2.  Terminology

   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]. 

   The definitions of the basic terms like Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc.  are
   semantically identical to those found in the IPFIX requirements
   document [RFC3917].  Some of the terms have been expanded for more
   clarity when defining the protocol.  Additional terms required for
   the protocol have also been defined.  Definitions in this document
   and in [RFC5470] are equivalent, except that definitions that are
   only relevant to the IPFIX protocol only appear here. 

   The terminology summary table in Section 2.1 gives a quick overview
   of the relationships between some of the different terms defined. 

   Observation Point 

      An Observation Point is a location in the network where packets
      can be observed.  Examples include: a line to which a probe is
      attached, a shared medium, such as an Ethernet-based LAN, a single
      port of a router, or a set of interfaces (physical or logical) of
      a router. 
 


<Claise, et al.>            Standards Track                     [Page 6]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


      Note that every Observation Point is associated with an
      Observation Domain (defined below), and that one Observation Point
      may be a superset of several other Observation Points.  For
      example, one Observation Point can be an entire line card.  That
      would be the superset of the individual Observation Points at the
      line card's interfaces. 

   Observation Domain 

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process. 
      For example, a router line card may be an Observation Domain if it
      is composed of several interfaces, each of which is an Observation
      Point.  In the IPFIX Message it generates, the Observation Domain
      includes its Observation Domain ID, which is unique per Exporting
      Process.  That way, the Collecting Process can identify the
      specific Observation Domain from the Exporter that sends the IPFIX
      Messages. Every Observation Point is associated with an
      Observation Domain.  It is RECOMMENDED that Observation Domain IDs
      also be unique per IPFIX Device.

   Traffic Flow or Flow 

      There are several definitions of the term 'flow' being used by the
      Internet community.  Within the context of IPFIX we use the
      following definition: 

      A Flow is defined as a set of packets passing an Observation Point
      in the network during a certain time interval.  All packets
      belonging to a particular Flow have a set of common properties. 
      Each property is defined as the result of applying a function to
      the values of: 

         1. one or more packet header fields (e.g., destination IP 
            address), transport header fields (e.g., destination port
            number), or application header fields (e.g., RTP header
            fields [RFC3550]). 

         2. one or more characteristics of the packet itself (e.g.,
            number of MPLS labels, etc...). 

         3. one or more of fields derived from packet treatment (e.g.,
            next hop IP address, the output interface, etc...). 

      A packet is defined as belonging to a Flow if it completely
      satisfies all the defined properties of the Flow. 

      Note that the set of packets represented by a Flow may be empty;
 


<Claise, et al.>            Standards Track                     [Page 7]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


      that is, a Flow may represent zero or more packets. Note also that
      as sampling is a packet treatent, this definition includes packets

"treatment"


      selected by a sampling mechanism.

"also" seems to be in the wrong place. Consider: "Note also that as sampling is a packet treatment, this definition also includes packets selected by a sampling mechanism."



   Flow Key 

      Each of the fields that: 

      1.  belong to the packet header (e.g., destination IP address), 

      2.  are a property of the packet itself (e.g., packet length), 

      3.  are derived from packet treatment (e.g., Autonomous System
          (AS) number), 

      and that are used to define a Flow are termed Flow Keys.

There's an implicit OR between 1, 2, and 3 that's confused by the final "and that". Putting ", or" at the end of 1 and 2 might help.



   Flow Record 

      A Flow Record contains information about a specific Flow that was
      observed at an Observation Point.  A Flow Record contains measured
      properties of the Flow (e.g., the total number of bytes for all
      the Flow's packets) and usually characteristic properties of the
      Flow (e.g., source IP address).

Say, "and usually contains characteristic properties", else the statement is that "A FR contains ... usually characteristic properties", which is something else entirely.



   Metering Process 

      The Metering Process generates Flow Records.  Inputs to the
      process are packet headers and characteristics observed at an
      Observation Point, and packet treatment at the Observation Point
      (for example, the selected output interface).

The inputs could come from multiple OPs, and the packet treatment could be at a distinct OP from where the characteristics were observed.
eg, suppose a sampler and a filter. That's two treatment OPs.

From the earlier definition, "one Observation Point may be a superset of several other Observation Points". However, it's may not be obvious to the IPFIX novice that this applies here.



      The Metering Process consists of a set of functions that includes
      packet header capturing, timestamping, sampling, classifying, and
      maintaining Flow Records. 

      The maintenance of Flow Records may include creating new records,
      updating existing ones, computing Flow statistics, deriving
      further Flow properties, detecting Flow expiration, passing Flow
      Records to the Exporting Process, and deleting Flow Records. 

   Exporting Process 

      The Exporting Process sends Flow Records to one or more Collecting

Consider "zero or more", so the EP can be present but disabled or inactive, not have a reachable CP, or can be filtering what it exports.
Else, if it's unable to export or decides not to export a particular FR, it's technically not longer a 5101bis-compliant EP :-(

Consider "sends Flow Records and Templates".


      Processes.  The Flow Records are generated by one or more Metering
      Processes.

   Exporter 
 


<Claise, et al.>            Standards Track                     [Page 8]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


      A device that hosts one or more Exporting Processes is termed an
      Exporter.  

   IPFIX Device 

      An IPFIX Device hosts at least one Exporting Process.  It may host
      further Exporting Processes and arbitrary numbers of Observation
      Points and Metering Processes. 

   Collecting Process 

      A Collecting Process receives Flow Records from one or more
      Exporting Processes.  The Collecting Process might process or

So it's not actually a CP until it receives data? ie, if it doesn't receive anything, then it's not a CP?


      store received Flow Records, but such actions are out of scope for
      this document. 

   Collector 

      A device that hosts one or more Collecting Processes is termed a
      Collector.

   Template 

      A Template is an ordered sequence of <type, length> pairs used to
      completely specify the structure and semantics of a particular set
      of information that needs to be communicated from an IPFIX Device
      to a Collector.  Each Template is uniquely identifiable by means
      of a Template ID.

We're moving away from this with SD where type and semantics are contained in data records. Potentially similarly with EFS.



   IPFIX Message 

      An IPFIX Message is a message originating at the Exporting Process
      that carries the IPFIX records of this Exporting Process and whose
      destination is a Collecting Process.  An IPFIX Message is
      encapsulated at the transport layer. 

   Message Header 

      The Message Header is the first part of an IPFIX Message, which
      provides basic information about the message, such as the IPFIX
      version, length of the message, message sequence number, etc. 

   Template Record 

      A Template Record defines the structure and interpretation of
      fields in a Data Record. 

   Data Record 
 


<Claise, et al.>            Standards Track                     [Page 9]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


      A Data Record is a record that contains values of the parameters
      corresponding to a Template Record.

Clarify the difference between "Flow Record" and "Data Record" ?



   Options Template Record 

      An Options Template Record is a Template Record that defines the
      structure and interpretation of fields in a Data Record, including
      defining how to scope the applicability of the Data Record. 

   Set 

      Set is a generic term for a collection of records that have a
      similar structure.  In an IPFIX Message, one or more Sets follow
      the Message Header.

Then is a header with no sets an invalid IPFIX Message?
Maybe it's a new exporter informing the CP that it's there; maybe it's a connectivity test. It's an empty Message, but it's still a Message.



      There are three different types of Sets: Template Set, Options
      Template Set, and Data Set.  

   Template Set 

      A Template Set is a collection of one or more Template Records
      that have been grouped together in an IPFIX Message.  

   Options Template Set 

      An Options Template Set is a collection of one or more Options
      Template Records that have been grouped together in an IPFIX
      Message.

   Data Set 

      A Data Set is one or more Data Records, of the same type, that are
      grouped together in an IPFIX Message.  Each Data Record is
      previously defined by a Template Record or an Options Template
      Record.

   Information Element 

      An Information Element is a protocol and encoding-independent
      description of an attribute that may appear in an IPFIX Record. 
      The IPFIX information model [RFC5102bis] defines the base set of
      Information Elements for IPFIX.  The type associated with an

Not any more.


      Information Element indicates constraints on what it may contain
      and also determines the valid encoding mechanisms for use in
      IPFIX.

   Transport Session 

 


<Claise, et al.>            Standards Track                    [Page 10]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


      In Stream Control Transmission Protocol (SCTP), the transport
      session is known as the SCTP association, which is uniquely
      identified by the SCTP endpoints [RFC4960]; in TCP, the transport
      session is known as the TCP connection, which is uniquely
      identified by the combination of IP addresses and TCP ports used. 
      In UDP, the transport session is known as the UDP session, which
      is uniquely identified by the combination of IP addresses and UDP
      ports used.

2.1.  Terminology Summary Table 

   +------------------+---------------------------------------------+ 
   |                  |                 contents                    | 
   |                  +--------------------+------------------------+ 
   |       Set        |      Template      |         record         |

Why isn't "record" capitalised?


   +------------------+--------------------+------------------------+ 
   |     Data Set     |          /         |     Data Record(s)     | 
   +------------------+--------------------+------------------------+ 
   |   Template Set   | Template Record(s) |           /            | 
   +------------------+--------------------+------------------------+ 
   | Options Template | Options Template   |           /            | 
   |       Set        | Record(s)          |                        | 
   +------------------+--------------------+------------------------+ 

   Figure A: Terminology Summary Table

Figure A is unreferenced, ie there's no text saying "Figure A summarises IPFIX terminology".



   A Data Set is composed of Data Record(s).  No Template Record is
   included.  A Template Record or an Options Template Record defines
   the Data Record. 

   A Template Set contains only Template Record(s).   

   An Options Template Set contains only Options Template Record(s).   

3.  IPFIX Message Format  

   An IPFIX Message consists of a Message Header, followed by one or
   more Sets.  The Sets can be any of the possible three types: Data
   Set, Template Set, or Options Template Set.   

   The format of the IPFIX Message is shown in Figure B. 

   +----------------------------------------------------+ 
   | Message Header                                     | 
   +----------------------------------------------------+ 
   | Set                                                | 
   +----------------------------------------------------+ 
   | Set                                                | 
 


<Claise, et al.>            Standards Track                    [Page 11]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   +----------------------------------------------------+ 
     ... 
   +----------------------------------------------------+ 
   | Set                                                | 
   +----------------------------------------------------+ 

   Figure B: IPFIX Message Format 

   The Exporter MUST encode all integers in the Message Header and the
   Set Headers in network byte order (also known as big-endian byte
   order).

   Following are some examples of IPFIX Messages: 

   1. An IPFIX Message consisting of interleaved Template, Data, and
      Options Template Sets -- A newly created Template is exported as
      soon as possible.  So, if there is already an IPFIX Message with a
      Data Set that is being prepared for export, the Template and
      Options Template Sets are interleaved with this information,
      subject to availability of space.

These are implementation details.

If "A newly created Template is exported as soon as possible" then the Message would have been exported before the following Data and Options sets could be added.






























 


<Claise, et al.>            Standards Track                    [Page 12]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   +--------+--------------------------------------------------------+ 
   |        | +----------+ +---------+     +-----------+ +---------+ | 
   |Message | | Template | | Data    |     | Options   | | Data    | | 
   | Header | | Set      | | Set     | ... | Template  | | Set     | | 
   |        | |          | |         |     | Set       | |         | | 
   |        | +----------+ +---------+     +-----------+ +---------+ | 
   +--------+--------------------------------------------------------+  

   Figure C: IPFIX Message, Example 1

Figure C is unreferenced. If it's not required, then remove it. If it's required, then add some text to say why it's here.



   2. An IPFIX Message consisting entirely of Data Sets -- After the
      appropriate Template Records have been defined and transmitted to
      the Collecting Process, the majority of IPFIX Messages consist
      solely of Data Sets.   

   +--------+----------------------------------------------+ 
   |        | +---------+     +---------+      +---------+ | 
   |Message | | Data    |     | Data    |      | Data    | | 
   | Header | | Set     | ... | Set     | ...  | Set     | | 
   |        | +---------+     +---------+      +---------+ | 
   +--------+----------------------------------------------+   

   Figure D: IPFIX Message, Example 2

Figure D is unreferenced.



   3. An IPFIX Message consisting entirely of Template and Options
      Template Sets.

Is there nothing to be said about this, unlike (1) and (2) ?



   +--------+-------------------------------------------------+ 
   |        | +----------+     +----------+      +----------+ | 
   |Message | | Template |     | Template |      | Options  | | 
   | Header | | Set      | ... | Set      | ...  | Template | | 
   |        | |          |     |          |      | Set      | | 
   |        | +----------+     +----------+      +----------+ | 
   +--------+-------------------------------------------------+ 

   Figure E: IPFIX Message, Example 3

Figure E is unreferenced. Why is it here? What does it show?














 


<Claise, et al.>            Standards Track                    [Page 13]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


3.1.  Message Header Format 

   The format of the IPFIX Message Header is shown in Figure F. 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Version Number          |            Length             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           Export Time                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Sequence Number                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Observation Domain ID                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure F: IPFIX Message Header Format 

   Message Header Field Descriptions:  

   Version 

      Version of Flow Record format exported in this message.  The value

Consider "IPFIX" instead of "Flow Record format", because if the Header, Template IDs, or Set IDs are changed, the version would have to change although the FR format may be unchanged.


      of this field is 0x000a for the current version, incrementing by
      one the version used in the NetFlow services export version 9
      [RFC3954].

   Length 

      Total length of the IPFIX Message, measured in octets, including
      Message Header and Set(s). 

   Export Time

      Time at which the IPFIX Message Header leaves the Exporter,
      expressed in seconds since the UNIX epoch of 1 January 1970 at
      00:00 UTC, encoded as an unsigned 32-bit integer.

   Sequence Number 

      Incremental sequence counter modulo 2^32 of all IPFIX Data Records
      sent in a the current stream from the current Observation Domain
      by the Exporting Process. Each SCTP Stream counts sequence numbers
      separately, while all messages in a TCP connection or UDP
      transport session are considered to be part of the same stream.
      This value SHOULD be used by the Collecting Process to identify
      whether any IPFIX Data Records have been missed. Template and
      Options Template Records do not increase the Sequence Number.
 


<Claise, et al.>            Standards Track                    [Page 14]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012

The "Observation Domain ID" title is missing here.


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

3.2.  Field Specifier Format 

   Vendors need the ability to define proprietary Information Elements,
   because, for example, they are delivering a pre-standards product, or
   the Information Element is, in some way, commercially sensitive. 
   This section describes the Field Specifier format for both
   IETF-specified Information Elements [RFC5102bis] and enterprise-
   specific Information Elements.

NB this text is inconsistent with the texts under Figure K, and above Figure O.



   The Information Elements are identified by the Information Element
   identifier.  When the Enterprise bit is set to 0, the corresponding
   Information Element identifier will report an IETF-specified

Why future tense? "reports" would be fine.


   Information Element, and the Enterprise Number MUST NOT be present. 
   When the Enterprise bit is set to 1, the corresponding Information
   Element identifier will report an enterprise-specific Information

As above.


   Element; the Enterprise Number MUST be present.  An example of this
   is shown in Section A.4.2.

A.2.2 is the first (and more obvious) example.



   The Field Specifier format is shown in Figure G. 

   0                   1                   2                   3  
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |E|  Information Element ident. |        Field Length           |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                      Enterprise Number                        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

   Figure G: Field Specifier Format 






 


<Claise, et al.>            Standards Track                    [Page 15]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Where: 

   E  

      Enterprise bit.  This is the first bit of the Field  Specifier.

"Field  Specifier" is double-spaced.


      If this bit is zero, the Information Element  Identifier

"Element  Identifier" is double-spaced.


      identifies an IETF-specified Information Element,  and the four-

"Element,  and" is double-spaced.


      octet Enterprise Number field MUST NOT be present.  If this bit is
      one, the Information Element identifier identifies an enterprise-
      specific Information  Element, and the Enterprise Number filed

"Information  Element" is double-spaced.

s/filed/field/


      MUST be present.   

   Information Element identifier

      A numeric value that represents the type of Information Element. 
      Refer to [RFC5102bis].

Not any more.


 

   Field Length  

      The length of the corresponding encoded Information Element,  in

"Element,  in" is double-spaced.


      octets.  Refer to [RFC5102bis].  The field length may be smaller
      than the definition in [RFC5102bis] if the reduced size encoding

Which definition is that?

Remove "the".


      is used (see Section 6.2).  The value 65535 is reserved for
      variable-length Information Elements (see Section 7). 

   Enterprise Number

      IANA enterprise number [PEN] of the authority defining the
      Information Element identifier in this Template Record. 

3.3.  Set and Set Header Format 

   A Set is a generic term for a collection of records that have a
   similar structure.  There are three different types of Sets: Template
   Sets, Options Template Sets, and Data Sets.  Each of these Sets
   consists of a Set Header and one or more records.  The Set Format and
   the Set Header Format are defined in the following sections. 

3.3.1.  Set Format 

   A Set has the format shown in Figure H.  The record types can be
   either Template Records, Options Template Records, or Data Records.
   The record types MUST NOT be mixed within a Set. 





 


<Claise, et al.>            Standards Track                    [Page 16]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   +--------------------------------------------------+ 
   | Set Header                                       | 
   +--------------------------------------------------+ 
   | record                                           | 
   +--------------------------------------------------+ 
   | record                                           | 
   +--------------------------------------------------+ 
    ... 
   +--------------------------------------------------+ 
   | record                                           | 
   +--------------------------------------------------+ 
   | Padding (opt.)                                   | 
   +--------------------------------------------------+ 

   Figure H: Set Format 

   The Set Field Definitions are as follows: 

   Set Header 

      The Set Header Format is defined in Section 3.3.2. 

   Record 

      One of the record Formats: Template Record, Options Template
      Record, or Data Record Format.  

   Padding 

      The Exporting Process MAY insert some padding octets, so that the
      subsequent Set starts at an aligned boundary.  For security
      reasons, the padding octet(s) MUST be composed of zero (0) valued
      octets.  The padding length MUST be shorter than any allowable
      record in this Set.  If padding of the IPFIX Message is desired in
      combination with very short records, then the padding Information
      Element 'paddingOctets' [RFC5102bis] can be used for padding

5102bis isn't a reference for PO.


      records such that their length is increased to a multiple of 4 or
      8 octets.  Because Template Sets are always 4-octet aligned by
      definition, padding is only needed in case of other alignments
      e.g., on 8-octet boundaries.

3.3.2.  Set Header Format 

   Every Set contains a common header.  This header is defined in Figure
   I.

Make a non-breaking space in "Figure I".





 


<Claise, et al.>            Standards Track                    [Page 17]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Set ID               |          Length               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure I: Set Header Format 

   The Set Header Field Definitions are as follows: 

   Set ID

      Set ID value identifies the Set.  A value of 2 is reserved for the
      Template Set.  A value of 3 is reserved for the Options Template
      Set.  All other values from 4 to 255 are reserved for future use. 
      Values above 255 are used for Data Sets.  The  Set ID values of 0

"The  Set" is double-spaced.


      and 1 are not used for historical reasons  [RFC3954].

"reasons  [RFC3954]" is double-spaced.

Add a comma to avoid mis-parsing: "The Set ID values of 0 and 1 are not used, for historical reasons" or re-order: "For historical reasons, Set ID values of 0 and 1 are not used". As it is, the existing text says they're not used for historical reasons, but any other reason is fine.



   Length

      Total length of the Set, in octets, including the Set Header, all
      records, and the optional padding.  Because an individual Set MAY
      contain multiple records, the Length value MUST be used to
      determine the position of the next Set. 

3.4.   Record Format 

   IPFIX defines three record formats, defined in the next sections: the
   Template Record Format, the Options Template Record Format, and the
   Data Record Format.  

3.4.1.  Template Record Format 

   One of the essential elements in the IPFIX record format is the
   Template Record.  Templates greatly enhance the flexibility of the
   record format because they allow the Collecting Process to process
   IPFIX Messages without necessarily knowing the interpretation of all
   Data Records.  A Template Record contains any combination of
   IANA-assigned and/or enterprise-specific Information Elements

s/Elements/Element/ (singular)


   identifiers.

   The format of the Template Record is shown in Figure J.  It consists
   of a Template Record Header and one or more Field Specifiers.  The
   definition of the Field Specifiers is given in Figure G above. 




 


<Claise, et al.>            Standards Track                    [Page 18]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   +--------------------------------------------------+ 
   | Template Record Header                           | 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 
    ... 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 

   Figure J: Template Record Format 

   The format of the Template Record Header is shown in Figure K. 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      Template ID (> 255)      |         Field Count           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure K: Template Record Header Format 

   The Template Record Header Field Definitions are as follows: 

   Template ID

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

See note in section 4 about Template IDs.



   Field Count 

      Number of fields in this Template Record. 

   The example in Figure L shows a Template Set with mixed standard and
   enterprise-specific Information Elements.  It consists of a Set
   Header, a Template Header, and several Field Specifiers.

NB this text is inconsistent with the similar texts in section 3.2, and above Figure O.







 


<Claise, et al.>            Standards Track                    [Page 19]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |          Set ID = 2           |          Length               |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |      Template ID = 256        |         Field Count = N       |    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |1| Information Element id. 1.1 |        Field Length 1.1       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                    Enterprise Number  1.1                     |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |0| Information Element id. 1.2 |        Field Length 1.2       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |             ...               |              ...              |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |1| Information Element id. 1.N |        Field Length 1.N       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                    Enterprise Number  1.N                     |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |      Template ID = 257        |         Field Count = M       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |0| Information Element id. 2.1 |        Field Length 2.1       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |1| Information Element id. 2.2 |        Field Length 2.2       |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                    Enterprise Number  2.2                     |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |             ...               |              ...              |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |1| Information Element id. 2.M |        Field Length 2.M       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Enterprise Number  2.M                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                          Padding (opt)                        |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Enterprise Number  x.y" is double-spaced in each case.



   Figure L: Template Set Example  

   Information Element Identifiers 1.2 and 2.1 are defined by the IETF
   (Enterprise bit = 0) and, therefore, do not need an Enterprise Number
   to identify them.  

3.4.2.  Options Template Record Format 

   Thanks to the notion of scope, The Options Template Record gives the

s/The/the".


   Exporter the ability to provide additional information to the
   Collector that would not be possible with Flow Records alone.  

 


<Claise, et al.>            Standards Track                    [Page 20]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   One Options Template Record example is the "Flow Keys", which reports
   the Flow Keys for a Template, which is defined as the scope.  Another
   example is the "Template configuration", which reports the
   configuration sampling parameter(s) for the Template, which is
   defined as the scope.

Possibly the "sampling configuration" reports the configured sampling params ?

s/configuration/configured/

"Flow Keys" is in 4.4, but "Template configuration" (or in fact, anything to do with sampling) isn't.



3.4.2.1.  Scope  

   The scope, which is only available in the Options Template Set, gives
   the context of the reported Information Elements in the Data Records.
    Note that the IPFIX Message Header already contains the Observation

NB wrong indentation.


   Domain ID (the identifier of the Observation Domain).  If not zero,
   this Observation Domain ID can be considered as an implicit scope for
   the Data Records in the IPFIX Message.  The Observation Domain ID
   MUST be zero when the IPFIX Message contains Data Records with
   different Observation Domain ID values defined as scopes.

Not necessarily. I can't think of a great example, but it allows OD#n to report on other ODs in a way that's not possible if n must be in the DR with all the other ODs.


 

   Multiple Scope Fields MAY be present in the Options Template Record,
   in which case, the composite scope is the combination of the scopes.
   For example, if the two scopes are defined as "metering process" and
   "template", the combined scope is this Template for this Metering

Why are these terms lowercase? Should they be IE names?


   Process.  The order of the Scope Fields, as defined in the Options
   Template Record, is irrelevant in this case.  However, if the order
   of the Scope Fields in the Options Template Record is relevant, the
   order of the Scope Fields MUST be used.  For example, if the first
   scope defines the filtering function, while the second scope defines
   the sampling function, the order of the scope is important.  Applying
   the sampling function first, followed by the filtering function,
   would lead to potentially different Data Records than applying the
   filtering function first, followed by the sampling function.  In this
   case, the Collector deduces the function order by looking at the
   order of the scope in the Options Template Record.

So how does the EP / CP / whoever determine that the order is important?
Why not do away with the ambiguity and simply say that the scope order is always to be regarded?



   The scope is an Information Element specified in the IPFIX
   Information Model [RFC5102bis].  An IPFIX-compliant implementation of
   the Collecting Process SHOULD support this minimum set of Information
   Elements as scope: LineCardId, TemplateId, exporterIPv4Address,
   exporterIPv6Address, and ingressInterface.  Note that other
   Information Elements, such as meteringProcessId, exportingProcessId,
   observationDomainId, etc. are also valid scopes.  The IPFIX protocol
   doesn't prevent the use of any Information Elements for scope.
   However, some Information Element types don't make sense if specified
   as scope; for example, the counter Information Elements.

   Finally, note that the Scope Field Count MUST NOT be zero. 



 


<Claise, et al.>            Standards Track                    [Page 21]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


3.4.2.2.  Options Template Record Format 

   An Options Template Record contains any combination of IANA-assigned
   and/or enterprise-specific Information Elements identifiers.

s/Elements/Element/ (singular)



   The format of the Options Template Record is shown in Figure M.  It
   consists of an Options Template Record Header and one or more Field
   Specifiers.  The definition of the Field Specifiers is given in
   Figure G above. 

   +--------------------------------------------------+ 
   | Options Template Record Header                   | 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 
    ... 
   +--------------------------------------------------+ 
   | Field Specifier                                  | 
   +--------------------------------------------------+ 

   Figure M: Options Template Record Format 

   The format of the Options Template Record Header is shown in Figure
   N.

Make a non-breaking space in "Figure N".



    0                  1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Template ID (> 255)   |         Field Count           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      Scope Field Count        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure N: Options Template Record Header Format

Q: can we deprecate regular Templates (per section 3.4.1) - so everything is in "options template" format - and allow the SFC to be zero for non-scoped (data) Templates?



   The Options Template Record Header Field Definitions are as follows: 

   Template ID 

   Template ID of this Options Template Record.  This value is greater
   than 255.  





 


<Claise, et al.>            Standards Track                    [Page 22]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Field Count 

   Number of all fields in this Options Template Record, including the
   Scope Fields. 

   Scope Field Count 

   Number of scope fields in this Options Template Record.  The  Scope

"The  Scope" is double-spaced.


   Fields are normal Fields except that they are interpreted as scope at
   the Collector.  The Scope Field Count  MUST NOT be zero.

"Count  MUST" is double-spaced.



   The example in Figure O shows an Options Template Set with mixed IETF
   and enterprise-specific Information Elements.  It consists of a Set
   Header, an Options Template Header, and several Field Specifiers.

NB this text is inconsistent with similar texts in section 3.2, and under Figure K.



     0                   1                   2                   3   
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |          Set ID = 3           |          Length               |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |         Template ID = 258     |         Field Count = N + M   |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |     Scope Field Count = N     |0|  Scope 1 Infor. Element Id. |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |     Scope 1 Field Length      |0|  Scope 2 Infor. Element Id. |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |     Scope 2 Field Length      |             ...               |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |            ...                |1|  Scope N Infor. Element Id. |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |     Scope N Field Length      |   Scope N Enterprise Number ...  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   ...  Scope N Enterprise Number   |1| Option 1 Infor. Element Id. | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |    Option 1 Field Length      |  Option 1 Enterprise Number ...  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   ... Option 1 Enterprise Number   |              ...              |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |             ...               |0| Option M Infor. Element Id. |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |     Option M Field Length     |      Padding (optional)       |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

   Figure O: Options Template Set Example  




 


<Claise, et al.>            Standards Track                    [Page 23]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


3.4.3.  Data Record Format 

   The Data Records are sent in Data Sets.  The format of the Data
   Record is shown in Figure P.  It consists only of one or more Field
   Values.  The Template ID to which the Field Values belong is encoded
   in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 

   +--------------------------------------------------+ 
   | Field Value                                      | 
   +--------------------------------------------------+ 
   | Field Value                                      | 
   +--------------------------------------------------+ 
    ... 
   +--------------------------------------------------+ 
   | Field Value                                      | 
   +--------------------------------------------------+ 

   Figure P: Data Record Format 

   Note that Field Values do not necessarily have a length of 16 bits.
   Field Values are encoded according to their data type specified in
   [RFC5102bis].

Not any more.



   Interpretation of the Data Record format can be done only if the
   Template Record corresponding to the Template ID is available at the
   Collecting Process.  

   The example in Figure Q shows a Data Set. It consists of a Set Header
   and several Field Values.   



















 


<Claise, et al.>            Standards Track                    [Page 24]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Set ID = Template ID        |          Length               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Record 1 - Field Value 3    |             ...               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Record 2 - Field Value 3    |             ...               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   Record 3 - Field Value 1    |   Record 3 - Field Value 2    |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 3 - Field Value 3    |             ...               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |              ...              |      Padding (optional)       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    

   Figure Q: Data Set, Containing Data Records

s/Containing/containing/ (lowercase).



4.  Specific Reporting Requirements 

   Some specific Options Templates and Options Template Records are
   necessary to provide extra information about the Flow Records and
   about the Metering Process.    

   The Options Template and Options Template Records defined in these
   subsections, which impose some constraints on the Metering Process
   and Exporting Process implementations, MAY be implemented.  If
   implemented, the specific Options Templates SHOULD be implemented as
   specified in these subsections. 

   The minimum set of Information Elements is always specified in these
   Specific IPFIX Options Templates.  Nevertheless, extra Information
   Elements may be used in these specific Options Templates.

   The Collecting Process MUST check the possible combinations of
   Information Elements within the Options Template Records to correctly
   interpret the following Options Templates.

This is true of all Templates. ie, a CP MUST not assume that Template ID N has any particular meaning.
I have been asked about static allocations, so I'd like to see this explicitly stated, eg in section 3.4.1.



4.1.  The Metering Process Statistics Options Template 

   The Metering Process Statistics Options Template specifies the 
   structure of a Data Record for reporting Metering Process statistics.
    It SHOULD contain the following Information Elements that are

NB wrong indent.


   defined in [RFC5102bis]:

Not any more.


 


<Claise, et al.>            Standards Track                    [Page 25]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   (scope) observationDomainId 
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process. 
                           This Information Element MUST be defined as a
                           Scope Field.                     

   (scope) meteringProcessId 
                           An identifier of the Metering Process for
                           which statistics are reported. This
                           Information Element MUST be defined as a
                           Scope Field.

   exportedMessageTotalCount       
                           The total number of IPFIX Messages that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization. 

   exportedFlowRecordTotalCount 
                           The total number of Flow Records that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization. 

   exportedOctetTotalCount
                           The total number of octets that the Exporting
                           Process successfully sent to the Collecting
                           Process since the Exporting Process re-
                           initialization.

How does the EP know these Messages / Records / Octets were successfully sent?
eg, they may be handed off to a transport layer which doesn't report back on send status.



   The Exporting Process SHOULD export the Data Record specified by the
   Metering Process Statistics Options Template on a regular basis or
   based on some export policy.  This periodicity or export policy
   SHOULD be configurable.  

   Note that if several Metering Processes are available on the Exporter
   Observation Domain, the Information Element meteringProcessId MUST be
   specified as an additional Scope Field.

How does the collector determine the meaning of the meteringProcessId ?



4.2.  The Metering Process Reliability Statistics Options Template 

   The Metering Process Reliability Options Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102bis]:

Not any more.





 


<Claise, et al.>            Standards Track                    [Page 26]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   (scope) observationDomainId    
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process. 
                           This Information Element MUST be defined as a
                           Scope Field. 

   (scope) meteringProcessId    
                           The identifier of the Metering Process for
                           which lack of reliability is reported. This

Why "lack of"? This isn't the "Metering Process Unreliability Statistics"!


                           Information Element MUST be defined as a
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process. 

   ignoredOctetTotalCount 
                           The total number of octets in observed 
                           packets that the Metering Process did not
                           process.

   time first packet ignored     
                           The timestamp of the first packet that was
                           ignored by the Metering  Process.  For this

"Metering  Process" is double-spaced.


                           timestamp, any of the following timestamp can

"timestamps" plural.


                           be used: observationTimeSeconds,
                           observationTimeMilliseconds,
                           observationTimeMicroseconds, or
                           observationTimeNanoseconds.

   time last packet ignored      
                           The timestamp of the last packet that was
                           ignored by the Metering  Process.  For this

"Metering  Process" is double-spaced.


                           timestamp, any of the following timestamp can

"timestamps" plural.


                           be used: observationTimeSeconds,
                           observationTimeMilliseconds,
                           observationTimeMicroseconds, or
                           observationTimeNanoseconds.

   The Exporting Process SHOULD export the Data Record specified by the
   Metering Process Reliability Statistics Options Template on a regular
   basis or based on some export policy.  This periodicity or export
   policy SHOULD be configurable.  

   Note that if several Metering Processes are available on the Exporter
   Observation Domain, the Information Element meteringProcessId MUST be
   specified as an additional Scope Field.

 


<Claise, et al.>            Standards Track                    [Page 27]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Since the Metering Process Reliability Option Template will logically
   contain two identical timestamp Information Elements, and since the
   order of the Information Elements in the Template Records is not
   guaranteed, the Collecting Process MUST determine which is the oldest

It's defined as { first, last }, ie the semantic is derived from the position which is defined in the RFC. See section 8.


   and the most recent timestamp in order the determine the right
   semantic behind the time first packet ignored and time last packet
   ignored Information Elements. Note that the counters wrap-around for
   the timestamps SHOULD also be taken into account.

You're making this hard for no reason. First, Last, in order, "MUST" -> it's easy.



4.3.  The Exporting Process Reliability Statistics Options Template 

   The Exporting Process Reliability Options Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Exporting process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102bis]:  

   (scope) Exporting Process ID  
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102bis] that can be used for this purpose: 
                        exporterIPv4Address, exporterIPv6Address, or 
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.

How does the collector understand "exportingProcessId" ?



   notSentFlowTotalCount 
                        The total number of Flows that were generated by
                        the Metering Process and dropped by the Metering
                        Process or by the Exporting Process instead of
                        being sent to the Collecting Process. 

   notSentPacketTotalCount 
                        The total number of packets in Flow Records that
                        were generated by the Metering Process and
                        dropped by the Metering Process or by the
                        Exporting Process instead of being sent to the
                        Collecting Process.

   notSentOctetTotalCount
                        The total number of octets in packets in Flow
                        Records that were generated by the Metering
                        Process and dropped by the Metering Process or
                        by the Exporting Process instead of being sent
                        to the Collecting Process.




 


<Claise, et al.>            Standards Track                    [Page 28]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   time first flow dropped
                        The time at which the first Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the following timestamp can be
                        used: observationTimeSeconds,
                        observationTimeMilliseconds,
                        observationTimeMicroseconds, or
                        observationTimeNanoseconds.

   time last flow dropped 
                        The time at which the last Flow Record was
                        dropped by the Exporting Process.  For this
                        timestamp, any of the following timestamp can be
                        used: observationTimeSeconds,
                        observationTimeMilliseconds,
                        observationTimeMicroseconds, or
                        observationTimeNanoseconds.

   The Exporting Process SHOULD export the Data Record specified by the
   Exporting Process Reliability Statistics Options Template on a
   regular basis or based on some export policy.  This periodicity or
   export policy SHOULD be configurable. 

   Since the Exporting Process Reliability Option Template will
   logically contain two identical timestamp Information Elements, and
   since the order of the Information Elements in the Template Records
   is not guaranteed, the Collecting Process MUST determine which is the
   oldest and the most recent timestamp in order the determine the right
   semantic behind the time first packet ignored and time last packet
   ignored Information Elements. Note that the counters wrap-around for
   the timestamps SHOULD also be taken into account.

See comments in 4.2 and section 8.



4.4.  The Flow Keys Options Template 

   The Flow Keys Options Template specifies the structure of a Data
   Record for reporting the Flow Keys of reported Flows.  A Flow Keys
   Data Record extends a particular Template Record that is referenced
   by its templateId identifier.  The Template Record is extended by
   specifying which of the Information Elements contained in the
   corresponding Data Records describe Flow properties that serve as
   Flow Keys of the reported Flow. 

   The Flow Keys Options Template SHOULD contain the following
   Information Elements that are defined in [RFC5102bis]:

Not any more they're not.






 


<Claise, et al.>            Standards Track                    [Page 29]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   (scope) templateId      An identifier of a Template.  This
                           Information Element MUST be defined as a
                           Scope Field. 

   flowKeyIndicator        Bitmap with the positions of the Flow Keys in
                           the Data Records.  

5.  IPFIX Message Header Export Time and Flow Record Time 

   The IPFIX Message Header Export Time field is the time at which the
   IPFIX Message Header leaves the Exporter, expressed in seconds since
   the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded in an unsigned
   32-bit integer. 

   Certain time-related Information Elements may be expressed as an
   offset from this Export Time. For example, Data Records requiring a
   microsecond precision can export the flow start and end times with
   the flowStartMicroseconds and flowEndMicroseconds Information
   Elements [RFC5102bis], which encode the absolute time in microseconds
   in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit
   field. An alternate solution is to export the
   flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information
   Elements [RFC5102bis] in the Data Record, which respectively report
   the flow start and end time as negative offsets from the Export Time,
   as an unsigned 32-bit integer. This latter solution lowers the export
   bandwidth requirement, saving two bytes per timestamp, while
   increasing the load on the Exporter, as the Exporting Process must
   calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
   of every single Data Record before exporting the IPFIX Message.

   It must be noted that timestamps based on the Export Time impose some
   time constraints on the Data Records contained within the IPFIX
   Message. In the example of flowStartDeltaMicroseconds and
   flowEndDeltaMicroseconds Information Elements [RFC5102bis], the Data
   Record can only contain records with timestamps within 71 minutes of
   the Export Time. Otherwise, the 32-bit counter would not be
   sufficient to contain the flow start time offset.


6.  Linkage with the Information Model 

   As with values in the IPFIX Message Header and Set Header, values of
   all Information Elements [RFC5102bis], except for those of the string

This is potentially a _valid_ citation of 5102bis. I won't mention it any more.


   and octetArray data types, are encoded in canonical format in network
   byte order (also known as big-endian byte ordering).



 


<Claise, et al.>            Standards Track                    [Page 30]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


6.1.  Encoding of IPFIX Data Types 

   The following sections will define the encoding of the data types
   specified in [RFC5102bis].

Will they? Or do they? Just remove "will".



6.1.1. Integral Data Types 

   Integral data types -- octet, signed8, unsigned16, signed16,
   unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded
   using the default canonical format in network byte order.  Signed
   Integral data types are represented in two's complement notation. 

6.1.2. Address Types 

   Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
   encoded the same way as the integral data types, as six, four, and
   sixteen octets in network byte order, respectively.

6.1.3. float32 

   The float32 data type MUST be encoded as an IEEE single-precision
   32-bit floating point-type, as specified in [IEEE.754.1985], in
   network byte order.

6.1.4. float64 

   The float64 data type MUST be encoded as an IEEE double-precision 64-
   bit floating point-type, as specified in [IEEE.754.1985], in network
   byte order.

6.1.5. boolean 

   The boolean data type is specified according to the TruthValue in
   [RFC2579]. It is encoded as a single-octet integer in network byte
   order, as in Section 6.1.1., with the value 1 for true and a value 2
   for false. Every other value is undefined.

6.1.6. string and octetArray 

   The data type string represents a finite length string of valid
   characters of the Unicode character encoding set. The string data
   type MUST be encoded in UTF-8 format.

RFC3629 ?


   The string is sent as an array
   of octets using an Information Element of fixed or variable length.

Where "array" also allows for zero and one octet.


   The data type octetArray has no encoding rules; it represents a raw
   array of octets, with the intepretation of the octets defined in the

"interpretation".


   Information Element definition.

6.1.7. dateTimeSeconds
 


<Claise, et al.>            Standards Track                    [Page 31]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   The data type dateTimeSeconds is an unsigned 32-bit integer in
   network byte order containing the number of seconds since the UNIX
   epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1].
   dateTimeSeconds is encoded identically to the IPFIX Message Header
   Export Time field. It can represent dates between 1 January 1970 and
   8 February 2106.

6.1.8. dateTimeMilliseconds

   The data type dateTimeMilliseconds is an unsigned 64-bit integer in
   network byte order, containing the number of milliseconds since the
   UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It
   can represent dates beginning on 1 January 1970 for approximately the
   next 500 billion years.

6.1.9  dateTimeMicroseconds

   The data type dateTimeMicroseconds is a 64-bit field encoded
   according to the NTP Timestamp format as defined in section 6 of
   [RFC5905]. This field is made up of two unsigned 32-bit integers in
   network byte order, Seconds and Fraction. The Seconds field is the
   number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
   The Fraction field is the fractional number of seconds in units of
   1/(2^32) seconds (approximately 233 picoseconds). It can represent
   dates beginning between 1 January 1900 and 8 February 2036.

Since we're already over 80% through that range, it seems worth moving the epoch to 1/1/2000.



   Note that dateTimeMicroseconds and dateTimeNanoseconds share an
   identical encoding. The dataTimeMicroseconds data type is intended
   only to represent timestamps of microsecond precision. Therefore, the
   bottom 11 bits of the fraction field MAY contain any value and MUST
   be ignored for all Information Elements of this data type (as 2^11 x
   233 picoseconds = .477 microseconds).

Why not say, the bottom 11 bits must be zero?



6.1.10 dateTimeNanoseconds

   The data type dateTimeNanoseconds is a 64-bit field encoded according
   to the NTP Timestamp format as defined in section 6 of [RFC5905].
   This field is made up of two unsigned 32-bit integers in network byte
   order, Seconds and Fraction. The Seconds field is the number of
   seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The
   Fraction field is the fractional number of seconds in units of
   1/(2^32) seconds (approximately 233 picoseconds). It can represent
   dates beginning between 1 January 1900 and 8 February 2036.

   Note that dateTimeMicroseconds and dateTimeNanoseconds share an
   identical encoding. There is no restriction on the interpretation of
   the Fraction field for the dateTimeNanoseconds data type.

 


<Claise, et al.>            Standards Track                    [Page 32]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


6.2.  Reduced Size Encoding

   Information Elements encoded as signed, unsigned, or float data types
   MAY be encoded using fewer octets than those implied by their type in
   the information model definition [RFC5102bis], based on the
   assumption that the smaller size is sufficient to carry any value the
   Exporter may need to deliver. This reduces the network bandwidth
   requirement between the Exporter and the Collector. Note that the
   Information Element definitions [RFC5102bis] will always define the
   maximum encoding size.

   For instance, the information model [RFC5102bis] defines
   octetDeltaCount as an unsigned64 type, which would require 64 bits.
   However, if the Exporter will never locally encounter the need to
   send a value larger than 4294967295, it may chose to send the value
   instead as an unsigned32. For example, a core router would require an
   unsigned64 byteCount, while an unsigned32 might be sufficient for an
   access router.

   This behavior is indicated by the Exporter by specifying a size in
   the Template with a smaller length than that associated with the
   assigned type of the Information Element. In the example above, the
   Exporter would place a length of 4 versus 8 in the Template.

   If reduced size encoding MAY be be applied to the following integer
   types: unsigned64, signed64, unsigned32, signed32, unsigned16, and
   signed16. The signed versus unsigned property of the reported value
   MUST be preserved. The reduction in size can be to any number of
   octets smaller than the original type if the data value still fits,
   i.e., so that only leading zeroes are dropped. For example, an
   unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

   Reduced size encoding MAY be used to reduce float64 to float32. The
   float32 not only has a reduced number range, but due to the smaller
   mantissa, is also less precise. In this case, the float64 would be
   reduced in size to 4 octets.

   Reduced size encoding MUST NOT be applied to any other data type
   defined in [RFC5102bis] that implies a fixed length, as these types

Again, this is a potentially _valid_ 5102bis citation - so a simple s/5102bis/IANA/ isn't appropriate.


   either have internal structure (such as ipv4Address or
   dateTimeMicroseconds) or restricted ranges that are not suitable for
   reduced length encoding (such as dateTimeMilliseconds).

   Information Elements of type octetArray and string may be exported
   using any length, subject to restrictions on length specific to each
   Information Element, as noted in that Information Element's
   description.

 


<Claise, et al.>            Standards Track                    [Page 33]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


7.  Variable-Length Information Element

Shouldn't it be "elements" ?



   The IPFIX Template mechanism is optimized for fixed-length
   Information Elements [RFC5102bis].  Where an Information Element has
   a variable length, the following mechanism MUST be used to carry the
   length information for both the IETF and proprietary Information
   Elements.

   In the Template Set, the Information Element Field Length is recorded
   as 65535.  This reserved length value notifies the Collecting Process
   that length of the Information Element will be carried in the
   Information Element content itself. 

   In most cases, the length of the Information Element will be less
   than 255 octets.  The following length-encoding mechanism optimizes
   the overhead of carrying the Information Element length in this
   majority case.  The length is carried in the octet before the
   Information Element, as shown in Figure R. 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Length (< 255)|          Information Element                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      ... continuing as needed                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure R: Variable-Length Information Element (length < 255 octets) 

   The length may also be encoded into 3 octets before the Information
   element allowing the length of the Information Element to be greater
   than or equal to 255 octets. In this case, first octet of the Length
   field MUST be 255, and the length is carried in the second and third
   octets, as shown in Figure S. 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      255      |      Length (0 to 65535)      |       IE      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      ... continuing as needed                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure S: Variable-Length Information Element (length 0 to 65535
   octets)

   The octets carrying the length (either the first or the first three
   octets) MUST NOT be included in the length of the Information
 


<Claise, et al.>            Standards Track                    [Page 34]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Element.















































 


<Claise, et al.>            Standards Track                    [Page 35]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


8.  Template Management 

   This section describes the management of Templates and Options
   Templates at the Exporting and Collecting Processes. The goal of
   Template management is to ensure, to the extent possible, that the

What does that mean / add?


   Exporting Process and Collecting Process have a consistent view of
   the Templates and Options Templates used to encode and decode the
   Records sent from the Exporting Process to the Collecting Process.
   Achieving this goal is complicated somewhat by two factors: 1. the
   need to support the reuse of Template IDs within a Transport Session
   and 2. the need to support unreliable transmission for templates when
   UDP is used as the transport protocol for IPFIX Messages.

   The Template Management mechanisms defined in this section apply to
   IPFIX Message export on any supported Transport Protocol. Additional
   considerations specific to SCTP and UDP transport are given in
   sections 8.3 and 8.4, respectively.

   The Exporting Process assigns and maintains the Template IDs per
   Transport Session for the Exporter's Observation Domains. A newly

Arguably Exporters do not observe, therefore ODs don't belong to Exporters.


   created Template Record is assigned an unused Template ID by the
   Exporting Process. The Collecting Process MUST store all received
   Template Record information for the duration of each Transport
   Session until reuse or withdrawal as in section 8.1, except as noted
   in section 8.4, so that it can interpret the corresponding Data
   Records that are received in subsequent Data Sets. The Collecting
   Process MUST NOT assume that the Template IDs from a given Exporting
   Process refer to the same Templates as they did in previous Transport
   Sessions from the same Exporting Process. When a Transport Session is
   closed, the Collecting Process MUST discard all Templates received
   over that association and stop decoding IPFIX Messages that use those
   Templates.

Only if it's doing real-time decode. If it's storing Templates and Records in a database (file) then you absolutely do not want it to discard all the received Templates.



   If a specific Information Element is required by a Template, but is
   not present in observed packets, the Exporting Process MAY choose to
   export Flow Records without this Information Element in a Data Record
   defined by a new Template.

MAY... else, what are its choices?



   If an Information Element is required more than once in a Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process. For
   example, if a selected packet goes through two hash functions, and if
   the two hash values are sent within a single Template, the first
   occurrence of the hash value should belong to the first hash function
   in the Metering Process. For example, when exporting the two source
   IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address
   Information Element occurrence should be the IPv4 address of the
   outer header, while the second occurrence should be the address of
 


<Claise, et al.>            Standards Track                    [Page 36]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   the inner header. Collecting processes MUST properly handle Templates
   with multiple identical Information Elements.

NB this section applies to { first, last } in sections 4.2 and 4.3.



   The Exporting Process SHOULD transmit the Template Set and Options
   Template Set in advance of any Data Sets that use that (Options)
   Template ID, to help ensure that the Collector has the Template
   Record before receiving the first Data Record. Data Records that
   correspond to a Template Record MAY appear in the same and/or
   subsequent IPFIX Message(s). 

   This ensures that the Collecting Process normally receives Template
   Records from the Exporting Process before receiving Data Records.
   However, if the Template Records have not been received at the time
   Data Records are received, the Collecting Process MAY store the Data
   Records for a short period of time and decode them after the Template
   Records are received. In any case, a Collecting Process MUST NOT
   assume that the Data Set and the associated Template Set (or Options
   Template Set) are exported in the same IPFIX Message.

Store-and-wait only works for reliable and in-order transports. With an unreliable or out-of-order transport, an intervening TWM could have been lost (or still be pending), so the subsequently received Template doesn't apply to the previously received Data Records.

So perhaps we should do away with this MAY.

Section 8.2 says that Data Records MUST NOT be sent before Templates - although that has no bearing on their arrival time.



   Different Observation Domains from the same Transport Session MAY use
   the same Template ID value to refer to different Templates;
   Collecting Processes MUST properly handle this case.

   Options Templates and Templates which are related or interdependent
   (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent
   together in the same IPFIX Message.

8.1. Template Withdrawal and Redefinition

   Since a Template may have a lifetime at the Exporting Process
   independent of the Transport Session, IPFIX provides a mechanism for
   the withdrawal of templates and for the reuse of template IDs. This
   mechanism does not apply when UDP is used to transport IPFIX
   messages; for this case, see Section 8.4.

   Templates that will not be used further by an Exporting Process MUST
   be withdrawn by sending a Template Withdrawal Message. After
   receiving a Template Withdrawal, a Collecting Process MUST discard
   the Template and stop using it to interpret Data Sets.

It mustn't use the Template to interpret further Data Sets. However, it could keep the Template and use it to interpret previously-received Data Sets.



   A Template Withdrawal consists of a Template Record for the Template
   ID to be with a Field Count of 0. The format of a Template Withdrawal
   is shown in Figure T.

"A Template Withdrawal Message consists of a Template Record for the Template ID to be withdrawn, with a Field Count of 0."

"format of a Template Withdrawal Message..."







 


<Claise, et al.>            Standards Track                    [Page 37]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


    0                   1                   2                   3     
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |       Set ID = (2 or 3)       |          Length = 16          |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |          Template ID N        |        Field Count = 0        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |          Template ID ...      |        Field Count = 0        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Template ID M        |        Field Count = 0        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure T: Template Withdrawal Set Format  


   The Set ID field MUST contain the value 2 for Template Set Withdrawal
   and the value 3 for Options Template Set Withdrawal. Multiple

We're not withdrawing the (options) Template Set, but rather, the specified (options) Template itself.

Inconsistent terminology:
    "Template Withdrawal Set" (used three times, in the titles of Figures T, U, and V)
    "Template Set Withdrawal" (used twice here)
    "Template Withdrawal Message" (used seven times in the text).


   Template IDs MAY be withdrawn with a single Template Withdrawal, in
   that case, padding MAY be used.

This is a comma-splice; it should be a separate sentence. Anyway, why would a TWM be padded?



   A Template Withdrawal Message is an IPFIX Message containing Template
   Withdrawals. It withdraws Template IDs for the Observation Domain ID
   specified in the IPFIX Message Header. It MUST NOT contain new
   Template or Options Template Records, or any Data Sets. The Exporting

Why not? A Template could be withdrawn, redefined, used in a new Data Set, then withdrawn again all within a single Message, without any ambiguity.


   Process SHOULD NOT send a Template Withdrawal Message until
   sufficient time has elapsed to allow receipt and processing of and
   Data Records described by the withdrawn Templates; see section 8.2
   for more information on sequencing Template Withdrawals.

   The end of a Transport Session implicitly withdraws all the Templates
   used within the Transport Session, and Templates must be resent
   during subsequent Transport Sessions between an Exporting Process and
   Collecting Process. All Templates for a given Observation Domain MAY
   also be withdrawn using an All Templates Withdrawal, which withdraws

"All Templates Withdrawal Message" 


   the special Template ID 2; this is shown in Figure U. All Options

No it doesn't.


   Templates for a given observation Domain MAY likewise be withdrawn
   using an All Options Templates Withdrawal, which withdraws the
   special Template ID 3. Each of these Withdrawals MUST appear in a

No it doesn't.

Template IDs 2 and 3 have particular meanings in IPFIX, they're part of a reserved range (section 3.4.1). Exporters do not send Templates 2 and 3, so these cannot be withdrawn.

Also, Template IDs 2 and 3 aren't "special", they're "reserved".


   Template Withdrawal Message with no other Withdrawals.









 


<Claise, et al.>            Standards Track                    [Page 38]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


    0                   1                   2                   3     
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |             Set ID = 2        |          Length = 8           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |         Template ID = 2       |        Field Count = 0        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure U: All Templates Withdrawal Set Format 


    0                   1                   2                   3     
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |             Set ID = 3        |          Length = 8           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |         Template ID = 3       |        Field Count = 0        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Figure V: All Options Templates Withdrawal Set Format

Figure V is unreferenced.




   Template IDs MAY be reused for new Templates by sending a new
   Template Record or Options Template Record for a given Template ID
   after withdrawing the Template.

   If a Collecting Process receives a new Template Record or Options
   Template Record for an already-allocated Template ID, without having
   received a withdrawal, it MUST ignore the new Template Record and

This should say, "a TWM for that (options) Template Record".

"it MUST ignore the new (options) Template Record and"


   discard the old Template Record for the allocated ID; it SHOULD log

"discard the old (options) Template Record"

So this is basically a DoS vector? ie, if I can inject bogus Templates towards the collector, then it must discard both the bogus Template and the perfectly good Template, and therefore stop collecting data.


   the error.

   If a Collecting Process receives a Template Withdrawal for a Template

"Template Withdrawal Message"


   or Options Template it does not presently have stored, it MUST ignore
   the Template Withdrawal and SHOULD log the error.

"Template Withdrawal Message"



8.2   Sequencing Template Management Actions

   Since there is no guarantee of the ordering of exported IPFIX
   Messages across SCTP Streams or over UDP, an Exporting Process MUST
   sequence all template management actions (i.e., Template Records
   defining new templates and Template Withdrawals withdrawing them)

"Template Withdrawal Messages"


   using the Export Time field in the IPFIX Message Header.

So CPs must respect the Export Time rather than the delivery (arrival) order? Is there some sort of time flux going on here?



   An Exporting Process MUST NOT export a Data Set described by a new
   Template in an IPFIX Message with an Export Time before the Export
   Time of the IPFIX Message containing that Template. If a new Template

In simpler words, Templates must be sent before Data Sets. Or if they're not, then at least the later-sent Templates must have earlier Export Times. OK, I see how the time flux works.

Except, this contradicts store-and-wait in Section 8. Unless we're talking about the corner-corner case of Template is sent, CP restarts, Data is sent.


   and a Data Set described by it appear in the same IPFIX Message, the
 


<Claise, et al.>            Standards Track                    [Page 39]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Template Set containing the Template MUST appear before the Data Set
   in the Message.

   An Exporting Process MUST NOT export any Data Sets described by a
   withdrawn Template in IPFIX Messages with an Export Time after the
   Export Time of the IPFIX Message containing the Template Withdrawal

"Export Time of the TWM".


   withdrawing that Template.

Flux capacitor to the rescue again: you're saying that such Data Sets can be sent after the TWM provided their Export Time is earlier.



   Put another way, a Template only describes Records contained in IPFIX

Because the previous way was too complicated for mortals to comprehend :-(


   Messages with the same Export Time as the IPFIX Message containing
   Template Record, or a subsequent export time. Likewise, a Template
   Withdrawal is only in effect for IPFIX Messages with the same Export
   Time as the Template Withdrawal, or a subsequent Export Time.

No, a TWM does not withdraw subsequent templates.


   Collecting Processes MAY implement a buffer to handle out-of-order
   Template management events.

How exactly do you envisage that working? Put events in the buffer, sorted by time, and pop the topmost event after allowing some time delta?


This whole section became too confusing and unclear, so even I can barely understand it :-(



8.3.  Additional considerations for Template Management over SCTP

   Template Sets and Options Template Sets MAY be sent on any SCTP
   stream. Data Sets sent on a given SCTP stream MAY be represented by
   Template Records exported on any SCTP stream.

xref RFC6526 (per stream) here.



   Template Sets and Options Template Sets MUST be sent reliably and in
   order.

Why must they be in order? As long as they arrive before their corresponding Data Sets - unless an option is scoped to another option or a Template?



   Template Withdrawal Messages MAY be sent on any SCTP stream. Template
   Withdrawal Messages MUST be sent reliably, using SCTP-ordered

Why is that hyphenated?


   delivery. Template IDs MAY be reused by sending a Template Withdrawal
   Message and/or a new Template Record on a different SCTP stream than
   the stream on which the original Template was sent.

No. A Template can't be redefined simply by sending a new Template definition on another stream. With SCTP, the EP must explicitly withdraw the template before redefining it.



   Additional Template Management considerations are given in [IPFIX-
   PER-SCTP-STREAM], which specifies an extension to explicitly link

RFC6526.


   Templates with SCTP streams. In exchange for more restrictive rules
   on the assignment of Template Records to SCTP streams, this extension
   allows fast, reliable reuse of Template IDs and estimation of Data
   Record loss per Template.

8.4.  Additional considerations for Template Management over UDP

   Since UDP provides no method for reliable transmission of Templates,
   Exporting Processes using UDP as the Transport Protocol MUST
   periodically retransmit each active Template at regular intervals.
   The template retransmission interval MUST be configurable, as via the
   the templateRefreshTimeout and optionsTemplateRefreshTimeout defined
   in [IPFIX-CONF]. Default settings for these values are deployment-
   and application-specific.
 


<Claise, et al.>            Standards Track                    [Page 40]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Before exporting any Data Records described by a given Template
   Record or Options Template Record, especially in the case of Template
   ID reuse as in section 8.1, the Exporting Process SHOULD send
   multiple copies of the Template Record in separate IPFIX Message, in
   order to help ensure the Collecting Process has received it.

"Messages" plural.

Or more simply, prefix the Data Set with the corresponding Template.



   In order to minimize resource requirements for templates which have
   expired at the Exporting Process without being withdrawn, or in cases
   when the Template Withdrawal Message was lost between the Exporting
   Process and the Collecting Process, the Collecting Process MAY
   associate a lifetime with each Template received in a UDP Transport
   Session. Templates not refreshed by the Exporting Process within the
   lifetime can then be discarded by the Collecting Process. The
   template lifetime at the Collecting Process MAY be exposed by a
   configuration parameter, or MAY be derived from observation of the
   interval of periodic Template retransmissions from the Exporting
   Process. In this latter case, the Template lifetime SHOULD default to
   at least 3 times the observed retransmission rate.

The EP should export an option indicating the template lifetime it's using.



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

"IPFIX Device" == Exporter source address?

"Last Received" - is this the last received template definition, a byte count, a boolean, a timestamp, or some combination of these?



9. The Collecting Process's Side

   This section describes the handling of the IPFIX Protocol at the
   Collecting Process common to all Transport Protocols. Additional
   considerations for SCTP and UDP are given in Sections 9.1 and 9.2
   respectively. Template management at Collecting Processes is covered
   in Section 8.

   The Collecting Process MUST listen for association requests /
   connections to start new Transport Sessions from the Exporting
   Process.

   The Collecting Process MUST note the Information Element identifier
   of any Information Element that it does not understand and MAY
   discard that Information Element from the Flow Record.

From Flow Records, plural.



   The Collecting Process MUST accept padding in Data Records and
   Template Records.  The padding size is the Set Length minus the size
   of the Set Header (4 octets for the Set ID and the Set Length),
   modulo the Record size deduced from the Template Record.

Is this shown in any figures?



   The IPFIX protocol has a Sequence Number field in the Export header
   that increases with the number of IPFIX Data Records in the IPFIX
 


<Claise, et al.>            Standards Track                    [Page 41]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Message. The Collecting Process MAY detect out-of-sequence, dropped,
   or duplicate IPFIX Messages using this the Sequence Number. If it
   supports this mechanism, the Collecting Process SHOULD log
   out-of-sequence IPFIX Messages, as these could indicate resource
   exhaustion at the Exporting Process or the Collecting Process, an
   Exporting Process reset, packet loss due to congestion between the
   Exporting Process and the Collecting Process, or message injection.

   If the Collecting Process receives a malformed IPFIX Message, it MUST
   discard the IPFIX Message and SHOULD log the error. Note that non-
   zero Set padding does not constitute a malformed IPFIX Message.

What does constitute a malformed message? Some examples would be useful.



9.1.  Additional considerations for SCTP Collecting Processes

   The Exporting Process requests a number of streams to use for export
   at association setup time. An Exporting Process MAY request and
   support more than one stream per SCTP association.

9.2.  Additional considerations for UDP Collecting Processes

   A Transport Session for IPFIX Messages transported over UDP is
   defined from the point of view of the Exporting Process, and roughly
   corresponds to the time during which a given Exporting Process sends
   IPFIX messages over UDP to a given Collecting Process. Since this is
   difficult to detect at the Collecting Process, the Collecting Process
   MAY expire all Transport Session state after no IPFIX Messages are
   received from a given Exporting Process during a configurable idle
   timeout.

That's not quite accurate: the EP may have multiple transport sessions. The CP may expire a particular transport session's state regardless of whether IPFIX Messages continue to be exported for other transport sessions from the EP.



   The Collecting Process SHOULD accept Data Records without the
   associated Template Record (or other definitions) required to decode
   the Data Record.  If the Template Records (or other definitions such
   as Common Properties) have not been received at the time Data Records
   are received, the Collecting Process SHOULD store the Data Records
   for a short period of time and decode them after the Template Records
   (or other definitions) are received.  The short period of time MUST
   be lower than the lifetime of definitions associated with identifiers
   considered unique within the UDP session.

Per earlier comments, I think this is dangerous and we should do away with it.


10.  Transport Protocol 

   The IPFIX Protocol Specification has been designed to be transport
   protocol independent.  Note that the Exporter can export to multiple
   Collecting Processes using independent transport protocols. 

   The IPFIX Message Header 16-bit Length field limits the length of an
   IPFIX Message to 65535 octets, including the header.  A Collecting
   Process MUST be able to handle IPFIX Message lengths of up to 65535
 


<Claise, et al.>            Standards Track                    [Page 42]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   octets.















































 


<Claise, et al.>            Standards Track                    [Page 43]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


10.1.  Transport Compliance and Transport Usage 

   SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758]
   MUST be implemented by all compliant implementations. UDP [UDP] MAY
   also be implemented by compliant implementations. TCP [TCP] MAY also
   be implemented by compliant implementations.

   SCTP SHOULD be used in deployments where Exporters and Collectors are
   communicating over links that are susceptible to congestion. PR-SCTP
   is capable of providing any required degree of reliability.

   TCP MAY be used in deployments where Exporters and Collectors
   communicate over links that are susceptible to congestion, but SCTP
   is preferred due to its ability to limit back pressure on Exporters
   and its message versus stream orientation.

   UDP MAY be used, although it is not a congestion-aware protocol.
   However, in this case the IPFIX traffic between Exporter and
   Collector MUST be separately contained or provisioned to minimize the
   risk of congestion-related loss.

10.2.  SCTP 

   This section describes how IPFIX is transported over SCTP [RFC4960]
   using the PR-SCTP [RFC3758] extension.    

10.2.1.  Congestion Avoidance 

   The SCTP transport protocol provides the required level of congestion
   avoidance by design. 

   SCTP will detect congestion in the end-to-end path between the IPFIX
   Exporting Process and the IPFIX Collecting Process, and limit the
   transfer rate accordingly.  When an IPFIX Exporting Process has
   records to export, but detects that transmission by SCTP is
   temporarily impossible, it can either wait until sending is possible
   again, or it can decide to drop the record.  In the latter case, the
   dropped export data MUST be accounted for, so that the amount of
   dropped export data can be reported.

Say where it's accounted, ie in the Exporting Process Reliability Statistics Options Template (section 4.3).



10.2.2.  Reliability 

   The SCTP transport protocol is by default reliable, but has the
   capability to deliver messages with partial reliability [RFC3758]. 

   Using reliable SCTP messages for the IPFIX export is not in itself a
   guarantee that all Data Records will be delivered.  If there is
   congestion on the link from the Exporting Process to the Collecting
 


<Claise, et al.>            Standards Track                    [Page 44]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Process, or if a significant number of retransmissions are required,
   the send queues on the Exporting Process may fill up; the Exporting
   Process MAY either suspend, export, or discard the IPFIX Messages. 
   If Data Records are discarded the IPFIX Sequence Numbers used for
   export MUST reflect the loss of data.

10.2.3.  MTU 

   SCTP provides the required IPFIX Message fragmentation service based
   on path MTU discovery. 

10.2.4.  Association Establishment and Shutdown

   The IPFIX Exporting Process SHOULD initiate an SCTP association with
   the IPFIX Collecting Process.  By default, the Collecting Process
   listens for connections on SCTP port 4739.  By default, the
   Collecting Process listens for secure connections on SCTP port 4740

xref IANA for the ports.
ie, http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml


   (refer to the Security Considerations section).  By default, the
   Exporting Process tries to connect to one of these ports.  It MUST be
   possible to configure both the Exporting and Collecting Processes to
   use a different SCTP port.

A different port from the default; not a different port from each other!

Since this paragraph is repeated for UDP and TCP, why not put it in the generic section above?



   The Exporting Process MAY establish more than one association
   (connection "bundle" in SCTP terminology) to the Collecting Process. 

   An Exporting Process MAY support more than one active association to
   different Collecting Processes (including the case of different
   Collecting Processes on the same host).

   When an Exporting Process is shut down, it SHOULD shut down the SCTP
   association.

   When a Collecting Process no longer wants to receive IPFIX Messages,
   it SHOULD shut down its end of the association.  The Collecting
   Process SHOULD continue to receive and process IPFIX Messages until
   the Exporting Process has closed its end of the association. 

   When a Collecting Process detects that the SCTP association has been
   abnormally terminated, it MUST continue to listen for a new
   association establishment. 

   When an Exporting Process detects that the SCTP association to the
   Collecting Process is abnormally terminated, it SHOULD try to
   re-establish the association.

   Association timeouts SHOULD be configurable.


 


<Claise, et al.>            Standards Track                    [Page 45]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


10.2.5.  Failover

   If the Collecting Process does not acknowledge the attempt by the
   Exporting Process to establish an association, the Exporting Process
   should retry using the SCTP exponential backoff feature.  The
   Exporter MAY log an alarm if the time to establish the association
   exceeds a specified threshold, configurable on the Exporter. 

   If Collecting Process failover is supported by the Exporting Process,
   a second SCTP association MAY be opened in advance.

10.2.6.  Streams

   An Exporting Process MAY request more than one SCTP stream per
   association.  Each of these streams may be used for the transmission
   of IPFIX Messages containing Data Sets, Template Sets, and/or Options
   Template Sets. 

   Depending on the requirements of the application, the Exporting
   Process may send Data Sets with full or partial reliability, using
   ordered or out-of-order delivery, over any SCTP stream established
   during SCTP Association setup. 

   An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as
   per Section 4 of the PR-SCTP [RFC3758] specification when using
   partial reliability to transmit IPFIX Messages containing only Data
   Sets.

   However, Exporting Processes SHOULD mark such IPFIX Messages for
   retransmission for as long as resource or other constraints allow.

10.3.  UDP 

   This section describes how IPFIX is transported over UDP [UDP]. 

10.3.1.  Congestion Avoidance 

   UDP has no integral congestion-avoidance mechanism. Its use over
   congestion-sensitive network paths is therefore not recommended. UDP
   MAY be used in deployments where Exporters and Collectors always
   communicate over dedicated links that are not susceptible to
   congestion, i.e., links that are over-provisioned compared to the
   maximum export rate from the Exporters.

10.3.2.  Reliability 

   UDP is not a reliable transport protocol, and cannot guarantee
   delivery of messages.  IPFIX Messages sent from the Exporting Process
 


<Claise, et al.>            Standards Track                    [Page 46]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   to the Collecting Process using UDP may therefore be lost.  UDP MUST
   NOT be used unless the application can tolerate some loss of IPFIX
   Messages.

   The Collecting Process SHOULD deduce the loss and reordering of IPFIX
   Data Records by looking at the discontinuities in the IPFIX Sequence
   Number.  In the case of UDP, the IPFIX Sequence Number contains the
   total number of IPFIX Data Records sent for the UDP Transport Session
   prior to the receipt of this IPFIX Message, modulo 2^32.  A Collector
   SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
   by tracking the Sequence Number.  Templates sent from the Exporting
   Process to the Collecting Process using UDP as a transport MUST be
   re-sent at regular intervals, in case previous copies were lost.

Or in case the CP (re)started.



   Exporting Processes exporting IPFIX Messages via UDP MUST include a
   valid UDP checksum.

10.3.3.  MTU 

   The maximum size of exported messages MUST be configured such that 
   the total packet size does not exceed the path MTU.  If the path MTU
   is unknown, a maximum packet size of 512 octets SHOULD be used. 

10.3.4.  Session Establishment and Shutdown

   By default, the Collecting Process listens on the UDP port 4739.  By
   default, the Collecting Process listens for secure connections on UDP
   port 4740 (refer to the "Security Considerations" section).  By
   default, the Exporting Process tries to connect to one of these
   ports.  It MUST be possible to configure both the Exporting and
   Collecting Processes to use a different UDP port.

This is just repetition of 10.2.4.



   As UDP is a connectionless protocol, there is no real session
   establishment or shutdown for IPFIX over UDP. An Exporting Process
   starts sending IPFIX Messages to a Collecting Process at one point in
   time, and stops sending them at another point in time. This leads to
   some complications in template management, which are outlined in
   Section 8.4 above.

10.3.5.  Failover and Session Duplication

   Because UDP is not a connection-oriented protocol, the Exporting
   Process is unable to determine from the transport protocol that the
   Collecting Process is no longer able to receive the IPFIX Messages. 
   Therefore, it cannot invoke a failover mechanism.  However, the
   Exporting Process MAY duplicate the IPFIX Message to several
   Collecting Processes. 

 


<Claise, et al.>            Standards Track                    [Page 47]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


10.4.  TCP 

   The IPFIX Exporting Process initiates a TCP connection to the
   Collecting Process.  By default, the Collecting Process listens for
   connections on TCP port 4739.  By default, the Collecting Process
   listens for secure connections on TCP port 4740 (refer to the
   Security Considerations section).  By default, the Exporting Process
   tries to connect to one of these ports.  It MUST be possible to
   configure both the Exporting Process and the Collecting Process to
   use a different TCP port.

This is just repetition of 10.2.4 and 10.3.4.



   An Exporting Process MAY support more than one active connection to
   different Collecting Processes (including the case of different
   Collecting Processes on the same host). 

   The Exporter MAY log an alarm if the time to establish the connection
   exceeds a specified threshold, configurable on the Exporter. 

10.4.1.  Congestion Avoidance 

   TCP controls the rate at which data can be sent from the Exporting
   Process to the Collecting Process, using a mechanism that takes into
   account both congestion in the network and the capabilities of the
   receiver.

   Therefore, an IPFIX Exporting Process may not be able to send IPFIX
   Messages at the rate that the Metering Process generates it, either
   because of congestion in the network or because the Collecting
   Process cannot handle IPFIX Messages fast enough. As long as
   congestion is transient, the Exporting Process can buffer IPFIX
   Messages for transmission. But such buffering is necessarily limited,
   both because of resource limitations and because of timeliness
   requirements, so ongoing and/or severe congestion may lead to a
   situation where the Exporting Process is blocked.

If IPFIX Messages are delayed (whether in the EP, or in the network stack), should/must their header Export Time be rewritten?
In the latter (stack) case, this may not even be possible.



   When an Exporting Process has Data Records to export but the
   transmission buffer is full, and it wants to avoid blocking, it can
   decide to drop some Data Records. The dropped Data Records MUST be
   accounted for, so that the number of lost records can later be
   exported as in Section 4.3.

Say how they're accounted.



   When an Exporting Process finds that the rate at which records should
   be exported is consistently higher than the rate at which TCP sending
   permits, it SHOULD provide back pressure to the Metering Processes. 
   The Metering Process could then adapt by temporarily reducing the
   amount of data it generates, for example, using sampling or
   aggregation.

That has it's own issues, eg sampling is introduced or sampling rate changes -> data records can't be aggregated with previous records at the collector, until they're normalised.

Anyway, although sampling means the counts will be lower, the flow records will still exist - so the export bandwidth won't change much. The EP needs less flow records, as opposed to smaller counts within each record.



 


<Claise, et al.>            Standards Track                    [Page 48]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


10.4.2.  Reliability 

   TCP ensures reliable delivery of data from the Exporting Process to
   the Collecting Process. 

   In the case of TCP, the IPFIX Sequence Number contains the total
   number of IPFIX Data Records sent from this TCP connection, from the
   current Observation Domain by the Exporting Process, prior to the
   receipt of this IPFIX Message, modulo 2^32.

This is called out as if it's somehow different, which is misleading: this is unchanged regardless of transport, so it should be stated once generically.


10.4.3.  MTU

   As TCP offers a stream service instead of a datagram or sequential
   packet service, IPFIX Messages transported over TCP are instead
   separated using the Length field in the IPFIX Message Header. The
   Exporting Process can choose any valid length for exported IPFIX
   Messages, as TCP handles segmentation.

   However, if an Exporting Process exports data from multiple
   Observation Domains, it should be careful to choose IPFIX Message
   lengths appropriately to minimize head-of-line blocking between
   different Observation Domains.  Multiple TCP connections MAY be used
   to avoid head-of-line blocking between different Observation Domains.

10.4.4.  Connection Establishment, Shutdown, and Restart

   The IPFIX Exporting Process initiates a TCP connection to the
   Collecting Process.  By default, the Collecting Process listens for
   connections on TCP port 4739.  By default, the Collecting Process
   listens for secure connections on TCP port 4740 (refer to the
   Security Considerations section).  By default, the Exporting Process
   tries to connect to one of these ports.  It MUST be possible to
   configure both the Exporting Process and the Collecting Process to
   use a different TCP port.

This is unnecessary repetition of 10.2.4, 10.3.4, and 10.4.



   An Exporting Process MAY support more than one active connection to
   different Collecting Processes (including the case of different
   Collecting Processes on the same host). 

   The Exporter MAY log an alarm if the time to establish the connection
   exceeds a specified threshold, configurable on the Exporter. 

   When an Exporting Process is shut down, it SHOULD shut down the TCP
   connection.   

   When a Collecting Process no longer wants to receive IPFIX Messages,
   it SHOULD close its end of the connection.  The Collecting Process
   SHOULD continue to read IPFIX Messages until the Exporting Process
 


<Claise, et al.>            Standards Track                    [Page 49]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   has closed its end. 

   When a Collecting Process detects that the TCP connection to the
   Exporting Process has terminated abnormally, it MUST continue to
   listen for a new connection. 

   When an Exporting Process detects that the TCP connection to the
   Collecting Process has terminated abnormally, it SHOULD try to
   re-establish the connection.  Connection timeouts and retry schedules
   SHOULD be configurable.  In the default configuration, an Exporting
   Process MUST NOT attempt to establish a connection more frequently
   than once per minute.

10.4.5.  Failover

   If the Collecting Process does not acknowledge the attempt by the
   Exporting Process to establish a connection, it will retry using the
   TCP exponential backoff feature.   

   If Collecting Process failover is supported by the Exporting Process,
   a second TCP connection MAY be opened in advance.  

11.  Security Considerations 

   The security considerations for the IPFIX protocol have been derived
   from an analysis of potential security threats, as discussed in the
   "Security Considerations" section of IPFIX requirements [RFC3917]. 
   The requirements for IPFIX security are as follows: 

   1. IPFIX must provide a mechanism to ensure the confidentiality of
      IPFIX data transferred from an Exporting Process to a Collecting
      Process, in order to prevent disclosure of Flow Records
      transported via IPFIX. 

   2. IPFIX must provide a mechanism to ensure the integrity of IPFIX
      data transferred from an Exporting Process to a Collecting
      Process, in order to prevent the injection of incorrect data or
      control information (e.g., Templates) into an IPFIX Message
      stream.

   3. IPFIX must provide a mechanism to authenticate IPFIX Collecting
      and Exporting Processes, to prevent the collection of data from an
      unauthorized Exporting Process or the export of data to an
      unauthorized Collecting Process. 

   Because IPFIX can be used to collect information for network
   forensics and billing purposes, attacks designed to confuse, disable,
   or take information from an IPFIX collection system may be seen as a
 


<Claise, et al.>            Standards Track                    [Page 50]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   prime objective during a sophisticated network attack. 

   An attacker in a position to inject false messages into an IPFIX
   Message stream can either affect the application using IPFIX (by
   falsifying data), or the IPFIX Collecting Process itself (by
   modifying or revoking Templates, or changing options); for this
   reason, IPFIX Message integrity is important. 

   The IPFIX Messages themselves may also contain information of value
   to an attacker, including information about the configuration of the
   network as well as end-user traffic and payload data, so care must be
   taken to confine their visibility to authorized users.  When an
   Information Element containing end-user payload information is
   exported, it SHOULD be transmitted to the Collecting Process using a
   means that secures its contents against eavesdropping.  Suitable
   mechanisms include the use of either a direct point-to-point
   connection or the use of an encryption mechanism.  It is the
   responsibility of the Collecting Process to provide a satisfactory
   degree of security for this collected data, including, if necessary,
   anonymization of any reported data. 

11.1.  Applicability of TLS and DTLS 

   Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC4347] were designed to provide the
   confidentiality, integrity, and authentication assurances required by
   the IPFIX protocol, without the need for pre-shared keys.

   With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC4347]
   MUST be implemented.  If UDP is selected as the IPFIX transport
   protocol, DTLS [RFC4347] MUST be implemented.  If TCP is selected as
   the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. 

   Note that DTLS is selected as the security mechanism for SCTP. 
   Though TLS bindings to SCTP are defined in [RFC3436], they require
   all communication to be over reliable, bidirectional streams, and
   require one TLS connection per stream.  This arrangement is not
   compatible with the rationale behind the choice of SCTP as an IPFIX
   transport protocol. 

   Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man
   in the middle may attempt to take data out of an association and fool
   the sender into thinking that the data was actually received by the
   peer. In generic TLS for SCTP (and/or TCP), this is not possible.
   This means that the removal of a message may become hidden from the
   sender or receiver. Another vulnerability of using SCTP with DTLS is
   that someone could inject SCTP control information to shut down the
   SCTP association, effectively generating a loss of IPFIX Messages if
 


<Claise, et al.>            Standards Track                    [Page 51]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   those are buffered outside of the SCTP association. Techniques such
   as [RFC6083] could be used to overcome these vulnerabilities.

   When using DTLS over SCTP, the Exporting Process MUST ensure that
   each IPFIX Message is sent over the same SCTP stream that would be
   used when sending the same IPFIX Message directly over SCTP.  Note
   that DTLS may send its own control messages on stream 0 with full
   reliability; however, this will not interfere with the processing of
   stream 0 IPFIX Messages at the Collecting Process, because DTLS
   consumes its own control messages before passing IPFIX Messages up to
   the application layer.

   When using DTLS over SCTP or UDP, the Heartbeat Extention [RFC6520]

Extension.


   SHOULD be used, especially on long-lived Transport Sessions, to
   ensure that the association remains active.

11.2.  Usage 

   The IPFIX Exporting Process initiates the communication to the IPFIX 
    Collecting Process, and acts as a TLS or DTLS client according to

NB wrong indentation.


   [RFC5246] and [RFC4347], while the IPFIX Collecting Process acts as a
   TLS or DTLS server.  The DTLS client opens a secure connection on the
   SCTP port 4740 of the DTLS server if SCTP is selected as the
   transport protocol.  The TLS client opens a secure connection on the
   TCP port 4740 of the TLS server if TCP is selected as the transport
   protocol.  The DTLS client opens a secure connection on the UDP port
   4740 of the DTLS server if UDP is selected as the transport
   protocol.

Cite IANA for port 4740.



11.3.  Authentication 

   IPFIX Exporting Processes and IPFIX Collecting Processes are
   identified by the fully qualified domain name of the interface on
   which IPFIX Messages are sent or received, for purposes of X.509
   client and server certificates as in [RFC5280]. 

   To prevent man-in-the-middle attacks from impostor Exporting or
   Collecting Processes, the acceptance of data from an unauthorized
   Exporting Process, or the export of data to an unauthorized
   Collecting Process, strong mutual authentication via asymmetric keys
   MUST be used for both TLS and DTLS.  Each of the IPFIX Exporting and
   Collecting Processes MUST verify the identity of its peer against its
   authorized certificates, and MUST verify that the peer's certificate
   matches its fully qualified domain name, or, in the case of SCTP, the
   fully qualified domain name of one of its endpoints. 



 


<Claise, et al.>            Standards Track                    [Page 52]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   The fully qualified domain name used to identify an IPFIX Collecting
   Process or Exporting Process may be stored either in a subjectAltName
   extension of type dNSName, or in the most specific Common Name field
   of the Subject field of the X.509 certificate.  If both are present,
   the subjectAltName extension is given preference. 

   Internationalized domain names (IDN) in either the subjectAltName
   extension of type dNSName or the most specific Common Name field of
   the Subject field of the X.509 certificate MUST be encoded using
   Punycode [RFC3492] as described in [RFC5891], "Conversion
   Operations".

11.4.  Protection against DoS Attacks 

   An attacker may mount a denial-of-service (DoS) attack against an
   IPFIX collection system either directly, by sending large amounts of
   traffic to a Collecting Process, or indirectly, by generating large
   amounts of traffic to be measured by a Metering Process.

   Direct denial-of-service attacks can also involve state exhaustion,
   whether at the transport layer (e.g., by creating a large number of
   pending connections), or within the IPFIX Collecting Process itself
   (e.g., by sending Flow Records pending Template or scope information,
   a large amount of Options Template Records, etc.). 

   SCTP mandates a cookie-exchange mechanism designed to defend against
   SCTP state exhaustion denial-of-service attacks.  Similarly, TCP
   provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN
   cookies SHOULD be used by any Collecting Process accepting TCP
   connections.  DTLS also provides cookie exchange to protect against
   DTLS server state exhaustion. 

   The reader should note that there is no way to prevent fake IPFIX
   Message processing (and state creation) for UDP & SCTP communication.
    The use of TLS and DTLS can obviously prevent the creation of fake

NB wrong indentation.


   states, but they are themselves prone to state exhaustion attacks. 
   Therefore, Collector rate limiting SHOULD be used to protect TLS &
   DTLS (like limiting the number of new TLS or DTLS session per second
   to a sensible number). 

   IPFIX state exhaustion attacks can be mitigated by limiting the rate
   at which new connections or associations will be opened by the
   Collecting Process, the rate at which IPFIX Messages will be accepted
   by the Collecting Process, and adaptively limiting the amount of
   state kept, particularly records waiting on Templates.  These rate
   and state limits MAY be provided by a Collecting Process; if
   provided, the limits SHOULD be user configurable.  

 


<Claise, et al.>            Standards Track                    [Page 53]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Additionally, an IPFIX Collecting Process can eliminate the risk of
   state exhaustion attacks from untrusted nodes by requiring TLS or
   DTLS mutual authentication, causing the Collecting Process to accept
   IPFIX Messages only from trusted sources. 

   With respect to indirect denial of service, the behavior of IPFIX
   under overload conditions depends on the transport protocol in use. 
   For IPFIX over TCP, TCP congestion control would cause the flow of
   IPFIX Messages to back off and eventually stall, blinding the IPFIX
   system.  SCTP improves upon this situation somewhat, as some IPFIX
   Messages would continue to be received by the Collecting Process due
   to the avoidance of head-of-line blocking by SCTP's multiple streams
   and partial reliability features, possibly affording some visibility
   of the attack.  The situation is similar with UDP, as some datagrams
   may continue to be received at the Collecting Process, effectively
   applying sampling to the IPFIX Message stream, implying that some
   forensics may be left.

   To minimize IPFIX Message loss under overload conditions, some
   mechanism for service differentiation could be used to prioritize
   IPFIX traffic over other traffic on the same link.  Alternatively,
   IPFIX Messages can be transported over a dedicated network.  In this
   case, care must be taken to ensure that the dedicated network can
   handle the expected peak IPFIX Message traffic. 

11.5.  When DTLS or TLS Is Not an Option 

   The use of DTLS or TLS might not be possible in some cases due to
   performance issues or other operational concerns.  

   Without TLS or DTLS mutual authentication, IPFIX Exporting Processes
   and Collecting Processes can fall back on using IP source addresses
   to authenticate their peers.  A policy of allocating Exporting
   Process and Collecting Process IP addresses from specified address
   ranges, and using ingress filtering to prevent spoofing, can improve
   the usefulness of this approach.  Again, completely segregating IPFIX
   traffic on a dedicated network, where possible, can improve security
   even further.  In any case, the use of open Collecting Processes
   (those that will accept IPFIX Messages from any Exporting Process
   regardless of IP address or identity) is discouraged. 

   Modern TCP and SCTP implementations are resistant to blind insertion
   attacks (see [RFC1948], [RFC4960]); however, UDP offers no such
   protection.  For this reason, IPFIX Message traffic transported via
   UDP and not secured via DTLS SHOULD be protected via segregation to a
   dedicated network. 


 


<Claise, et al.>            Standards Track                    [Page 54]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


11.6.  Logging an IPFIX Attack 

   IPFIX Collecting Processes MUST detect potential IPFIX Message
   insertion or loss conditions by tracking the IPFIX Sequence Number,
   and SHOULD provide a logging mechanism for reporting out-of-sequence
   messages.  Note that an attacker may be able to exploit the handling
   of out-of-sequence messages at the Collecting Process, so care should
   be taken in handling these conditions.  For example, a Collecting
   Process that simply resets the expected Sequence Number upon receipt
   of a later Sequence Number could be temporarily blinded by deliberate
   injection of later Sequence Numbers. 

   IPFIX Exporting and Collecting Processes SHOULD log any connection
   attempt that fails due to authentication failure, whether due to
   being presented an unauthorized or mismatched certificate during TLS
   or DTLS mutual authentication, or due to a connection attempt from an
   unauthorized IP address when TLS or DTLS is not in use. 

   IPFIX Exporting and Collecting Processes SHOULD detect and log any
   SCTP association reset or TCP connection reset. 

11.7.  Securing the Collector 

   The security of the Collector and its implementation is important to
   achieve overall security.  However, it is outside the scope of this
   document.

12.  IANA Considerations 

   IPFIX Messages use two fields with assigned values.  These are the
   IPFIX Version Number, indicating which version of the IPFIX Protocol
   was used to export an IPFIX Message, and the IPFIX Set ID, indicating
   the type for each set of information within an IPFIX Message.   

   The IPFIX Version Number value of 10 is reserved for the IPFIX
   protocol specified in this document.  Set ID values of 0 and 1 are
   not used for historical reasons [RFC3954].  The Set ID value of 2 is

Again, "not used for historical reasons" is ambiguous (ie, could be used for other reasons).


   reserved for the Template Set.  The Set ID value of 3 is reserved for
   the Options Template Set.  All other Set ID values from 4 to 255 are
   reserved for future use.  Set ID values above 255 are used for Data
   Sets.

   New assignments in either IPFIX Version Number or IPFIX Set ID
   assignments require a Standards Action [RFC5226], i.e., they are to
   be made via Standards Track RFCs approved by the IESG. 



 


<Claise, et al.>            Standards Track                    [Page 55]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


Appendix A.  IPFIX Encoding Examples

   This appendix, which is a not a normative reference, contains IPFIX
   encoding examples. 

   Let's consider the example of an IPFIX Message composed of a 
   Template Set, a Data Set (which contains three Data Records), an
   Options Template Set and a Data Set (which contains 2 Data Records
   related to the previous Options Template Record).   

   IPFIX Message: 

   +--------+------------------------------------------. . . 
   |        | +--------------+ +------------------+  
   |Message | | Template     | | Data             |  
   | Header | | Set          | | Set              |   . . . 
   |        | | (1 Template) | | (3 Data Records) |  
   |        | +--------------+ +------------------+  
   +--------+------------------------------------------. . . 

        . . .-------------------------------------------+ 
              +------------------+ +------------------+ | 
              | Options          | | Data             | | 
       . . .  | Template Set     | | Set              | | 
              | (1 Template)     | | (2 Data Records) | | 
              +------------------+ +------------------+ | 
        . . .-------------------------------------------+ 

A.1.  Message Header Example 

   The Message Header is composed of: 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Version = 0x000a          |         Length = 152          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Export Time                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Sequence Number                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     Observation Domain ID                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 






 


<Claise, et al.>            Standards Track                    [Page 56]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


A.2.  Template Set Examples 

A.2.1.  Template Set Using IETF-Specified Information Elements  


   We want to report the following Information Elements: 

   - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], 
     with a length of 4 octets 

   - The IPv4 destination IP address: destinationIPv4Address in
     [RFC5102bis], with a length of 4 octets

   - The next-hop IP address (IPv4): ipNextHopIPv4Address in
     [RFC5102bis], with a length of 4 octets

   - The number of packets of the Flow: packetDeltaCount in
     [RFC5102bis], with a length of 4 octets

   - The number of octets of the Flow: octetDeltaCount in
     [RFC5102bis], with a length of 4 octets

   Therefore, the Template Set will be composed of the following: 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Set ID = 2            |      Length = 28 octets       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Template ID 256         |       Field Count = 5         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0|    sourceIPv4Address = 8    |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0| destinationIPv4Address = 12 |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0|    packetDeltaCount = 2     |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0|    octetDeltaCount = 1      |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.2.2.  Template Set Using Enterprise-Specific Information Elements  

   We want to report the following Information Elements:  

   - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with
     a length of 4 octets 
 


<Claise, et al.>            Standards Track                    [Page 57]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   - The IPv4 destination IP address: destinationIPv4Address in
     [RFC5102bis], with a length of 4 octets 

   - An enterprise-specific Information Element representing 
     proprietary information, with a type of 15 and a length of 4 

   - The number of packets of the Flow: packetDeltaCount in 
     [RFC5102bis], with a length of 4 octets  

   - The number of octets of the Flow: octetDeltaCount in  [RFC5102bis],

"in [RFC" is double-spaced.


     with a length of 4 octets 

   Therefore, the Template Set will be composed of the following:  

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |         Set ID = 2            |      Length = 32 octets       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |       Template ID 257         |       Field Count = 5         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |0|    sourceIPv4Address = 8    |       Field Length = 4        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |0| destinationIPv4Address = 12 |       Field Length = 4        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |1| Information Element Id. = 15|       Field Length = 4        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                       Enterprise number                       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |0|    packetDeltaCount = 2     |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |0|    octetDeltaCount = 1      |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 















 


<Claise, et al.>            Standards Track                    [Page 58]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


A.3.  Data Set Example 

   In this example, we report the following three Flow Records: 

   Src IP addr. | Dst IP addr.  | Next Hop addr. | Packet | Octets  
                |               |                | Number | Number 
   ------------------------------------------------------------------ 
   192.0.2.12   | 192.0.2.254   | 192.0.2.1      | 5009   | 5344385 
   192.0.2.27   | 192.0.2.23    | 192.0.2.2      | 748    | 388934 
   192.0.2.56   | 192.0.2.65    | 192.0.2.3      | 5      | 6534 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Set ID = 256         |          Length = 64          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.12                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.254                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.1                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             5009                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            5344385                            |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.27                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.23                           |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.2                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              748                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             388934                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.56                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.65                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.0.2.3                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               5                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              6534                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Note that padding is not necessary in this example. 
 


<Claise, et al.>            Standards Track                    [Page 59]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


A.4.  Options Template Set Examples 

A.4.1.  Options Template Set Using IETF-Specified Information Elements 
   

   Per line card (the router being composed of two line cards), we want
   to report the following Information Elements:  

   - Total number of IPFIX Messages: exportedMessageTotalCount
     [RFC5102bis], with a length of 2 octets  

   - Total number of exported Flows: exportedFlowRecordTotalCount
     [RFC5102bis], with a length of 2 octets  

   The line card, which is represented by the lineCardId Information
   Element [RFC5102bis], is used as the Scope Field. 

   Therefore, the Options Template Set will be: 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Set ID = 3            |          Length = 24          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Template ID 258         |        Field Count = 3        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Scope Field Count = 1     |0|     lineCardId = 141        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Scope 1 Field Length = 4    |0|exportedMessageTotalCount=41 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Field Length = 2        |           Padding             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.4.2.  Options Template Set Using Enterprise-Specific Information
        Elements

   Per line card (the router being composed of two line cards), we want 
   to report the following Information Elements:  

      - Total number of IPFIX Messages: exportedMessageTotalCount
        [RFC5102bis], with a length of 2 octets  

      - An enterprise-specific number of exported Flows, with a type of
        42 and a length of 4 octets 

   The line card, which is represented by the lineCardId Information
 


<Claise, et al.>            Standards Track                    [Page 60]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Element [RFC5102bis], is used as the Scope Field. 

   The format of the Options Template Set is as follows:  

     0                   1                   2                   3  
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |         Set ID = 3            |          Length = 28          |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Template ID 259         |        Field Count = 3        |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |     Scope Field Count = 1     |0|     lineCardId = 141        |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |   Scope 1 Field Length = 4    |0|exportedFlowRecordTotalCo.=41|  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Field Length = 2        |1|Information Element Id. = 42 |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Field Length = 4        |       Enterprise number      ...  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   ...       Enterprise number      |           Padding             |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.4.3.  Options Template Set Using an Enterprise-Specific Scope 

   In this example, we want to export the same information as in the
   example in Section A.4.1:  

      - Total number of IPFIX Messages: exportedMessageTotalCount
        [RFC5102bis], with a length of 2 octets  

      - Total number of exported Flows: exportedFlowRecordTotalCount
        [RFC5102bis], with a length of 2 octets  

   But this time, the information pertains to a proprietary scope, 
   identified by enterprise-specific Information Element number 123.  













 


<Claise, et al.>            Standards Track                    [Page 61]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   The format of the Options Template Set is now as follows:  

     0                   1                   2                   3  
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |         Set ID = 3            |          Length = 28          |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Template ID 260         |        Field Count = 3        |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |     Scope Field Count = 1     |1|Scope 1 Infor. El. Id. = 123 |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |    Scope 1 Field Length = 4   |       Enterprise Number      ... 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   ...       Enterprise Number      |0|exportedMessageTotalCount=41 |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |       Field Length = 2        |           Padding             |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

A.4.4.  Data Set Using an Enterprise-Specific Scope 

   In this example, we report the following two Data Records: 

   Enterprise field 123   | IPFIX Message  | Exported Flow Records 
   ------------------------------------------------------------------- 
   1                      | 345            | 10201     
   2                      | 690            | 20402 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |      Set ID = 260             |         Length = 20           |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                               1                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |             345               |            10201              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                               2                               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |             690               |            20402              |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 






 


<Claise, et al.>            Standards Track                    [Page 62]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


A.5.  Variable-Length Information Element Examples 

A.5.1.  Example of Variable-Length Information Element with Length
        Inferior to 255 Octets   

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       5       |          5 octet Information Element          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.5.2.  Example of Variable-Length Information Element with 3 Octet
        Length Encoding   

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      255      |             1000              |    IE ...     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                1000 octet Information Element                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   :                              ...                              : 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             ... IE            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

References 

Normative References

FYI (for the RFC editor) the following-lines indent is off by one in all the following citations:

 


   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3436]      Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
                   Layer Security over Stream Control Transmission
                   Protocol", RFC 3436, December 2002.   

   [RFC3492]      Costello, A., "Punycode: A Bootstring encoding of
                   Unicode for Internationalized Domain Names in
                   Applications (IDNA)", RFC 3492, March 2003.  

   [RFC3758]      Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
                   Conrad, "Stream Control Transmission Protocol (SCTP)
                   Partial Reliability Extension", RFC 3758, May 2004.  

 


<Claise, et al.>            Standards Track                    [Page 63]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   [RFC4347]      Rescorla, E. and N. Modadugu, "Datagram Transport
                   Layer Security", RFC 4347, April 2006.

** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347)

  

   [RFC4960]      Stewart, R., Ed., "Stream Control Transmission
                   Protocol", RFC 4960, September 2007. 

   [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26, RFC
                   5226, May 2008. 

   [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                   Security (TLS) Protocol Version 1.2", RFC 5246,
                   August 2008.

   [RFC5280]      Cooper, D., Santesson, S., Farrell, S. Boeyen, S.
                   Housley, R., and W. Polk, "Internet X.509 Public Key
                   Infrastructure Certificate and Certificate Revocation
                   List (CRL) Profile", RFC 5280, April 2008. 

   [RFC5905]      Mills, D., Delaware, U., Martin, J., Burbank, J. and
                   W. Kasch, "Network Time Protocol Version 4: Protocol
                   and Algorithms Specification", RFC 5905, June 2010

   [RFC5891]      J. Klensin, "Internationalized Domain Names in
                   Applications (IDNA): Protocol", RFC 5891, August
                   2010.

   [RFC6520]      Seggelmann, R., Tuexen, M., and Williams, M.,
                   "Transport Layer Security (TLS) and Datagram
                   Transport Layer Security (DTLS) Heartbeat Extension",
                   RFC 6520, February 2012.

   [TCP]          Postel, J., "Transmission Control Protocol", STD 7,
                   RFC 793, September 1981.

   [UDP]          Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                   August 1980.

   [RFC5102bis]   Quittek, J., Bryant S., Claise, B., Aitken, P., and J.
                   Meyer, "Information Model for IP Flow Information
                   Export", draft-claise-ipfix-information-model-
                   rfc5102bis-01.txt, Work in Progress, October 2011.

-- Possible downref: Normative reference to a draft: ref. 'RFC5102bis' 



Informative References 

   [PEN]          IANA Private Enterprise Numbers registry
                   http://www.iana.org/assignments/enterprise-numbers. 
                   
 


<Claise, et al.>            Standards Track                    [Page 64]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   [RFC1948]      Bellovin, S., "Defending Against Sequence Number
                   Attacks", RFC 1948, May 1996.

-- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) 



   [RFC2579]      McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                   "Textual Conventions for SMIv2", STD 58, RFC 2579,
                   April 1999. 

   [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, RFC 3550, July 2003.  

   [RFC3917]      Quittek, J., Zseby, T., Claise, B., and S. Zander,
                   "Requirements for IP Flow Information Export
                   (IPFIX)", RFC 3917, October 2004. 

   [RFC3954]      Claise, B., Ed., "Cisco Systems NetFlow Services
                   Export Version 9", RFC 3954, October 2004.

   [RFC5101]      Claise, B., Ed., "Bidirectional Flow Export Using IP
                   Flow Information Export (IPFIX)", RFC 5103, January
                   2008.

   [RFC5103]      Trammell, B., and E. Boschi, "Specification of the IP
                   Flow Information Export (IPFIX) Protocol for the
                   Exchange of IP Traffic Flow Information", RFC 5101,
                   January 2008.

   [RFC5153]      Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP
                   Flow Information Export (IPFIX) Implementation
                   Guidelines", RFC5153, April 2008

   [RFC5470]      Sadasivan, G., Brownlee, N., Claise, B., and J.
                   Quittek, "Architecture for IP Flow Information
                   Export", RFC5470, March 2009.

   [RFC5472]      Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
                   "IP Flow Information Export (IPFIX) Applicability",
                   RFC5472, March 2009. 

   [RFC5471]      Schmoll, C., Aitken, P., and B. Claise, "Guidelines
                   for IP Flow Information Export (IPFIX) Testing",
                   RFC5471, March 2009

   [RFC5473]      Boschi, E., Mark, L., and B. Claise, "Reducing
                   Redundancy in IP Flow Information Export (IPFIX) and
                   Packet Sampling (PSAMP) Reports", RFC5473, March 2009

   [RFC5610]      Boschi, E., Trammell, B., Mark, L., and T. Zseby,
 


<Claise, et al.>            Standards Track                    [Page 65]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


                   "Exporting Type Information for IP Flow Information
                   Export (IPFIX) Information Elements", July 2009.

   [RFC6083]      Tuexen, M., Seggelman, R. and E. Rescola, "Datagram
                   Transport Layer Security (DTLS) for Stream Control
                   Transmission Protocol (SCTP)", RFC6083, January 2011.

   [RFC6313]      Claise, B., Dhandapani, G., Aitken, P, and S. Yates,
                   "Export of Structured Data in IP Flow Information
                   Export (IPFIX)", RFC6313, July 2011.

   [RFC6183]      Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi,
                   "IP Flow Information Export (IPFIX) Mediation:
                   Framework", RFC6183, April 2011.

   [POSIX.1]      IEEE 1003.1-2008 - IEEE Standard for Information
                   Technology - Portable Operating System Interface,
                   IEEE, 2008. 

   [IEEE.754.1985] Institute of Electrical and Electronics Engineers,
                   "Standard for Binary Floating-Point Arithmetic", IEEE
                   Standard 754, August 1985.

   [IPFIX-CONF]   Muenz, G., Claise, B., and P. Aitken, "Configuration
                   Data Model for IPFIX and PSAMP", draft-ietf-ipfix-
                   configuration-model-10, Work in Progress, July 2011.

== Outdated reference: draft-ietf-ipfix-configuration-model has been published as RFC 6728



   [IPFIX-PER-SCTP-STREAM] Claise, B., Aitekn, P., Johnson, A. and G.
                   Muenz, "IPFIX Export per SCTP Stream", draft-ietf-
                   ipfix-export-per-sctp-stream-08, Work in Progress,
                   May 2010.

== Outdated reference: draft-ietf-ipfix-export-per-sctp-stream has been published as RFC 6526


P.


   [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 
                   "Specification of the Protocol for IPFIX Mediations",
                   draft-claise-ipfix-mediation-protocol-04, Work in
                   Progress, July 2011.

   [RFC5815bis]   Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
                   "Definitions of Managed Objects for IP Flow
                   Information Export", draft-dkcm-ipfix-rfc5815bis-
                   00.txt, Work in Progress, October 2011.

Acknowledgments 

   We would like to thank the following persons: Ganesh Sadasivan for
   his significant contribution during the initial phases of the
   protocol specification; Juergen Quittek for the coordination job
   within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and
 


<Claise, et al.>            Standards Track                    [Page 66]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Andrew Johnson for the thorough reviews; Randall Stewart and Peter
   Lei for their SCTP expertise and contributions; Martin Djernaes for
   the first essay on the SCTP section; Michael Behringer and Eric
   Vyncke for their advice and knowledge in security; Michael Tuexen for
   his help regarding the DTLS section; Elisa Boschi for her
   contribution regarding the improvement of SCTP sections; Mark
   Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter
   Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul
   Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical
   reviews and feedback.

Authors' Addresses  

   Benoit Claise (Ed.)
   Cisco Systems 
   De Kleetlaan 6a b1 
   1831 Diegem 
   Belgium 

   Phone: +32 2 704 5622 
   EMail: bclaise@cisco.com 


   Brian Trammell (Ed.)
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   EMail: trammell@tik.ee.ethz.ch


   Stewart Bryant 
   Cisco Systems, Inc. 
   250, Longwater, 
   Green Park, 
   Reading, RG2 6GB, 
   United Kingdom 

   Phone: +44 (0)20 8824-8828             
   EMail: stbryant@cisco.com 






 


<Claise, et al.>            Standards Track                    [Page 67]

Internet-Draft        IPFIX Protocol Specification     November 20, 2012


   Simon Leinen 
   SWITCH 
   Werdstrasse 2
   P.O. Box 
   8021 Zurich 
   Switzerland 

   Phone: +41 44 268 1536 
   EMail: simon.leinen@switch.ch 


   Thomas Dietz 
   NEC Europe Ltd. 
   NEC Laboratories Europe
   Network Research Division
   Kurfuersten-Anlage 36 
   69115 Heidelberg 
   Germany

   Phone: +49 6221 4342-128 
   EMail: Thomas.Dietz@nw.neclab.eu 






























<Claise, et al.>            Standards Track                    [Page 68]

--------------080303060203060507050408-- From andrewf@plixer.com Mon Dec 10 09:04:02 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 58B8B21F8201 for ; Mon, 10 Dec 2012 09:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WaLO6HdYUFkh for ; Mon, 10 Dec 2012 09:04:01 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1721F8419 for ; Mon, 10 Dec 2012 09:04:01 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Dec 2012 12:03:54 -0500 Message-ID: <50C615FA.5040403@plixer.com> Date: Mon, 10 Dec 2012 12:03:54 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: Paul Aitken , IETF IPFIX Working Group References: <50C5F8CC.5070609@cisco.com> In-Reply-To: <50C5F8CC.5070609@cisco.com> Content-Type: multipart/alternative; boundary="------------050401080604080803090802" X-OriginalArrivalTime: 10 Dec 2012 17:03:54.0672 (UTC) FILETIME=[56008300:01CDD6F8] Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-protocol-rfc5101bis-03 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, 10 Dec 2012 17:04:02 -0000 This is a multi-part message in MIME format. --------------050401080604080803090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/10/2012 09:59 AM, Paul Aitken wrote: > draft-ietf-ipfix-protocol-rfc5101bis-03 Dear all, > > Here's a comprehensive review of draft-ietf-ipfix-protocol-rfc5101bis-03 : > > >> >> >> >> >> Network Working Group B. Claise, Ed. >> Internet Draft Cisco Systems, Inc. >> Obsoletes: 5101 B. Trammell, Ed. >> Category: Standards Track ETH Zurich >> Expires: May 24, 2013 November 20, 2012 >> >> >> Specification of the IP Flow Information eXport (IPFIX) Protocol [ snip ] >> 6.1.9 dateTimeMicroseconds >> >> The data type dateTimeMicroseconds is a 64-bit field encoded >> according to the NTP Timestamp format as defined in section 6 of >> [RFC5905]. This field is made up of two unsigned 32-bit integers in >> network byte order, Seconds and Fraction. The Seconds field is the >> number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. >> The Fraction field is the fractional number of seconds in units of >> 1/(2^32) seconds (approximately 233 picoseconds). It can represent >> dates beginning between 1 January 1900 and 8 February 2036. > > Since we're already over 80% through that range, it seems worth moving > the epoch to 1/1/2000. > I don't disagree that this would have made sense, but can we reasonably make this change in 5101bis? Will this make a 5101 collector incorrectly interpret 5101bis? Maybe I am missing something. -Andrew --------------050401080604080803090802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/10/2012 09:59 AM, Paul Aitken wrote:
draft-ietf-ipfix-protocol-rfc5101bis-03 Dear all,

Here's a comprehensive review of draft-ietf-ipfix-protocol-rfc5101bis-03 :


 



Network Working Group                                     B. Claise, Ed.
Internet Draft                                       Cisco Systems, Inc.
Obsoletes: 5101                                         B. Trammell, Ed.
Category: Standards Track                                     ETH Zurich
Expires: May 24, 2013                                  November 20, 2012


   Specification of the IP Flow Information eXport (IPFIX) Protocol
[ snip ]
6.1.9  dateTimeMicroseconds

   The data type dateTimeMicroseconds is a 64-bit field encoded
   according to the NTP Timestamp format as defined in section 6 of
   [RFC5905]. This field is made up of two unsigned 32-bit integers in
   network byte order, Seconds and Fraction. The Seconds field is the
   number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
   The Fraction field is the fractional number of seconds in units of
   1/(2^32) seconds (approximately 233 picoseconds). It can represent
   dates beginning between 1 January 1900 and 8 February 2036.

Since we're already over 80% through that range, it seems worth moving the epoch to 1/1/2000.


I don't disagree that this would have made sense, but can we reasonably make this change in 5101bis?  Will this make a 5101 collector incorrectly interpret 5101bis?  Maybe I am missing something.

-Andrew
--------------050401080604080803090802-- From paitken@cisco.com Mon Dec 10 09:08:29 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 4685121F84E0 for ; Mon, 10 Dec 2012 09:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 fVSRYrzPH+k0 for ; Mon, 10 Dec 2012 09:08:28 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A49A21F84E4 for ; Mon, 10 Dec 2012 09:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1147; q=dns/txt; s=iport; t=1355159309; x=1356368909; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BR9VojF0UhZCHs15sy/jQbf0e0cH7ImeEUAkATPxX4Y=; b=RBp/AEIOINqWfNnhSm26hg04i3tu59oU5qkha+oXt23u2jLrTf6Y1cV9 JZOUNCIHH7gILKr3HrKxV/3iorEj48T28pg1nemTyP6oVN2DBYzQq30ZA gDFcIFFj8inzlp0kUWrqj6hHTeaDyova6cek8QquSV7Dw4J6QuqqWGsNw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0HADMWxlCQ/khN/2dsb2JhbABEg0i7OBZzgh4BAQEDAThAARALIRYPCQMCAQIBRQYNAQcBAYgHBrc5kQIDklODM4Vril2Ccw X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="148059674" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2012 17:08:28 +0000 Received: from [10.55.84.15] (dhcp-10-55-84-15.cisco.com [10.55.84.15]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBAH8R5a029041; Mon, 10 Dec 2012 17:08:27 GMT Message-ID: <50C6170C.1090900@cisco.com> Date: Mon, 10 Dec 2012 17:08:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Feren References: <50C5F8CC.5070609@cisco.com> <50C615FA.5040403@plixer.com> In-Reply-To: <50C615FA.5040403@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-protocol-rfc5101bis-03 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, 10 Dec 2012 17:08:29 -0000 Andrew, >>> 6.1.9 dateTimeMicroseconds >>> >>> The data type dateTimeMicroseconds is a 64-bit field encoded >>> according to the NTP Timestamp format as defined in section 6 of >>> [RFC5905]. This field is made up of two unsigned 32-bit integers in >>> network byte order, Seconds and Fraction. The Seconds field is the >>> number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. >>> The Fraction field is the fractional number of seconds in units of >>> 1/(2^32) seconds (approximately 233 picoseconds). It can represent >>> dates beginning between 1 January 1900 and 8 February 2036. >> >> Since we're already over 80% through that range, it seems worth >> moving the epoch to 1/1/2000. >> > > I don't disagree that this would have made sense, but can we > reasonably make this change in 5101bis? Will this make a 5101 > collector incorrectly interpret 5101bis? Maybe I am missing something. Correct; this is a point for discussion rather than a realistic proposal. Also, I'm glad to see you read this far through ;-) Let's save this change for v11 export :-) P. From muenz@net.in.tum.de Mon Dec 10 13:57: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 4574321F862D for ; Mon, 10 Dec 2012 13:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 a5-EFFAzV8zG for ; Mon, 10 Dec 2012 13:57:34 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F221F851E for ; Mon, 10 Dec 2012 13:57:34 -0800 (PST) Received: from [192.168.2.36] (g230147129.adsl.alicedsl.de [92.230.147.129]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7410219B1280 for ; Mon, 10 Dec 2012 22:57:32 +0100 (CET) Message-ID: <50C65ACC.20505@net.in.tum.de> Date: Mon, 10 Dec 2012 22:57:32 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPFIX Working Group References: <50AEF1D1.9010809@auckland.ac.nz> In-Reply-To: <50AEF1D1.9010809@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.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: Mon, 10 Dec 2012 21:57:35 -0000 Dear all, I had a look at the differences between RFC5101 and the RFC5101bis draft (not at the unchanged parts). The changes in RFC5101bis make things much clearer. As we see in Paul's review, there are many more smaller issues that need to be improved and those parts of the RFC which have not yet been touched. All in all, I agree with Paul's comments and with the comments made by the other reviewers. Here are some additional comments: There are occurrences of "template ID" and "template", but I think it should be "Template ID" and "Template" all over the place. I suggest that you check the writing of all the other IPFIX terms as well. In 4.1 and 4.2, it is unclear whether meteringProcessId is a mandatory or optional scope field. If it is mandatory (I don't think that it should be!), the "Note..." paragraphs below are superfluous. If it is optional as in RFC5101, please denote it in the description of the Template fields. In 8.1, look for "allow receipt and processing of and Data Records" and correct it (and -> any). Still in 8.1, I do not think that this paragraph applies to UDP where we now also allow TWM (as far as I understand): "If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, without having received a withdrawal, it MUST ignore the new Template Record and discard the old Template Record for the allocated ID; it SHOULD log the error." Last paragraph in 8.4: "...the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: ." The UDP Transport Session is defined by a four-tuple. Collector IP address and port are missing in the list. Nevertheless, a Collecting Process can easily listen on an interface which is assigned multiple IP addresses. So, at least Collector IP address must be included. In 10.3.2, "Exporting Processes exporting IPFIX Messages via UDP MUST include a valid UDP checksum." does not make sense. The IPFIX Messages does not have a UDP checksum field. It's the underlying UDP datagram. I also suggest to add a reference to the RFC where the UDP checksum usage is explained. In 9.2, I would prefer MAY over SHOULD in "If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received." BTW, SHOULD contradicts the MAY used earlier in 8. Also, it must be mentioned that at late arrival of the Template, the Export Time must be compared to the one of the earlier received Data Records. Thanks, Gerhard On 23.11.2012 04:47, Nevil Brownlee wrote: > > Hi all: > > Following up on Brian's email dated 20 November ... > > The WG Last Call for this I-D starts now, and will run until Monday, > 10 December. > > Do please read the draft, and post your comments to the list. It's > important that we can show it has been well-considered/reviewed within > the WG, so short comments like "yes, this does clearly describe the > IPFIX Information Model as we want it to be" are important and useful! > > Cheers, Nevil > From n.brownlee@auckland.ac.nz Mon Dec 10 18:54:13 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 F3F8F21F86D5 for ; Mon, 10 Dec 2012 18:54:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reOvmeK7X8-s for ; Mon, 10 Dec 2012 18:54:11 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC4221F86D2 for ; Mon, 10 Dec 2012 18:54:09 -0800 (PST) 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=1355194451; x=1386730451; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Hse3xXFVjE+hFXELj3QUgi9Fs5mbWqKFRFY7BfNOjLk=; b=hTJtkVq06C2/FwBQZGlDRDGAqLR8jUsW4pIoN7/rYNqGFw1cIWMeaHLv EtqPHkFoFlb/2joyPkwyRWXW53xcaID0Sqbw2D1OMRhFtzEwJW+Q8VTft rlJq4uXhrXPyEnm0+Tz/xJALnews223qQdtfXd1iLA+Wsa3xmMJEcrup6 w=; X-IronPort-AV: E=Sophos;i="4.84,256,1355050800"; d="scan'208";a="161466828" 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; 11 Dec 2012 15:54:08 +1300 Message-ID: <50C6A04F.6000106@auckland.ac.nz> Date: Tue, 11 Dec 2012 15:54:07 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <662DB88B-EAB3-4980-BED3-59AB29552DA3@tik.ee.ethz.ch> In-Reply-To: <662DB88B-EAB3-4980-BED3-59AB29552DA3@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] I-D Action: draft-ietf-ipfix-ie-doctors-07.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: Tue, 11 Dec 2012 02:54:13 -0000 Hi Brian: Since we agree that your proposed change is purely editorial, making the change at AUTH48 is the right way to do it. Benoit, I think these things need AD approval, is that right? Cheers, Nevil On 4/12/12 10:44 PM, Brian Trammell wrote: > Hi, Andrew, > > I recall this thread, but had completely missed the resolution to it; apologies, and thanks for bringing it back up. > > Rereading the descriptions and the approved revision of ie-doctors, there are two problems with the draft text: > > (1) the assumed semantics are incorrect; and > > (2) initiatorOctets doesn't actually duplicate octetTotalCount (since it counts from the end of the L4 payload as opposed to the beginning of the L3 header). > > The following problems still exist with these IEs: > > (3) initiatorPackets still appears to duplicate packetTotalCount, unless... > > (3a) the definition of initiatorPackets is interpreted in a certain way. As it is, it's still ambiguous to the point of not being implementable: "The total number of layer 4 packets in a flow from the initiator"... What is a "layer 4 packet"? Is this a packet containing payload beyond the layer 4 header? containing content that will be delivered to the application (which may be different, depending on which layer 4)? a packet containing a layer 4 header known to the MP? > > (4) responder{Octets/Packets} still duplicate the RFC 5103 reversed versions of initiatorOctets and initiatorPackets using "initiator" biflowDirection, which goes against the general rule to reuse IEs when necessary. > > From a process standpoint, I'm not sure what the right thing to do is, as IE-DOCTORS is now in the RFC-EDITOR queue. I believe the point made by this paragraph (the second in section 4.9) to be a necessary one, but the examples given are clearly in error. The meaning of the text is conveyed by the first sentence, which does not require update; the example is non-normative. I believe that the problem is therefore editorial, and would propose an RFC-EDITOR note like the following during AUTH48: > > OLD: > > Before registering a new Information Element, it must be determined > that it would be sufficiently unique within the IANA IE registry. > This evaluation has not always been done in the past, and the > existence of the Information Elements defined without this evaluation > should not be taken as an example that such Information Element > definition practices should be followed in the future. Specific > examples of such Information Elements include initiatorOctets and > responderOctets (which duplicate octetDeltaCount and its reverse per > [RFC5103]) and initiatorPackets and responderPackets (the same, for > packetDeltaCount). > > NEW: > > Before registering a new Information Element, it must be determined > that it would be sufficiently unique within the IANA IE registry. > This evaluation has not always been done in the past, and the > existence of the Information Elements defined without this evaluation > should not be taken as an example that such Information Element > definition practices should be followed in the future. Specific > examples of such Information Elements include initiatorPackets and > responderPackets (which appear to duplicate packetTotalCount and > its reverse per [RFC5103]). > > However, I'd like a ruling from our Friendly Area Directors as to whether this an acceptable resolution at this stage. > > Separate from this, issue (3a) above concerning the ambiguity of initiatorPackets and responderPackets should be handled with a revision to the Information Element definitions. > > Cheers, > > Brian > > On 4 Dec 2012, at 5:18, Andrew Feren wrote: > >> Hi Brian, >> >> I haven't reread this entire draft, but happened to notice that this >> version still has >> >> "Specific >> examples of such Information Elements include initiatorOctets and >> responderOctets (which duplicate octetDeltaCount and its reverse per >> [RFC5103 ]) and initiatorPackets >> and responderPackets (the same, for >> packetDeltaCount)." >> >> >> Which is not correct >> >> Earlier discussion at >> >> http://www.ietf.org/mail-archive/web/ipfix/current/msg06451.html >> >> http://www.ietf.org/mail-archive/web/ipfix/current/msg06456.html >> >> >> -Andrew >> >> On 10/3/12 10:47 AM, "internet-drafts@ietf.org" >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IP Flow Information Export Working >>> Group of the IETF. >>> >>> Title : Guidelines for Authors and Reviewers of IPFIX >>> Information Elements >>> Author(s) : Brian Trammell >>> Benoit Claise >>> Filename : draft-ietf-ipfix-ie-doctors-07.txt >>> Pages : 33 >>> Date : 2012-10-03 >>> >>> Abstract: >>> This document provides guidelines for how to write definitions of new >>> Information Elements for the IP Flow Information Export (IPFIX) >>> protocol. It provides instructions on using the proper conventions >>> for Information Elements to be registered in the IANA IPFIX >>> Information Element registry, and provides guidelines for expert >>> reviewers to evaluate new registrations. >>> >>> >>> 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-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-ie-doctors-07 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 Tue Dec 11 05:40:29 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 B780121F8532 for ; Tue, 11 Dec 2012 05:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaYmjsEQ6ihS for ; Tue, 11 Dec 2012 05:40:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1FA21F845E for ; Tue, 11 Dec 2012 05:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D58C6D9310 for ; Tue, 11 Dec 2012 14:40:23 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mKf66a9MVYsW for ; Tue, 11 Dec 2012 14:40:23 +0100 (MET) Received: from [172.16.0.154] (ec2-79-125-80-212.eu-west-1.compute.amazonaws.com [79.125.80.212]) (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 5DC98D930A for ; Tue, 11 Dec 2012 14:40:21 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 11 Dec 2012 14:40:12 +0100 To: IETF IPFIX Working Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPFIX] RFC5101bis revision 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, 11 Dec 2012 13:40:29 -0000 Greetings, all, Thanks to all for the comments on 5101bis; I'll be pulling these = together and putting out a -04 revision, hopefully early next week, = including all of the indicated edits for which discussion doesn't appear = necessary, or for which text needs to be generated for further = discussion. Given that there's at least one discussion that will lead to a semantic = change in 5101bis -- namely, handling wraparound and eras explicitly in = the timestamp data types -- I presume the resulting revision will = require another WGLC. Thanks again, best regards, Brian= From Quittek@neclab.eu Thu Dec 13 03:29: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 B6DC221F8951 for ; Thu, 13 Dec 2012 03:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dJ4N42J-PZmG for ; Thu, 13 Dec 2012 03:29:00 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25721F88B6 for ; Thu, 13 Dec 2012 03:29:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 73D44102A1B; Thu, 13 Dec 2012 12:28:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrn99J0ExL+5; Thu, 13 Dec 2012 12:28:59 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 59742102A1A; Thu, 13 Dec 2012 12:28:49 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.222]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 13 Dec 2012 12:28:49 +0100 From: Juergen Quittek To: Brian Trammell , IETF IPFIX Working Group Thread-Topic: [IPFIX] RFC5101bis revision Thread-Index: AQHN2STlrbKdFWvdDESoVMnMlTCPhg== Date: Thu, 13 Dec 2012 11:27:56 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <421B4CBDAD96764CABBDF06C37BF3F09@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] RFC5101bis revision 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, 13 Dec 2012 11:29:00 -0000 Hi Brian, Let's see the changes first. If it is just this one semantical change, we can also ask explicitly for agreement on this update on the mailing list. Thanks, Juergen On 11.12.12 14:40, "Brian Trammell" wrote: >Greetings, all, > >Thanks to all for the comments on 5101bis; I'll be pulling these together >and putting out a -04 revision, hopefully early next week, including all >of the indicated edits for which discussion doesn't appear necessary, or >for which text needs to be generated for further discussion. > >Given that there's at least one discussion that will lead to a semantic >change in 5101bis -- namely, handling wraparound and eras explicitly in >the timestamp data types -- I presume the resulting revision will require >another WGLC. > >Thanks again, best regards, > >Brian >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Thu Dec 13 03:32:32 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 1A1FC21F8A8C for ; Thu, 13 Dec 2012 03:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8jORd7efbJx for ; Thu, 13 Dec 2012 03:32:31 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 212F021F8980 for ; Thu, 13 Dec 2012 03:32:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 451FBD9323; Thu, 13 Dec 2012 12:32:30 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zU0ldt7PQwaa; Thu, 13 Dec 2012 12:32:30 +0100 (MET) Received: from [172.16.0.154] (ec2-79-125-80-212.eu-west-1.compute.amazonaws.com [79.125.80.212]) (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 20892D9310; Thu, 13 Dec 2012 12:32:17 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Thu, 13 Dec 2012 12:32:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72032D6D-34CD-4CC6-B57B-84806601790A@tik.ee.ethz.ch> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC5101bis revision 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, 13 Dec 2012 11:32:32 -0000 hi Juergen, Okay, even better. Again, I haven't had a chance to do a full review of = the reviews yet; I'll post on this next week. Thanks, cheers, Brian On 13 Dec 2012, at 12:27, Juergen Quittek wrote: > Hi Brian, >=20 > Let's see the changes first. If it is just this one semantical = change, we > can also ask explicitly for agreement on this update on the mailing = list. >=20 > Thanks, > Juergen >=20 >=20 > On 11.12.12 14:40, "Brian Trammell" wrote: >=20 >> Greetings, all, >>=20 >> Thanks to all for the comments on 5101bis; I'll be pulling these = together >> and putting out a -04 revision, hopefully early next week, including = all >> of the indicated edits for which discussion doesn't appear necessary, = or >> for which text needs to be generated for further discussion. >>=20 >> Given that there's at least one discussion that will lead to a = semantic >> change in 5101bis -- namely, handling wraparound and eras explicitly = in >> the timestamp data types -- I presume the resulting revision will = require >> another WGLC. >>=20 >> Thanks again, best regards, >>=20 >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Fri Dec 14 02:54: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 7BCE121F86AA for ; Fri, 14 Dec 2012 02:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCeVEic7t91q for ; Fri, 14 Dec 2012 02:54:45 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD121F86B2 for ; Fri, 14 Dec 2012 02:54:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BDF53D930D for ; Fri, 14 Dec 2012 11:54:40 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YHA8eOkCuckf for ; Fri, 14 Dec 2012 11:54:40 +0100 (MET) 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 81084D930C for ; Fri, 14 Dec 2012 11:54:40 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Dec 2012 11:54:40 +0100 Message-Id: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> To: IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] On Encodings in RFC5102bis 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, 14 Dec 2012 10:54:46 -0000 Greetings, all, In reviewing WGLC comments on 5101bis, specifically with respect to = timestamp wraparound (on which I'm still working on a response), I had a = look at RFC5102bis to see if the text there would be compatible with = such a thing. The sections describing the POSIX-based abstract data = types which include, unlike the others, encoding details; I would = suggest removing the encoding details, leaving them for RFC5101bis (and = alternate encodings, as in draft-trammell-ipfix-text-adt), to be = consistent with the rest of RFC5102bis. OLD: 3.1.15. dateTimeSeconds The data type dateTimeSeconds is an unsigned 32-bit integer representing the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 3.1.16. dateTimeMilliseconds The data type dateTimeMilliseconds is an unsigned 64-bit integer containing the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. NEW: 3.1.15. dateTimeSeconds The data type dateTimeSeconds represents the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 3.1.16. dateTimeMilliseconds The data type dateTimeMilliseconds represents the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. (The reference to [POSIX.1] remains necessary to clarify leap second = issues; i.e., this value is can be directly derived from the system = clock on a UNIX-like machine). While reviewing this, I noticed that there's one other encoding-specific = as opposed to data-specific ADT: macAddress. I'd suggest the following = change as well: OLD: 3.1.12. macAddress The type "macAddress" represents a string of 6 octets. NEW: 3.1.12. macAddress The type "macAddress" represents a MAC-48 address. I'd specify MAC-48 as opposed to EUI-48, because it's not clear that = require global uniqueness. On this point, does anyone know of the = correct reference to use here? I've been looking at various 802 = cross-references in RFCs but can't find anything that fits yet... Comments? Even a "looks good" would be helpful. I'd like to make this = last change soon, so an -08 revision can be written up and sent up to = the IESG. Thanks, cheers, Brian= From paitken@cisco.com Fri Dec 14 03:39: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 C625C21F8569 for ; Fri, 14 Dec 2012 03:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 m5YiwDcpUYr4 for ; Fri, 14 Dec 2012 03:39:28 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2821F8566 for ; Fri, 14 Dec 2012 03:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3137; q=dns/txt; s=iport; t=1355485167; x=1356694767; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NDRcbIh9Q9haLr0NUig5vU25YpEApQGhn6cNFmzbQd0=; b=drbBAZaQFISZLiZKpVLiTNQkv2sgLk50L53REWhYyweuZ4immvKJeV4N uIV4I9S++hjAJjG7V8LgBaJLNnnztVWgznDsLBze48Kd46hmJ6NANddJw l0VAMnhzluDA5gd1ebQfKzVTSqUkhameuW7W9NyFBNGacFnvUEO/UThFK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIHABEPy1CQ/khN/2dsb2JhbABFgy8ZuzsWc4IeAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIDwy9VwSRGgOWCYVril2Ccw X-IronPort-AV: E=Sophos;i="4.84,280,1355097600"; d="scan'208";a="79105781" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Dec 2012 11:39:24 +0000 Received: from [10.55.84.244] (dhcp-10-55-84-244.cisco.com [10.55.84.244]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBEBdMj8009537; Fri, 14 Dec 2012 11:39:23 GMT Message-ID: <50CB0FEB.4030704@cisco.com> Date: Fri, 14 Dec 2012 11:39:23 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> In-Reply-To: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 14 Dec 2012 11:39:28 -0000 Brian, This seems good to me. MAC-48 seems correct. I don't have a good reference; IANA's IPFIX registry cites "IEEE.802-3.2002"; googling this just produces lots of IPFIX hits :-) BTW: 1. I've just asked IANA to convert links in the IPFIX registry from plain text into active links. 2. It'd be handy if we had active links to all the IEEE docs xref'd in the registry. However, some of them seem to be superseded or expired and no longer available to download. P. On 14/12/12 10:54, Brian Trammell wrote: > Greetings, all, > > In reviewing WGLC comments on 5101bis, specifically with respect to timestamp wraparound (on which I'm still working on a response), I had a look at RFC5102bis to see if the text there would be compatible with such a thing. The sections describing the POSIX-based abstract data types which include, unlike the others, encoding details; I would suggest removing the encoding details, leaving them for RFC5101bis (and alternate encodings, as in draft-trammell-ipfix-text-adt), to be consistent with the rest of RFC5102bis. > > > OLD: > > 3.1.15. dateTimeSeconds > > The data type dateTimeSeconds is an unsigned 32-bit integer > representing the number of seconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > 3.1.16. dateTimeMilliseconds > > The data type dateTimeMilliseconds is an unsigned 64-bit integer > containing the number of milliseconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > > NEW: > > 3.1.15. dateTimeSeconds > > The data type dateTimeSeconds represents > the number of seconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > 3.1.16. dateTimeMilliseconds > > The data type dateTimeMilliseconds represents > the number of milliseconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > > (The reference to [POSIX.1] remains necessary to clarify leap second issues; i.e., this value is can be directly derived from the system clock on a UNIX-like machine). > > > While reviewing this, I noticed that there's one other encoding-specific as opposed to data-specific ADT: macAddress. I'd suggest the following change as well: > > > OLD: > > 3.1.12. macAddress > > The type "macAddress" represents a string of 6 octets. > > > NEW: > > 3.1.12. macAddress > > The type "macAddress" represents a MAC-48 address. > > > I'd specify MAC-48 as opposed to EUI-48, because it's not clear that require global uniqueness. On this point, does anyone know of the correct reference to use here? I've been looking at various 802 cross-references in RFCs but can't find anything that fits yet... > > Comments? Even a "looks good" would be helpful. I'd like to make this last change soon, so an -08 revision can be written up and sent up to the IESG. > > Thanks, cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Fri Dec 14 04:26:13 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 0900521F85C6 for ; Fri, 14 Dec 2012 04:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qEhRhcOzvs8 for ; Fri, 14 Dec 2012 04:26:12 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0821F85C8 for ; Fri, 14 Dec 2012 04:26:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0AB9DD9321; Fri, 14 Dec 2012 13:26:11 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ztMMe8mCvR+r; Fri, 14 Dec 2012 13:26:10 +0100 (MET) 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 C73B4D930D; Fri, 14 Dec 2012 13:26:10 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <50C6170C.1090900@cisco.com> Date: Fri, 14 Dec 2012 13:26:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C5F8CC.5070609@cisco.com> <50C615FA.5040403@plixer.com> <50C6170C.1090900@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1283) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-protocol-rfc5101bis-03 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, 14 Dec 2012 12:26:13 -0000 hi, Paul, Andrew, If we're going to reference NTP export, we should use the NTP epoch; = otherwise, we're basically just begging for interoperability problems. I think at some point we'll need to split representation from epoch. The = current proposal to allow implicit wraparound begins to address that (it = keeps epoch mod wrapround, basically).=20 Cheers, Brian On 10 Dec 2012, at 18:08 , Paul Aitken wrote: > Andrew, >=20 >>>> 6.1.9 dateTimeMicroseconds >>>>=20 >>>> The data type dateTimeMicroseconds is a 64-bit field encoded >>>> according to the NTP Timestamp format as defined in section 6 of >>>> [RFC5905]. This field is made up of two unsigned 32-bit integers = in >>>> network byte order, Seconds and Fraction. The Seconds field is = the >>>> number of seconds since the NTP epoch, 1 January 1900 at 00:00 = UTC. >>>> The Fraction field is the fractional number of seconds in units = of >>>> 1/(2^32) seconds (approximately 233 picoseconds). It can = represent >>>> dates beginning between 1 January 1900 and 8 February 2036. >>>=20 >>> Since we're already over 80% through that range, it seems worth = moving the epoch to 1/1/2000. >>>=20 >>=20 >> I don't disagree that this would have made sense, but can we = reasonably make this change in 5101bis? Will this make a 5101 collector = incorrectly interpret 5101bis? Maybe I am missing something. >=20 > Correct; this is a point for discussion rather than a realistic = proposal. Also, I'm glad to see you read this far through ;-) >=20 > Let's save this change for v11 export :-) >=20 > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Fri Dec 14 06:44: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 1C1FC21F857B for ; Fri, 14 Dec 2012 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] 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 ury-7--CF0nm for ; Fri, 14 Dec 2012 06:44:50 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 07CAA21F85A0 for ; Fri, 14 Dec 2012 06:44:49 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Dec 2012 09:44:48 -0500 Message-ID: <50CB3B60.8000709@plixer.com> Date: Fri, 14 Dec 2012 09:44:48 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> In-Reply-To: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2012 14:44:48.0678 (UTC) FILETIME=[910DE460:01CDDA09] Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 14 Dec 2012 14:44:51 -0000 Hi Brian, That all looks good. -Andrew On 12/14/2012 05:54 AM, Brian Trammell wrote: > Greetings, all, > > In reviewing WGLC comments on 5101bis, specifically with respect to timestamp wraparound (on which I'm still working on a response), I had a look at RFC5102bis to see if the text there would be compatible with such a thing. The sections describing the POSIX-based abstract data types which include, unlike the others, encoding details; I would suggest removing the encoding details, leaving them for RFC5101bis (and alternate encodings, as in draft-trammell-ipfix-text-adt), to be consistent with the rest of RFC5102bis. > > > OLD: > > 3.1.15. dateTimeSeconds > > The data type dateTimeSeconds is an unsigned 32-bit integer > representing the number of seconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > 3.1.16. dateTimeMilliseconds > > The data type dateTimeMilliseconds is an unsigned 64-bit integer > containing the number of milliseconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > > NEW: > > 3.1.15. dateTimeSeconds > > The data type dateTimeSeconds represents > the number of seconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > 3.1.16. dateTimeMilliseconds > > The data type dateTimeMilliseconds represents > the number of milliseconds since the UNIX epoch, 1 January > 1970 at 00:00 UTC, as defined in [POSIX.1]. > > > (The reference to [POSIX.1] remains necessary to clarify leap second issues; i.e., this value is can be directly derived from the system clock on a UNIX-like machine). > > > While reviewing this, I noticed that there's one other encoding-specific as opposed to data-specific ADT: macAddress. I'd suggest the following change as well: > > > OLD: > > 3.1.12. macAddress > > The type "macAddress" represents a string of 6 octets. > > > NEW: > > 3.1.12. macAddress > > The type "macAddress" represents a MAC-48 address. > > > I'd specify MAC-48 as opposed to EUI-48, because it's not clear that require global uniqueness. On this point, does anyone know of the correct reference to use here? I've been looking at various 802 cross-references in RFCs but can't find anything that fits yet... > > Comments? Even a "looks good" would be helpful. I'd like to make this last change soon, so an -08 revision can be written up and sent up to the IESG. > > Thanks, cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Dec 14 07:20:05 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 022EB21F8803; Fri, 14 Dec 2012 07:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 lwyguDfWOMmQ; Fri, 14 Dec 2012 07:20:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9381121F87F2; Fri, 14 Dec 2012 07:20:04 -0800 (PST) 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.36 Message-ID: <20121214152004.19591.78646.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 07:20:04 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-08.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, 14 Dec 2012 15:20:05 -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-08.txt Pages : 22 Date : 2012-12-14 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Dec 14 07:36: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 73A1D21F87FE for ; Fri, 14 Dec 2012 07:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVKMOiC-GcTo for ; Fri, 14 Dec 2012 07:36:50 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF0C21F87D2 for ; Fri, 14 Dec 2012 07:36:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A423ED9308 for ; Fri, 14 Dec 2012 16:36:44 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hjF21Xc-rESk for ; Fri, 14 Dec 2012 16:36:44 +0100 (MET) 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 77AB2D9305 for ; Fri, 14 Dec 2012 16:36:44 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Dec 2012 16:36:44 +0100 References: <20121214152004.19591.78646.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <7FABDDCA-C610-498E-A0BD-D2794CF9D602@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-08.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, 14 Dec 2012 15:36:51 -0000 Greetings, all, This revision removes encoding restrictions from the dateTimeSeconds, = dateTimeMilliseconds, and macAddress abstract data types, as briefly = discussed this morning, and adds a reference to 802.3 for MAC addresses. I believe this revision to be ready for post-WGLC writeup. Cheers, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-information-model-rfc5102bis-08.txt > Date: 14 December 2012 16:20:04 GMT+01:00 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Information Model for IP Flow Information = eXport (IPFIX) > Author(s) : Benoit Claise > Brian Trammell > Filename : = draft-ietf-ipfix-information-model-rfc5102bis-08.txt > Pages : 22 > Date : 2012-12-14 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 8 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrjohn@cisco.com Mon Dec 17 03:04:11 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 DD1F321F8A9D for ; Mon, 17 Dec 2012 03:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seX-rPrmWcyV for ; Mon, 17 Dec 2012 03:04:11 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C6BF821F8AA5 for ; Mon, 17 Dec 2012 03:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3136; q=dns/txt; s=iport; t=1355742251; x=1356951851; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=gBWfKkWofecee9M5TSxtOU8fxRMhmT3KEgKF71qF2j8=; b=Hh6W3TxT18beYsPD7ukSBm990t9mh382z4GNQ6qLBpnaStdOmpxGoAHu /zVsFLFUz4juc1+h7+TilxPXZHuwx+UoB5hWy6ASxJ4wmfOWoBXIz2X5i Sy1nQ925qUsY8CWrFr1qQpt1/kdkuOUse4vhR0T98c79b4a7Hoi6WZenz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAHACr7zlCQ/khM/2dsb2JhbABFg0i6ahZzgh4BAQEDAQEBATc0EAsLGC4nMBmIDQYMuVgEjF2BGoJIYQOWCpBIgnM X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208";a="148446515" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2012 11:04:09 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBHB49bT001588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Dec 2012 11:04:09 GMT Received: from ams-andrjohn-8715.cisco.com (ams-andrjohn-8715.cisco.com [10.55.163.38]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBHB48hJ011896 for ; Mon, 17 Dec 2012 11:04:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew Johnson In-Reply-To: <50CB3B60.8000709@plixer.com> Date: Mon, 17 Dec 2012 11:04:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4A425737-82E8-413B-A307-AB108AB3EF72@cisco.com> References: <65CB9985-77E3-4179-A81A-741AFF45E387@tik.ee.ethz.ch> <50CB3B60.8000709@plixer.com> To: ipfix@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 17 Dec 2012 11:04:12 -0000 +1 Andrew On 14 Dec 2012, at 14:44, Andrew Feren wrote: > Hi Brian, >=20 > That all looks good. >=20 > -Andrew >=20 > On 12/14/2012 05:54 AM, Brian Trammell wrote: >> Greetings, all, >>=20 >> In reviewing WGLC comments on 5101bis, specifically with respect to = timestamp wraparound (on which I'm still working on a response), I had a = look at RFC5102bis to see if the text there would be compatible with = such a thing. The sections describing the POSIX-based abstract data = types which include, unlike the others, encoding details; I would = suggest removing the encoding details, leaving them for RFC5101bis (and = alternate encodings, as in draft-trammell-ipfix-text-adt), to be = consistent with the rest of RFC5102bis. >>=20 >>=20 >> OLD: >>=20 >> 3.1.15. dateTimeSeconds >>=20 >> The data type dateTimeSeconds is an unsigned 32-bit integer >> representing the number of seconds since the UNIX epoch, 1 January >> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>=20 >> 3.1.16. dateTimeMilliseconds >>=20 >> The data type dateTimeMilliseconds is an unsigned 64-bit integer >> containing the number of milliseconds since the UNIX epoch, 1 = January >> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>=20 >>=20 >> NEW: >>=20 >> 3.1.15. dateTimeSeconds >>=20 >> The data type dateTimeSeconds represents >> the number of seconds since the UNIX epoch, 1 January >> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>=20 >> 3.1.16. dateTimeMilliseconds >>=20 >> The data type dateTimeMilliseconds represents >> the number of milliseconds since the UNIX epoch, 1 January >> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>=20 >>=20 >> (The reference to [POSIX.1] remains necessary to clarify leap second = issues; i.e., this value is can be directly derived from the system = clock on a UNIX-like machine). >>=20 >>=20 >> While reviewing this, I noticed that there's one other = encoding-specific as opposed to data-specific ADT: macAddress. I'd = suggest the following change as well: >>=20 >>=20 >> OLD: >>=20 >> 3.1.12. macAddress >>=20 >> The type "macAddress" represents a string of 6 octets. >>=20 >>=20 >> NEW: >>=20 >> 3.1.12. macAddress >>=20 >> The type "macAddress" represents a MAC-48 address. >>=20 >>=20 >> I'd specify MAC-48 as opposed to EUI-48, because it's not clear that = require global uniqueness. On this point, does anyone know of the = correct reference to use here? I've been looking at various 802 = cross-references in RFCs but can't find anything that fits yet... >>=20 >> Comments? Even a "looks good" would be helpful. I'd like to make this = last change soon, so an -08 revision can be written up and sent up to = the IESG. >>=20 >> Thanks, cheers, >>=20 >> Brian >> _______________________________________________ >> 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 From pthaler@broadcom.com Tue Dec 18 19:26:34 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 ECFDA21E803F for ; Tue, 18 Dec 2012 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.641 X-Spam-Level: X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fJ8awcOlYfYZ for ; Tue, 18 Dec 2012 19:26:32 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1221E8034 for ; Tue, 18 Dec 2012 19:26:32 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 18 Dec 2012 19:24:25 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 18 Dec 2012 19:26:19 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 18 Dec 2012 19:25:58 -0800 From: "Pat Thaler" To: "ipfix@ietf.org" Thread-Topic: Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-01 Thread-Index: Ac3dhyWaIaNIo93GS1S2OJuRFWtt1AAEWUCQ Date: Wed, 19 Dec 2012 03:25:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CCFECE31ZK900031-01-01 Content-Type: multipart/alternative; boundary=_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1DB78SJEXCHMB09corpa_ Subject: Re: [IPFIX] Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-01 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, 19 Dec 2012 03:26:35 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1DB78SJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable There are a number of items that should be corrected in this draft. * The draft is out of date with respect to status of 802.1 and 802.= 3 standards. Please replace with current references. o The amendments IEEE 802.1ad and 802.1ah are not active standards as the= material from them was incorporated into IEEE 802.1Q revisions. References= to them should be changed to the current revision of 802.1Q o The current revision of 802.1Q is IEEE Std 802.1Q-2011. o The current revision of 802.3 is IEEE Std 802.3-2012 (which has been ap= proved and should be published shortly). It doesn't have a subclause 3.5. T= his was removed in the 2008 revision of 802.3 as the subclause just duplica= ted information from 802.1Q. 802.1Q should be used as the reference for fie= lds such as VLAN ID and priority code point. o 802.1BR only specifies Bridge Port Extension so only Figure B-4 shows a= frame format specified in 802.1BR o 802.1Qbg Edge Virtual Bridging specifies use of an S-Tag to identify tr= affic belonging to S-Channels (i.e. a virtual link) on a physical link betw= een an end station and the adjacent bridge so the formats in Figure B-1 and= B-2 would apply to 802.1Qbg, not 802.1BR. * The frame formats for Edge Virtual Bridging and Port Extension ap= ply only between the end node and adjacent bridge (for figures B-1 and B-2)= or within an Extended Bridge (i.e. a controlling bridge plus its port exte= nders, figure B-3). They are never used between bridges for those standard= s. The Edge Virtual Bridge frame formats use the same tags as Provider Bri= dged frame formats (Figure A-3 and A-4). When the frames with that format a= re used between bridges it is provider bridging which is used in some data = centers as well as in the WAN. It would be better to organize the frame for= mat annexes as frame formats used between bridges and frame formats used fo= r Edge Virtual Bridging between edge devices and their bridge and within an= Extended Bridge. * 2.2 Data Center Bridging - the content here seems confused. It is= n't clear what the relevance of this summary is to the draft since informat= ion elements for the IEEE 802.1BR E-Tag have not been added. The E-Tag only= appears between elements of an Extended Bridge and the Controlling Bridge = has visibility of all the traffic in the Extended Bridge so it isn't clear = to me that data link layer monitoring is relevant to it (any more than it w= ould be to monitoring traffic between blades in a blade bridge). The C-Tag = is used in Data Center Bridging the same way as in all 802.1Q bridging so t= hat isn't a special case. The use of the S-Tag for Edge Virtual Bridging S-= Channels only occurs on the link between an end station and its adjacent br= idge. No additional elements are needed for these. The conclusion that Data= Center Bridging complicates traffic measurement is not substantiated. Plea= se remove 2.2 or if it is retained make it more clear and accurate. * 2.3 Multiple Path Ethernet Summary - says "two solutions are disc= ussed for standardization" implying that the standards haven't been finishe= d. IEEE Std 802.1aq-2012 Shortest Path Bridging is an approved standard whi= ch was published in June. * 2.4 VXLAN - The limit of the 12-bit VLAN ID is not the motivating= factor for Network Virtualization Overlay (NVO3). If it was, the I-Tag whi= ch supports a 24-bit service identifier would suffice. A more significant m= otivator for the NVO3 is allowing for IP and MAC address isolation between = the data center (which may be a layer 3 data center) and the tenant network= s and between the tenant networks. The problem statement draft, draft-ietf-= nvo3-overlay-problem-statement-01, provides a more complete description of= the motivating factors. VXLAN is not the only proposed encapsulation for N= VO3. It seems early to mention this topic as we haven't decided on which so= lutions to standardize. No information elements have been added for it so 2= .4 could be deleted. If it remains, it should point to the NVO3 work in gen= eral rather than a specific proposal. * 5.1 and 5.2 - formally, there is no such thing as an 802.1ad fram= e or 802.1ah since 802.1ad and 802.1ah have been rolled into 802.1Q. You co= uld use S-Tagged and B-Tagged frame. Regards, Pat Thaler --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1DB78SJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

There are a number of items that should be corrected= in this draft.

 

·         The draft is out of date with respect to sta= tus of 802.1 and 802.3 standards. Please replace with current references.

o   The amendments IEEE 802.1ad and 802.1ah are = not active standards as the material from them was incorporated into IEEE 8= 02.1Q revisions. References to them should be changed to the current revisi= on of 802.1Q

o   The current revision of 802.1Q is IEEE Std 8= 02.1Q-2011.

o   The current revision of 802.3 is IEEE Std 80= 2.3-2012 (which has been approved and should be published shortly). It does= n’t have a subclause 3.5. This was removed in the 2008 revision of 80= 2.3 as the subclause just duplicated information from 802.1Q. 802.1Q should be used as the reference for fields such as VLA= N ID and priority code point.

o   802.1BR only specifies Bridge Port Extension= so only Figure B-4 shows a frame format specified in 802.1BR

o   802.1Qbg Edge Virtual Bridging specifies use= of an S-Tag to identify traffic belonging to S-Channels (i.e. a virtual li= nk) on a physical link between an end station and the adjacent bridge so th= e formats in Figure B-1 and B-2 would apply to 802.1Qbg, not 802.1BR.

·         The frame formats for Edge Virtual Bridging = and Port Extension apply only between the end node and adjacent bridge (for= figures B-1 and B-2) or within an Extended Bridge (i.e. a controlling brid= ge plus its port extenders, figure B-3).  They are never used between bridges for those standards. The &= nbsp;Edge Virtual Bridge frame formats use the same tags as Provider Bridge= d frame formats (Figure A-3 and A-4). When the frames with that format are = used between bridges it is provider bridging which is used in some data centers as well as in the WAN. It would be bett= er to organize the frame format annexes as frame formats used between bridg= es and frame formats used for Edge Virtual Bridging between edge devices an= d their bridge and within an Extended Bridge.

·         2.2 Data Center Bridging – the content= here seems confused. It isn’t clear what the relevance of this summa= ry is to the draft since information elements for the IEEE 802.1BR E-Tag ha= ve not been added. The E-Tag only appears between elements of an Extended Bridge and the Controlling Bridge has visibility o= f all the traffic in the Extended Bridge so it isn’t clear to me that= data link layer monitoring is relevant to it (any more than it would be to= monitoring traffic between blades in a blade bridge). The C-Tag is used in Data Center Bridging the same way as= in all 802.1Q bridging so that isn’t a special case. The use of the = S-Tag for Edge Virtual Bridging S-Channels only occurs on the link between = an end station and its adjacent bridge. No additional elements are needed for these. The conclusion that Data Cent= er Bridging complicates traffic measurement is not substantiated. Please re= move 2.2 or if it is retained make it more clear and accurate.

·         2.3 Multiple Path Ethernet Summary – s= ays “two solutions are discussed for standardization” implying = that the standards haven’t been finished. IEEE Std 802.1aq-2012 Short= est Path Bridging is an approved standard which was published in June.

·         2.4 VXLAN - The limit of the 12-bit VLAN ID = is not the motivating factor for Network Virtualization Overlay (NVO3). If = it was, the I-Tag which supports a 24-bit service identifier would suffice.= A more significant motivator for the NVO3 is allowing for IP and MAC address isolation between the data cen= ter (which may be a layer 3 data center) and the tenant networks and betwee= n the tenant networks. The problem statement draft, draft-ietf-nvo3-overlay-problem-statement-01, pr= ovides a more complete description of the motivating factors. VXLAN is not the only proposed encapsulation for NVO3. It seems early to m= ention this topic as we haven’t decided on which solutions to standar= dize. No information elements have been added for it so 2.4 could be delete= d. If it remains, it should point to the NVO3 work in general rather than a specific proposal.

·         5.1 and 5.2 – formally, there is no su= ch thing as an 802.1ad frame or 802.1ah since 802.1ad and 802.1ah have been= rolled into 802.1Q. You could use S-Tagged and B-Tagged frame.

 

Regards,

Pat Thaler

--_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1DB78SJEXCHMB09corpa_-- From internet-drafts@ietf.org Wed Dec 19 01:35: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 7F17C21F8781; Wed, 19 Dec 2012 01:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 fRKTvIuu4mQJ; Wed, 19 Dec 2012 01:35:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C175F21F8795; Wed, 19 Dec 2012 01:35:03 -0800 (PST) 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.37 Message-ID: <20121219093503.31303.29411.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 01:35:03 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Wed, 19 Dec 2012 09:35:04 -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 : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-04.txt Pages : 66 Date : 2012-12-19 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Wed Dec 19 01:48:49 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 9F1C221F8588 for ; Wed, 19 Dec 2012 01:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1B+p4DGlB9cw for ; Wed, 19 Dec 2012 01:48:48 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8421F8563 for ; Wed, 19 Dec 2012 01:48:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BDED9D9307 for ; Wed, 19 Dec 2012 10:48:47 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EtAvEIOE2CDL for ; Wed, 19 Dec 2012 10:48:47 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 70E8BD9304 for ; Wed, 19 Dec 2012 10:48:47 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Dec 2012 10:48:47 +0100 References: <20121219093503.31303.29411.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <8300ABE8-A995-4D03-B4F1-D973E4D2ADC8@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Wed, 19 Dec 2012 09:48:49 -0000 Greetings, all, Revision -04 of draft-ietf-ipfix-protocol-rfc5101bis addresses _most_ of = the comments received during WGLC; many thanks to all who commented, as = I think they've made the document much better. The language on template withdrawals has changed significantly. The = concept of a "template withdrawal message" has been largely removed from = the document, and the section has been made consistent with 8.2. 8.2 has = also changed quite a bit based on WGLC feedback. I don't think it's = possible to come up with a solution to all the various little corner = cases you can run into with template withdrawals that will make everyone = happy (trivial proof: I'm not happy with any of the possibilities I've = seen or could imagine), but I think what's in Section 8.1 is at least = internally self-consistent, so please have a look. Also completely new is Section 5.2 on timestamp wraparound, which = describes epoch wrap on 1900 and 1970 epoch timestamps in a way that's = consistent with what most people are probably already planning to do = anyway; given V5 and V9, I suspect there's a lot of well-tested = timestamp-wrapping corner-case code out there that can be easily = adapted. Please have a look at these and comment to the list; if only with a = "works for me". Chairs, please let us know if this new revision requires = a further WGLC.=20 Many thanks, and best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-protocol-rfc5101bis-04.txt > Date: December 19, 2012 10:35:03 AM GMT+01:00 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Specification of the IP Flow Information = eXport (IPFIX) Protocol for the Exchange of Flow Information > Author(s) : Benoit Claise > Brian Trammell > Filename : draft-ietf-ipfix-protocol-rfc5101bis-04.txt > Pages : 66 > Date : 2012-12-19 >=20 > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting Traffic Flow information over > the network. In order to transmit Traffic Flow information from an > Exporting Process to an information Collecting Process, a common > representation of flow data and a standard means of communicating > them is required. This document describes how the IPFIX Data and > Template Records are carried over a number of transport protocols > from an IPFIX Exporting Process to an IPFIX Collecting Process. = This > document obsoletes RFC 5101. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-04= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Quittek@neclab.eu Thu Dec 20 07:25: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 699B721F8202 for ; Thu, 20 Dec 2012 07:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 gcuKbJBP1Hvw for ; Thu, 20 Dec 2012 07:25:30 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5839021F898D for ; Thu, 20 Dec 2012 07:25:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B95FF102B20; Thu, 20 Dec 2012 16:25:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04x4sQICaI8x; Thu, 20 Dec 2012 16:25:29 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 9D763102B1F; Thu, 20 Dec 2012 16:25:19 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.64]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 16:24:03 +0100 From: Juergen Quittek To: Andrew Johnson , IETF IPFIX Working Group Thread-Topic: [IPFIX] On Encodings in RFC5102bis Thread-Index: AQHN3sYKDUlCF4OVhUC4qzcN5wVGHA== Date: Thu, 20 Dec 2012 15:24:02 +0000 Message-ID: In-Reply-To: <4A425737-82E8-413B-A307-AB108AB3EF72@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <31FC0A15A89C72439FD988FA42C79165@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 20 Dec 2012 15:25:31 -0000 Hi Brian and all, Does this mean we should delay the write-up until you have posted an updated version? Thanks, juergen On 17.12.12 12:04, "Andrew Johnson" wrote: >+1 > >Andrew > > >On 14 Dec 2012, at 14:44, Andrew Feren wrote: > >> Hi Brian, >>=20 >> That all looks good. >>=20 >> -Andrew >>=20 >> On 12/14/2012 05:54 AM, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> In reviewing WGLC comments on 5101bis, specifically with respect to >>>timestamp wraparound (on which I'm still working on a response), I had >>>a look at RFC5102bis to see if the text there would be compatible with >>>such a thing. The sections describing the POSIX-based abstract data >>>types which include, unlike the others, encoding details; I would >>>suggest removing the encoding details, leaving them for RFC5101bis (and >>>alternate encodings, as in draft-trammell-ipfix-text-adt), to be >>>consistent with the rest of RFC5102bis. >>>=20 >>>=20 >>> OLD: >>>=20 >>> 3.1.15. dateTimeSeconds >>>=20 >>> The data type dateTimeSeconds is an unsigned 32-bit integer >>> representing the number of seconds since the UNIX epoch, 1 January >>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>=20 >>> 3.1.16. dateTimeMilliseconds >>>=20 >>> The data type dateTimeMilliseconds is an unsigned 64-bit integer >>> containing the number of milliseconds since the UNIX epoch, 1 >>>January >>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>=20 >>>=20 >>> NEW: >>>=20 >>> 3.1.15. dateTimeSeconds >>>=20 >>> The data type dateTimeSeconds represents >>> the number of seconds since the UNIX epoch, 1 January >>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>=20 >>> 3.1.16. dateTimeMilliseconds >>>=20 >>> The data type dateTimeMilliseconds represents >>> the number of milliseconds since the UNIX epoch, 1 January >>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>=20 >>>=20 >>> (The reference to [POSIX.1] remains necessary to clarify leap second >>>issues; i.e., this value is can be directly derived from the system >>>clock on a UNIX-like machine). >>>=20 >>>=20 >>> While reviewing this, I noticed that there's one other >>>encoding-specific as opposed to data-specific ADT: macAddress. I'd >>>suggest the following change as well: >>>=20 >>>=20 >>> OLD: >>>=20 >>> 3.1.12. macAddress >>>=20 >>> The type "macAddress" represents a string of 6 octets. >>>=20 >>>=20 >>> NEW: >>>=20 >>> 3.1.12. macAddress >>>=20 >>> The type "macAddress" represents a MAC-48 address. >>>=20 >>>=20 >>> I'd specify MAC-48 as opposed to EUI-48, because it's not clear that >>>require global uniqueness. On this point, does anyone know of the >>>correct reference to use here? I've been looking at various 802 >>>cross-references in RFCs but can't find anything that fits yet... >>>=20 >>> Comments? Even a "looks good" would be helpful. I'd like to make this >>>last change soon, so an -08 revision can be written up and sent up to >>>the IESG. >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian >>> _______________________________________________ >>> 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 > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Thu Dec 20 07:30: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 6BC7421F88C5 for ; Thu, 20 Dec 2012 07:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBf+5MNomrGX for ; Thu, 20 Dec 2012 07:30:40 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66F21F88C4 for ; Thu, 20 Dec 2012 07:30:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4716AD930A; Thu, 20 Dec 2012 16:30:39 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9DVoqAbh94Ot; Thu, 20 Dec 2012 16:30:39 +0100 (MET) 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 01F3BD9305; Thu, 20 Dec 2012 16:30:39 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Thu, 20 Dec 2012 16:30:38 +0100 Content-Transfer-Encoding: 7bit Message-Id: <89669FFA-1A65-4337-8BAA-CA31EE395F2D@tik.ee.ethz.ch> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1283) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 20 Dec 2012 15:30:41 -0000 hi Juergen, The current revision has these changes in it; it's ready for write-up. Thanks, cheers, Brian On 20 Dec 2012, at 16:24 , Juergen Quittek wrote: > Hi Brian and all, > > Does this mean we should delay the write-up until you have posted an > updated version? > > Thanks, > juergen > > On 17.12.12 12:04, "Andrew Johnson" wrote: > >> +1 >> >> Andrew >> >> >> On 14 Dec 2012, at 14:44, Andrew Feren wrote: >> >>> Hi Brian, >>> >>> That all looks good. >>> >>> -Andrew >>> >>> On 12/14/2012 05:54 AM, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> In reviewing WGLC comments on 5101bis, specifically with respect to >>>> timestamp wraparound (on which I'm still working on a response), I had >>>> a look at RFC5102bis to see if the text there would be compatible with >>>> such a thing. The sections describing the POSIX-based abstract data >>>> types which include, unlike the others, encoding details; I would >>>> suggest removing the encoding details, leaving them for RFC5101bis (and >>>> alternate encodings, as in draft-trammell-ipfix-text-adt), to be >>>> consistent with the rest of RFC5102bis. >>>> >>>> >>>> OLD: >>>> >>>> 3.1.15. dateTimeSeconds >>>> >>>> The data type dateTimeSeconds is an unsigned 32-bit integer >>>> representing the number of seconds since the UNIX epoch, 1 January >>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>> >>>> 3.1.16. dateTimeMilliseconds >>>> >>>> The data type dateTimeMilliseconds is an unsigned 64-bit integer >>>> containing the number of milliseconds since the UNIX epoch, 1 >>>> January >>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>> >>>> >>>> NEW: >>>> >>>> 3.1.15. dateTimeSeconds >>>> >>>> The data type dateTimeSeconds represents >>>> the number of seconds since the UNIX epoch, 1 January >>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>> >>>> 3.1.16. dateTimeMilliseconds >>>> >>>> The data type dateTimeMilliseconds represents >>>> the number of milliseconds since the UNIX epoch, 1 January >>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>> >>>> >>>> (The reference to [POSIX.1] remains necessary to clarify leap second >>>> issues; i.e., this value is can be directly derived from the system >>>> clock on a UNIX-like machine). >>>> >>>> >>>> While reviewing this, I noticed that there's one other >>>> encoding-specific as opposed to data-specific ADT: macAddress. I'd >>>> suggest the following change as well: >>>> >>>> >>>> OLD: >>>> >>>> 3.1.12. macAddress >>>> >>>> The type "macAddress" represents a string of 6 octets. >>>> >>>> >>>> NEW: >>>> >>>> 3.1.12. macAddress >>>> >>>> The type "macAddress" represents a MAC-48 address. >>>> >>>> >>>> I'd specify MAC-48 as opposed to EUI-48, because it's not clear that >>>> require global uniqueness. On this point, does anyone know of the >>>> correct reference to use here? I've been looking at various 802 >>>> cross-references in RFCs but can't find anything that fits yet... >>>> >>>> Comments? Even a "looks good" would be helpful. I'd like to make this >>>> last change soon, so an -08 revision can be written up and sent up to >>>> the IESG. >>>> >>>> Thanks, cheers, >>>> >>>> Brian >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Quittek@neclab.eu Fri Dec 21 01:55:05 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 B1A2C21F8AF8 for ; Fri, 21 Dec 2012 01:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 4aIkrzjihwxJ for ; Fri, 21 Dec 2012 01:55:05 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9821F8539 for ; Fri, 21 Dec 2012 01:55:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 128A6102B48; Fri, 21 Dec 2012 10:55:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kT1N8zy8w1l; Fri, 21 Dec 2012 10:55:02 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E29C2102B47; Fri, 21 Dec 2012 10:54:47 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.64]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 10:54:47 +0100 From: Juergen Quittek To: Brian Trammell Thread-Topic: [IPFIX] On Encodings in RFC5102bis Thread-Index: AQHN32EY5AzX9AafVUOUwHYpjXqSWg== Date: Fri, 21 Dec 2012 09:53:57 +0000 Message-ID: In-Reply-To: <89669FFA-1A65-4337-8BAA-CA31EE395F2D@tik.ee.ethz.ch> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] On Encodings in RFC5102bis 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, 21 Dec 2012 09:55:05 -0000 Hi Brian, OK. Thanks. =20 I'll do the write-up. Juergen On 20.12.12 16:30, "Brian Trammell" wrote: >hi Juergen, > >The current revision has these changes in it; it's ready for write-up. > >Thanks, cheers, > >Brian > >On 20 Dec 2012, at 16:24 , Juergen Quittek wrote: > >> Hi Brian and all, >>=20 >> Does this mean we should delay the write-up until you have posted an >> updated version? >>=20 >> Thanks, >> juergen >>=20 >> On 17.12.12 12:04, "Andrew Johnson" wrote: >>=20 >>> +1 >>>=20 >>> Andrew >>>=20 >>>=20 >>> On 14 Dec 2012, at 14:44, Andrew Feren wrote: >>>=20 >>>> Hi Brian, >>>>=20 >>>> That all looks good. >>>>=20 >>>> -Andrew >>>>=20 >>>> On 12/14/2012 05:54 AM, Brian Trammell wrote: >>>>> Greetings, all, >>>>>=20 >>>>> In reviewing WGLC comments on 5101bis, specifically with respect to >>>>> timestamp wraparound (on which I'm still working on a response), I >>>>>had >>>>> a look at RFC5102bis to see if the text there would be compatible >>>>>with >>>>> such a thing. The sections describing the POSIX-based abstract data >>>>> types which include, unlike the others, encoding details; I would >>>>> suggest removing the encoding details, leaving them for RFC5101bis >>>>>(and >>>>> alternate encodings, as in draft-trammell-ipfix-text-adt), to be >>>>> consistent with the rest of RFC5102bis. >>>>>=20 >>>>>=20 >>>>> OLD: >>>>>=20 >>>>> 3.1.15. dateTimeSeconds >>>>>=20 >>>>> The data type dateTimeSeconds is an unsigned 32-bit integer >>>>> representing the number of seconds since the UNIX epoch, 1 January >>>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>>>=20 >>>>> 3.1.16. dateTimeMilliseconds >>>>>=20 >>>>> The data type dateTimeMilliseconds is an unsigned 64-bit integer >>>>> containing the number of milliseconds since the UNIX epoch, 1 >>>>> January >>>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>>>=20 >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> 3.1.15. dateTimeSeconds >>>>>=20 >>>>> The data type dateTimeSeconds represents >>>>> the number of seconds since the UNIX epoch, 1 January >>>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>>>=20 >>>>> 3.1.16. dateTimeMilliseconds >>>>>=20 >>>>> The data type dateTimeMilliseconds represents >>>>> the number of milliseconds since the UNIX epoch, 1 January >>>>> 1970 at 00:00 UTC, as defined in [POSIX.1]. >>>>>=20 >>>>>=20 >>>>> (The reference to [POSIX.1] remains necessary to clarify leap second >>>>> issues; i.e., this value is can be directly derived from the system >>>>> clock on a UNIX-like machine). >>>>>=20 >>>>>=20 >>>>> While reviewing this, I noticed that there's one other >>>>> encoding-specific as opposed to data-specific ADT: macAddress. I'd >>>>> suggest the following change as well: >>>>>=20 >>>>>=20 >>>>> OLD: >>>>>=20 >>>>> 3.1.12. macAddress >>>>>=20 >>>>> The type "macAddress" represents a string of 6 octets. >>>>>=20 >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> 3.1.12. macAddress >>>>>=20 >>>>> The type "macAddress" represents a MAC-48 address. >>>>>=20 >>>>>=20 >>>>> I'd specify MAC-48 as opposed to EUI-48, because it's not clear that >>>>> require global uniqueness. On this point, does anyone know of the >>>>> correct reference to use here? I've been looking at various 802 >>>>> cross-references in RFCs but can't find anything that fits yet... >>>>>=20 >>>>> Comments? Even a "looks good" would be helpful. I'd like to make this >>>>> last change soon, so an -08 revision can be written up and sent up to >>>>> the IESG. >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > From muenz@net.in.tum.de Fri Dec 21 13:06:47 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 157B921F85DF for ; Fri, 21 Dec 2012 13:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC7jnPa4aXUr for ; Fri, 21 Dec 2012 13:06:46 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id DC0F021F85C3 for ; Fri, 21 Dec 2012 13:06:45 -0800 (PST) Received: from [192.168.2.36] (g229139192.adsl.alicedsl.de [92.229.139.192]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 3F421188DBC8; Fri, 21 Dec 2012 22:06:41 +0100 (CET) Message-ID: <50D4CF3D.2050506@net.in.tum.de> Date: Fri, 21 Dec 2012 22:06:05 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <20121219093503.31303.29411.idtracker@ietfa.amsl.com> <8300ABE8-A995-4D03-B4F1-D973E4D2ADC8@tik.ee.ethz.ch> In-Reply-To: <8300ABE8-A995-4D03-B4F1-D973E4D2ADC8@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] Fwd: I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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, 21 Dec 2012 21:06:47 -0000 Brian, Have you read my WGLC comments? http://www.ietf.org/mail-archive/web/ipfix/current/msg06724.html I do not see them addressed. The last sentence that you added to 9.2 does not make sense: If the CP needs to cache Data Records because it does not know the Template, this cannot be a Template ID reuse situation. Regards, Gerhard On 19.12.2012 10:48, Brian Trammell wrote: > Greetings, all, > > Revision -04 of draft-ietf-ipfix-protocol-rfc5101bis addresses _most_ of the comments received during WGLC; many thanks to all who commented, as I think they've made the document much better. > > The language on template withdrawals has changed significantly. The concept of a "template withdrawal message" has been largely removed from the document, and the section has been made consistent with 8.2. 8.2 has also changed quite a bit based on WGLC feedback. I don't think it's possible to come up with a solution to all the various little corner cases you can run into with template withdrawals that will make everyone happy (trivial proof: I'm not happy with any of the possibilities I've seen or could imagine), but I think what's in Section 8.1 is at least internally self-consistent, so please have a look. > > Also completely new is Section 5.2 on timestamp wraparound, which describes epoch wrap on 1900 and 1970 epoch timestamps in a way that's consistent with what most people are probably already planning to do anyway; given V5 and V9, I suspect there's a lot of well-tested timestamp-wrapping corner-case code out there that can be easily adapted. > > Please have a look at these and comment to the list; if only with a "works for me". Chairs, please let us know if this new revision requires a further WGLC. > > Many thanks, and best regards, > > Brian > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-04.txt >> Date: December 19, 2012 10:35:03 AM GMT+01:00 >> To: i-d-announce@ietf.org >> Cc: ipfix@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Flow Information Export Working Group of the IETF. >> >> Title : Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information >> Author(s) : Benoit Claise >> Brian Trammell >> Filename : draft-ietf-ipfix-protocol-rfc5101bis-04.txt >> Pages : 66 >> Date : 2012-12-19 >> >> Abstract: >> This document specifies the IP Flow Information Export (IPFIX) >> protocol that serves for transmitting Traffic Flow information over >> the network. In order to transmit Traffic Flow information from an >> Exporting Process to an information Collecting Process, a common >> representation of flow data and a standard means of communicating >> them is required. This document describes how the IPFIX Data and >> Template Records are carried over a number of transport protocols >> from an IPFIX Exporting Process to an IPFIX Collecting Process. This >> document obsoletes RFC 5101. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 trammell@tik.ee.ethz.ch Sat Dec 22 04:24:15 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 65A5621F892A for ; Sat, 22 Dec 2012 04:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y+KRjUazUfp for ; Sat, 22 Dec 2012 04:24:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6F021F88BE for ; Sat, 22 Dec 2012 04:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C9920D9310; Sat, 22 Dec 2012 13:24:08 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id un5BA2JwMLio; Sat, 22 Dec 2012 13:24:08 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 8841ED9309; Sat, 22 Dec 2012 13:24:08 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <50D4CF3D.2050506@net.in.tum.de> Date: Sat, 22 Dec 2012 13:24:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85EFEC03-9D69-4338-84E3-075F986593C4@tik.ee.ethz.ch> References: <20121219093503.31303.29411.idtracker@ietfa.amsl.com> <8300ABE8-A995-4D03-B4F1-D973E4D2ADC8@tik.ee.ethz.ch> <50D4CF3D.2050506@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1283) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Sat, 22 Dec 2012 12:24:15 -0000 Hi, Gerhard, I recall reading them but _completely_ forgot to add them to the list of = edits for -04; sorry about that! I'll include these along with other = comments on -04 edits after the holidays in a -05. Thanks, cheers, Brian On Dec 21, 2012, at 10:06 PM, Gerhard Muenz wrote: >=20 > Brian, >=20 > Have you read my WGLC comments? > http://www.ietf.org/mail-archive/web/ipfix/current/msg06724.html > I do not see them addressed. >=20 > The last sentence that you added to 9.2 does not make sense: If the CP = needs to cache Data Records because it does not know the Template, this = cannot be a Template ID reuse situation. >=20 > Regards, > Gerhard >=20 >=20 >=20 > On 19.12.2012 10:48, Brian Trammell wrote: >> Greetings, all, >>=20 >> Revision -04 of draft-ietf-ipfix-protocol-rfc5101bis addresses _most_ = of the comments received during WGLC; many thanks to all who commented, = as I think they've made the document much better. >>=20 >> The language on template withdrawals has changed significantly. The = concept of a "template withdrawal message" has been largely removed from = the document, and the section has been made consistent with 8.2. 8.2 has = also changed quite a bit based on WGLC feedback. I don't think it's = possible to come up with a solution to all the various little corner = cases you can run into with template withdrawals that will make everyone = happy (trivial proof: I'm not happy with any of the possibilities I've = seen or could imagine), but I think what's in Section 8.1 is at least = internally self-consistent, so please have a look. >>=20 >> Also completely new is Section 5.2 on timestamp wraparound, which = describes epoch wrap on 1900 and 1970 epoch timestamps in a way that's = consistent with what most people are probably already planning to do = anyway; given V5 and V9, I suspect there's a lot of well-tested = timestamp-wrapping corner-case code out there that can be easily = adapted. >>=20 >> Please have a look at these and comment to the list; if only with a = "works for me". Chairs, please let us know if this new revision requires = a further WGLC. >>=20 >> Many thanks, and best regards, >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-protocol-rfc5101bis-04.txt >>> Date: December 19, 2012 10:35:03 AM GMT+01:00 >>> To: i-d-announce@ietf.org >>> Cc: ipfix@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >>>=20 >>> Title : Specification of the IP Flow Information = eXport (IPFIX) Protocol for the Exchange of Flow Information >>> Author(s) : Benoit Claise >>> Brian Trammell >>> Filename : draft-ietf-ipfix-protocol-rfc5101bis-04.txt >>> Pages : 66 >>> Date : 2012-12-19 >>>=20 >>> Abstract: >>> This document specifies the IP Flow Information Export (IPFIX) >>> protocol that serves for transmitting Traffic Flow information = over >>> the network. In order to transmit Traffic Flow information from = an >>> Exporting Process to an information Collecting Process, a common >>> representation of flow data and a standard means of communicating >>> them is required. This document describes how the IPFIX Data and >>> Template Records are carried over a number of transport protocols >>> from an IPFIX Exporting Process to an IPFIX Collecting Process. = This >>> document obsoletes RFC 5101. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-04 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-04= >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 From Quittek@neclab.eu Wed Dec 26 09:18:10 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 E8A4721F8CE1; Wed, 26 Dec 2012 09:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 6kydr4dirNx8; Wed, 26 Dec 2012 09:18:10 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B50CD21F8CCC; Wed, 26 Dec 2012 09:18:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C59FA102B71; Wed, 26 Dec 2012 18:18:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkIeZ32tpE3U; Wed, 26 Dec 2012 18:18:08 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id AA836102B44; Wed, 26 Dec 2012 18:17:48 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.64]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 26 Dec 2012 18:17:48 +0100 From: Juergen Quittek To: Benoit Claise , IESG Secretary , IETF IPFIX Working Group Thread-Topic: Write-up for draft draft-ietf-ipfix-information-model-rfc5102bis-08.txt Thread-Index: AQHN44znWDgCpD8GNkm+/0rCwvw0rQ== Date: Wed, 26 Dec 2012 17:17:38 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica Subject: [IPFIX] Write-up for draft draft-ietf-ipfix-information-model-rfc5102bis-08.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, 26 Dec 2012 17:18:11 -0000 Dear Benoit and dear IESG Secretary, Below please find the write up for draft-ietf-ipfix-information-model-rfc5102bis-08.txt. The draft is ready for forwarding to the IESG for publication. Best regards, Juergen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Write-up for draft draft-ietf-ipfix-information-model-rfc5102bis-08.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header indicates: "Category: Standards Track". It is appropriate. The RFC obsoletes standards track RFC 5202. It defines the standard for specifying and registering information Elements for the IPFIX protocol. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: 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. Working Group Summary: The documents has been significantly changed in content compared to RFC 5202. The main reason for the change is the existence of an IANA registry for IPFIX information elements. This change was fully aggreed on in WG discussions. Document Quality: This is an update of RFC 5102 based on a lot of practica experiences with specifying registering and implementing IPFIX information elements. Changes compared to RFC 5102 result from these experiences. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the draft and is fully convinced that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had multiple individual reviews from key WG members during WG last call. Several comments were made and have been addressed when updating the document after the reviews.The shepherd has no concern about the depth or breadth of the reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no such issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. =20 (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet- Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits. The only issue is that references to work in progress need to be updated. These may create a MISSREF during RFC-Editor processing and will eventually be resolved as refernces to RFCs. =20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No further formal review required except for a thorough review by IANA which will be conducted anyway. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there are references to draft-ietf-ipfix-protocol-rfc5101bis and draft-ietf-ipfix-ie-doctors-07. Both documents are progressed by the IPFIX working group and will be published before or together with this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. RFC 5102 will be obsoleted by this document. This is explicitly mentioned in the abstract and introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations are of particular importance for this documents, because one of its main subjects is the registration of IPFIX information elements at IANA. Consequently, the IANA considerations sections has been checked thoroughly by WG and shepherd. =20 (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new IANA registries requested by this document. It rather updates the descriptions of existing ones. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None to be done.