Re: [IPFIX] basicList clarification

Paul Aitken <> Tue, 15 December 2015 13:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85D3A1A8895 for <>; Tue, 15 Dec 2015 05:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UrHGk62JVVYN for <>; Tue, 15 Dec 2015 05:14:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 186991A8886 for <>; Tue, 15 Dec 2015 05:14:24 -0800 (PST)
Received: by with SMTP id n186so164360821wmn.1 for <>; Tue, 15 Dec 2015 05:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=BoPpTh9Z53qlPTprXkJ9EkIO8WaDAOn2QKuXqXNIQHY=; b=Q0SzcZexKQ99NRRW6/cox6iVMQs17QLeAmryhtV9vcmrocnd3f7sb+eIgWOYW6GGhv 480xWJEgbAG7LSJr69Ic1Q1JDPmEeVZdFb2e6vzFLa8rNSwASI5U+da5fu1aO8Ebvw1+ 71wZM19GMeCcVXkUOijbQGqQy8/422drTp/dmqDOANYIqscNjCFOclexvMTcrqI4itCK F54onWCBRMsPO3dDl+wB3p9TsrhI+HMAXfo7AkcEHVQAkOfynX2ZAt+5+jX+kZprGmQ1 7RZtfBP5lQAoTrT6eY8l0USooXr+mnpshtIirteHfeHKaoG732gE+SWpOjt09ltFa1Ma iE3g==
X-Received: by with SMTP id x62mr4807073wmx.49.1450185262658; Tue, 15 Dec 2015 05:14:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q7sm1404949wjz.12.2015. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 05:14:21 -0800 (PST)
Message-ID: <>
Date: Tue, 15 Dec 2015 13:14:20 +0000
From: Paul Aitken <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Gerald Naveen A <>,
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040507070602010909070607"
Archived-At: <>
Subject: Re: [IPFIX] basicList clarification
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Dec 2015 13:14:26 -0000


> Hi all,
> It is my understanding from the RFCs that basicList type is an 
> encoding for list of IPFIX Information Elements.

Yes, where the list contains zero or more instances of a single IE.

> To create the template much more strongly typed, we have defined a 
> custom (enterprise) Information Element with a new ID (say X), which 
> is defined as a basicList of specific items (eg., InterfaceName).
> My question to you all is: Is it mandatory that we have a separate 
> information element called InterfaceName (say ID Y) and define X as a 
> basicList of Y ?

Yes, that's how the protocol is defined.

> For our need, it is enough for us, that we define X as a basicList of 
> string (as X is already strongly defined). But string is a type, not 
> info element.
> We would like to retain X (instead of defining a template directly 
> with a standard basicList). And we don't have any other need to define 
> a new Information Element Y.

Y defines the list elements which tells the Collector that the list 
contains strings, and it defines the semantics of those strings - eg 
whether they contain interface names, user names, a list of 
selectorNames, or a list of Application names. Then a basicList of Y 
tells the Collector that you're exporting zero or more of them.

Perhaps you should define Y as a single instance of X (so Y is well 
defined), then redefine X as a basicList of Y. Or if you don't want/need 
to define both X and Y, then use the basicList IE #291 to export a 
basicList of (strongly defined) Y.

> I realize that the basicList encoding has a information-element ID of 
> the item in payload -- is this mandatory?

Yes. The encoding would not be interoperable without it.

> Or for a strongly typed item X, we could expect the IPFIX parser to be 
> aware of contents (interface name) by contract?

No. Every collector which implements RFC 6313 (IPFIX Structured Data) 
should be able to decode a basicList of Y. However, the mechanism which 
you propose requires the collector to have special knowledge of the 
internals of X, which is not scalable. In short, such an Exporter would 
not be interoperable with all Collectors.


> Pls let me know if my question is unclear.
> Thanks in advance.
> - Gerald Naveen

The custom IE which you've defined must contain meta-data about the list 
such as an element count, element lengths, delimiters or separators. It 
creates a new way of encoding list information which the collector must 
also understand in addtion to the basicList encoding, which is not 
useful. In short, you should not create list type elements; instead, use 
the basicList mechanism.

> _______________________________________________
> IPFIX mailing list