Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05
Benoit Claise <bclaise@cisco.com> Fri, 25 April 2014 13:32 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D68F1A0494 for <ipfix@ietfa.amsl.com>; Fri, 25 Apr 2014 06:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.772
X-Spam-Level:
X-Spam-Status: No, score=-8.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe61p-K0tHVj for <ipfix@ietfa.amsl.com>; Fri, 25 Apr 2014 06:32:21 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 973C41A01D1 for <ipfix@ietf.org>; Fri, 25 Apr 2014 06:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37704; q=dns/txt; s=iport; t=1398432736; x=1399642336; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=KkG0fsnmQlqNdn2AXAYcLYjJiyh7qGsGlnd/EUFRaSg=; b=mm2x7qwL7TvasPK5tx9OZcDohadpNYnOLCNQQrlANi09BSnklDe27LIM 6IGXN4OsEO2vmmaQB5Xd4U9wTl7a9tN+WGgUycqNND15z7vDOEwoQozCi r0E3rkWA6TkVCF01hPqdjJPug2tfKE8fLmzC3chCiLYYniik9NIgAwUtr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcEAPJiWlOtJssW/2dsb2JhbABZDoNHiRmyY4h6gSV0giUBAQEDARoDClERCw4TFgEOCQMCAQIBRQYBDAgBAYg1CA3KcReJN4UphDkBA5UTg3KBOIUjjAGCcUI7
X-IronPort-AV: E=Sophos; i="4.97,927,1389744000"; d="scan'208,217"; a="26986266"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Apr 2014 13:32:14 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PDWCdp017711; Fri, 25 Apr 2014 13:32:12 GMT
Message-ID: <535A63DC.3090308@cisco.com>
Date: Fri, 25 Apr 2014 15:32:12 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>, IPFIX Working Group <ipfix@ietf.org>
References: <534C76C7.9030108@auckland.ac.nz>
In-Reply-To: <534C76C7.9030108@auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------080804080705040804010304"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/yXh5eePTvqCUMOIxkAKwrUsXexc
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 13:32:25 -0000
Dear all, I stopped my review at section 4.4.2 (spent a couple of hours already), and I'm afraid the draft is not ready. Here is my feedback. - Section 1 For example, in the IPFIX information model [RFC7012 <http://tools.ietf.org/html/rfc7012>], Information Elements coming from the SNMP world have already been specified, e.g., ingressInterface and egressInterface both refer to the ifIndex defined in [RFC2863 <http://tools.ietf.org/html/rfc2863>]. As Jürgen noted, RFC 7012 doesn't specify the IPFIX information elements any longer. This is done in the IANA registry. - Section 2 In the best case, assuming very tight integration of an IPFIX Collector with and SNMP polling engine, SNMP data is retrieved shortly after Data Records have been received, which implies a delay of the sum of the active or inactive timeouts (if not null) plus the time to export the Flow Record to the Collector. For active and inactive timeouts, provide a reference to RFC 5470 , section 5.1.1. "Flow Expiration" Even if RFC 5470 doesn't call them active and inactive timeouts (btw, don't change that, these are well known terms), this is a good reference. - Section 2 This draft does not specify SNMP notifications, even if the specifications in this document could potentially allow this. draft -> document Same remark for: For each of these the options this draft specifies exactly which mibObjectValue to use. This draft defines two forms of indexing that can be used for SEQUENCE MIB Objects. - Section 2 The simple and application-wide data types specified in SMIv2 [RFC2578 <http://tools.ietf.org/html/rfc2578>], along with a new Textual Conventions Remove the s - Section 3 mibObjectValue Refers to any and all of the mibObjectValue Information Elements generically. Any restriction or requirement in this document that refers to mibObjectValue applies to the following Information Elements defined inSection 10.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-10.1>: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, mibObjectValueUnsigned, mibObjectValueTable and mibObjectValueSequence. Change mibObjectValue to mibObjectValue Information Elements. This is how it's used in some sentences in the rest of the document. However, I also see: mibObjectValue Field or mibObjectValue field I don't know what the term field refers to. Please change this to mibObjectValue Information Elements - Section 4 The Exporting process MAY extract the data values for mibObjectValue fields from a Process that resides on the same device or MAY capture/ create the data required to match the definition of the MIB Object. In particular exporting a value from a MIB does not imply that the SNMP process on the Device supports that MIB. Why is Process capitalized? Also MAY to may. This is not a RFC 2119 keyword required for the implementation. - Section 4 The main issue that arises from exporting MIBs in IPFIX is that MIB Object Identifiers do not fit into the standard IPFIX Template format [RFC7011 <http://tools.ietf.org/html/rfc7011>], as this only provides a 16-bit Information Element identifier and the length of the Information Element. I would remove "and the length of the Information Element", which doesn't add anything to this sentence - Section 4 One approach to this problem would be to extend the IPFIX standard to allow extended field specifiers so metadata about Fields can be included in Data Templates. Fields -> field - Section 4 However, future versions of IPFIX MAY export the required MIB metadata as part of newer set versions. MAY -> may. Please review all RFC 2119 keywords - Section 4 This is a standard IPFIX Option Template Set that MUST include a minimum set of required fields (seeSection 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>) and MAY include extra fields to provide more meta information about one of the mibObjectValue fields. While you're not yet in the specifications in Section 4, I would not introduce MUST and MAY here. This also contradicts the REQUIRED and RECOMMENDED in section 4.2.1 Please group the RFC 2119 keywords in section 4.2.1 - Throughout the document Option Template -> Options Template Note: IIRC, there were inconsistencies in RFC 5101, which were corrected in RFC 7011 - Major issue: I confused by mibFieldOption Is this a IE or an Options Template? The TOC shows: 4.2. MIB Field Options - Specifications and Required Fields . 11 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>. mibFieldOption . . . . . . . . . . . . . . . . . . .12 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-12> 4.2.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>. mibSubFieldOption . . . . . . . . . . . . . . . . . .13 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-13> 4.2.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>. mibTypeOption . . . . . . . . . . . . . . . . . . . .13 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-13> 4.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.3>. IPFIX and MIB Data Model . . . . . . . . . . . . . . . .14 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-14> 4.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4>. MIB Field Option Template Formats . . . . . . . . . . . .15 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-15> 4.4.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.1>. Data Template containing a mibObject Field . . . . .15 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-15> 4.4.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2>. mibFieldOption Template . . . . . . . . . . . . . . .17 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-17> 4.4.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.3>. mibFieldOption Data Records . . . . . . . . . . . . .18 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-18> 4.4.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.4>. Option Template containing a mibObject Field . . . .19 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-19> 4.4.5 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.5>. mibFieldOption Template with Semantics Fields . . . .20 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-20> 4.4.6. mibFieldOption Template with extra MIB Object Details 21 It's not clear! This document also defines three standard Option Templates (see Section 4.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB Object meta data: o mibFieldOption (Section 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>) o mibSubFieldOption (Section 4.2.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>) o mibTypeOption (Section 4.2.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>) Ok, so these are Options Templates. If this is the case, change the TOC section titles Then I see in figure 1 +------------------------+ | mibFieldOptionTemplate | +------------------------+ What is a mibFieldOptionTemplate ? This document defines a mibFieldOption Template to export the extra meta information required for a mibObjectValue field. Well, this one above is wrong. This should be Options Template, right? Then I see 2. A mibFieldOption Template Set The mibFieldOption Template describes which metadata will be sent for each mibObjectValue being exported. These should be Options Template Set, right? Then, I look at 4.2.1. mibFieldOption Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Field with a mibFieldOption: Then I look at 4.4.2. mibFieldOption Template The mibFieldOption Template is a Standard Option Template which defines the Fields that will be exported to provide enough metadata about a mibObjectValue so that the Collector can tie the data values in the mibObjectValue back to the definition of the MIB Object. And I finally understand that mibFieldOption is an Options Template. What is very confusing to me is that mibFieldOption is apparently simply an Options Template, like we have defined in IPFIX (http://tools.ietf.org/html/rfc7011#section-4.1) or PSAMP (http://tools.ietf.org/html/rfc5476#section-6.5.1) However, this Options Template is called like an IPFIX IE: mibFieldOption This should be called "MIB Field Options Template" throughout the document. OLD: This document also defines three standard Option Templates (see Section 4.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB Object meta data: o mibFieldOption (Section 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>) o mibSubFieldOption (Section 4.2.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>) o mibTypeOption (Section 4.2.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>) NEW: This document also defines three standard Option Templates (see Section 4.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB Object meta data: o MIB Field Options Template (Section 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>) o MIB SubField Options Template (Section 4.2.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>) o MIB Type Options Template (Section 4.2.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>) - Major: Why do we have ... http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1 http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2 ... with slightly different specifications? As I mentioned previously, there are also some conflicting spec rules at the beginning of the section 4 - 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 = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope field count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Example of tcpCurrEstab mibFieldOption Template Set This is not an Template Set, but an Options Template Set. Same remark for all the examples. - Section 4.2 Why a single in this sentence? For each mibObjectValue field that is defined in an IPFIX Template, a single mibFieldOption Data Record MUST be exported that provides the required minimum information to define the MIB object that is being exported (seeSection 4.2.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>). What if we export with UDP? We might want to re-export this metadata information, without which the collector can't interpret the data. This contradicts: Note that the ID of an identical mibFieldOptionTemplate which has already been exported MAY be reused without exporting the Template again. - Section 4.2 This mibFieldOption Data is defined in a template referred to in this document as a mibFieldOption Template with the format specified in Section 4.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4>. What's mibFieldOption Data? Template -> Options Template - Section 4.2 _ A Template that uses a mibObjectValue Field MUST be exported prior to the corresponding mibFieldOption Data Records._ It is RECOMMENDED that these are all exported in the same IPFIX Message. Note that this places an implicit size constraint on the export. _ These MUST all be exported prior to the corresponding Data Records which depend upon them._ i.e. referring to Figure 1, the export order MUST be: The two underlined sentences are redundant. - Major While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as they are per field: You don't explain those circumstances - I arrived at section 4.3, I'm not clear when I need to use mibSubFieldOption ormibTypeOption For mibSubFieldOption, this only thing I read so far is: To export a mibObjectValue that is contained in a mibObjectValueSequence Field with a mibSubFieldOption three fields are REQUIRED: Not too clear. - Major, Section 4.4.1 Multiple mibFieldOption that refer to a single mibObjectValue MUST NOT be exported. What is Multiple mibFieldOption? Multiple Data Records. No Multiple different Data Records. I agree Multiple Options Template Records. No Multiple different Options Template Records. I agree - Major, Section 4.4.1 OLD: 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 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueInteger | Field Length (mib) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPFIX Template Set using mibObjectValue Field NEW: 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 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = <mibObjectValue> | Field Length (mib) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPFIX Template Set using mibObjectValue Field Then you have to explain that <mibObjectValue> could be mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, mibObjectValueUnsigned, mibObjectValueTable and mibObjectValueSequence. I stopped my review at section 4.4.2, but plenty of my feedback would apparently be equivalent for the rest of the draft. Regards, Benoit > > Hi all: > > Sorry to be a little slow with this - the dust has settled from IETF-89, > and I've almost managed to catch up. > > The WG Last Call for our MIB Variable Export draft starts now, > and will end on Wednesday, 30 April. > > Please read it, and - better still - post reviews of it to the IPFIX > list! > > Cheers, Nevil >
- [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-ex… Nevil Brownlee
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Juergen Schoenwaelder
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Benoit Claise
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Benoit Claise
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Colin McDowall
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Colin McDowall
- Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variabl… Colin McDowall