Return-Path: 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 422051A9059 for ; Wed, 16 Dec 2015 14:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nyF7JBVrjPke for ; Wed, 16 Dec 2015 14:41:07 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929A21A9056 for ; Wed, 16 Dec 2015 14:41:06 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0266.001; Wed, 16 Dec 2015 17:41:05 -0500 From: Andrew Feren To: Paul Aitken , Gerald Naveen A Thread-Topic: [IPFIX] basicList clarification Thread-Index: AQHRNzNbwHz1ucln+0aHb7haeiYjWZ7MWm8AgAAeuICAAIvcAIABIjeb Date: Wed, 16 Dec 2015 22:41:05 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7595C1F74@PLXRDC01.plxr.local> References: <5670122C.9090806@gmail.com> , <5670A144.10708@gmail.com> In-Reply-To: <5670A144.10708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.14.173] Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_" MIME-Version: 1.0 Archived-At: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org 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: Wed, 16 Dec 2015 22:41:10 -0000 --_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul and Gerald, I have slightly mixed feelings on this, but my current bias is towards not = requiring a second IE. I plan to look at this a bit more closely, but here= are a few thoughts. see [ACF] inline... ________________________________ From: IPFIX [ipfix-bounces@ietf.org] on behalf of Paul Aitken [pjaitken@gma= il.com] Sent: Tuesday, December 15, 2015 6:24 PM To: Gerald Naveen A Cc: ipfix@ietf.org Subject: Re: [IPFIX] basicList clarification Gerald, Hi Paul, Thanks for the responses. It clarifies for most part; while I would also li= ke to clarify few things on my question. (tagged [Gerald] inline) See [PJ] inline... So it appears we would need to define Y as IE and mark X as basicList of Y. What you're proposing is possible if there's a good reason. However we want= to avoid unnecessary duplication of existing IEs into new "list of" IEs as= much as possible, so you should only create X if there's a strong justific= ation (eg it models an existing object). Thanks again On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken > wrote: Gerald, 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 informat= ion 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 strin= g (as X is already strongly defined). But string is a type, not info elemen= t. We would like to retain X (instead of defining a template directly with a s= tandard basicList). And we don't have any other need to define a new Inform= ation Element Y. Y defines the list elements which tells the Collector that the list contain= s 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 ex= porting zero or more of them. [Gerald] This is definitely a choice. However, as I mentioned, this makes t= he template weakly typed (ie., the element is just #291 basicList). We woul= d like to enforce stronger types at the template itself (this was the motiv= e behind defining X) [PJ] This was an objection from the Collector side when we were writing the= IPFIX Structured Data draft, because the collector can no longer tell what= information it's going to receive ahead of time (just "a list"); it has to= check each Data Record to know what information the list contains. On the = other hand, since the basicList is essentially a wrapper around any other I= E, it's not necessary to create new strongly-defined list IEs for each of t= he existing (and potentially all future) IEs. [ACF] From the collector side I still prefer strongly typed templates. The= re may be some middle ground possible like an option template that reports = the range of expected values for a template with a basicList (or other gene= ric structure). I started a draft on this a while back, but it got back bu= rnered. Might be time to dust it off again. 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 (str= ongly defined) Y. [Gerald] Yes, this is also a choice; but we don't need Y for any other reas= on except to fit into the basicList detail. So wanted to know if that can b= e avoided. I got my answer: No (if strongly typed templates). [PJ] Strongly typed templates would require a new "list of" IE for every ex= isting (and future) IE that was to become a list, which is incredibly waste= ful. [ACF] I think there can be different considerations for lists in standard = space and list IEs with a PEN. I realize that the basicList encoding has a information-element ID of the i= tem in payload -- is this mandatory? Yes. The encoding would not be interoperable without it. [PJ] Here I understood the question to be whether the IE ID field was requi= red in the basicList encoding - ie, it seemed that you were proposing a new= encoding where, since X is already strong defined as a basicList of Y, the= re's no need to include Y in the export. [ACF] I think the quibble here is whether Y needs an IE if it is only used = as a list. If an IE already exists you can use it. Requiring Y becomes wa= steful (to borrow your earlier word) in a different way. Assume there are = many lists of A, B, C, D and X. There isn't a need to ever export A, B, C,= D or X as any thing other than a list. The second IE isn't really needed. Or for a strongly typed item X, we could expect the IPFIX parser to be awar= e of contents (interface name) by contract? No. Every collector which implements RFC 6313 (IPFIX Structured Data) shoul= d be able to decode a basicList of Y. However, the mechanism which you prop= ose requires the collector to have special knowledge of the internals of X,= which is not scalable. In short, such an Exporter would not be interoperab= le with all Collectors. [Gerald] X is not a different encoding. X is a basicList (sort of more stro= ngly typed. ie., X is a basicList of Y). So the encoding is just the same a= s #291 standard basicList. But when the template declares a element as X, i= t is clearly typed even without having to look into the data (or it also do= esn't let the exporter send X of Z on the same template). [PJ] What you're proposing is possible and may be useful in some circumstan= ces. For example, for the MIB export draft, we've defined new IEs (#443, #4= 44) which are subTemplateLists, in order to give strong typing information = because the IE contains a row from a table. (See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 an= d http://www.iana.org/assignments/ipfix/ipfix.xhtml) [ACF] A different compromise might be some generic IEs, for exampe, a strin= g IE. Then you could have a list of aNames or bNames. Each of which put t= he (currently non existent) string IE ID as the ID in the strongly typed li= st. Of course that opens the door to generic basicList of generic strings.= Having a single list encoding is nice, but leaving out the ID probably is= n't any worse than fixed length vs var length strings. I reserve the right to change my opinions as I reread 6313, -Andrew P. 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 su= ch as an element count, element lengths, delimiters or separators. It creat= es a new way of encoding list information which the collector must also und= erstand in addtion to the basicList encoding, which is not useful. In short= , you should not create list type elements; instead, use the basicList mech= anism. [Gerald] Agree. We aren't trying to redefine basicList encoding for sure. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Paul and Gerald,

I have slightly mixed feelings on this, but my current bias is towards not = requiring a second IE.  I plan to look at this a bit more closely, but= here are a few thoughts.

see [ACF] inline...


From: IPFIX [ipfix-bounces@ietf.org] on= behalf of Paul Aitken [pjaitken@gmail.com]
Sent: Tuesday, December 15, 2015 6:24 PM
To: Gerald Naveen A
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] basicList clarification

Gerald,

Hi Paul,

Thanks for the responses. It clarifies for most part; while I would also li= ke to clarify few things on my question. (tagged [Gerald] inline)

See [PJ] inline...


So it appears we would need to define Y as IE and mark X a= s basicList of Y.

What you're proposing is possible if there's a good reason. However we want= to avoid unnecessary duplication of existing IEs into new "list of&qu= ot; IEs as much as possible, so you should only create X if there's a stron= g justification (eg it models an existing object).


Thanks again

On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken <pjaitken@gmail.= com> wrote:
Gerald,

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.<= span class=3D"">


To create the template much more strongly typed, we have defined a cus= tom (enterprise) Information Element with a new ID (say X), which is define= d as a basicList of specific items (eg., InterfaceName).

My question to you all is: Is it mandatory that we have a separate informat= ion 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 e= lement.

We would like to retain X (instead of defining a template directly with a s= tandard basicList). And we don't have any other need to define a new Inform= ation 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 whethe= r they contain interface names, user names, a list of selectorNames, or a l= ist of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of t= hem.
[Gerald] This is definitely a choice. However, as I mentioned, this ma= kes the template weakly typed (ie., the element is just #291 basicList). We= would like to enforce stronger types at the template itself (this was the = motive behind defining X)

[PJ] This was an objection from the Collector side when we were writing the= IPFIX Structured Data draft, because the collector can no longer tell what= information it's going to receive ahead of time (just "a list");= it has to check each Data Record to know what information the list contains. On the other hand, since the basicList= is essentially a wrapper around any other IE, it's not necessary to create= new strongly-defined list IEs for each of the existing (and potentially al= l future) IEs.

[ACF] From the collector side I still prefer strongly typed templates. = ; There may be some middle ground possible like an option template that rep= orts the range of expected values for a template with a basicList (or other= generic structure).  I started a draft on this a while back, but it got back burnered.   Might be time = to dust it off again.


Perhaps you should define Y as a single instance o= f 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 e= xport a basicList of (strongly defined) Y.
[Gerald] Yes, this is also a choice; but we don't need Y for any other= reason except to fit into the basicList detail. So wanted to know if that = can be avoided. I got my answer: No (if strongly typed templates).

[PJ] Strongly typed templates would require a new "list of" IE fo= r every existing (and future) IE that was to become a list, which is incred= ibly wasteful.

[ACF]  I think there can be different considerations for lists in stan= dard space and list IEs with a PEN.

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.

[PJ] Here I understood the question to be whether the IE ID field was requi= red in the basicList encoding - ie, it seemed that you were proposing a new= encoding where, since X is already strong defined as a basicList of Y, the= re's no need to include Y in the export.

[ACF] I think the quibble here is whether Y needs an IE if it is only used = as a list.  If an IE already exists you can use it.  Requiring Y = becomes wasteful (to borrow your earlier word) in a different way.  As= sume there are many lists of A, B, C, D and X.  There isn't a need to ever export A, B, C, D or X as any thing other than = a list.  The second IE isn't really needed.

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 y= ou propose requires the collector to have special knowledge of the internal= s of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors.
[Gerald] X is not a different encoding. X is a basicList (sort of more= strongly typed. ie., X is a basicList of Y). So the encoding is just the s= ame as #291 standard basicList. But when the template declares a element as= X, it is clearly typed even without having to look into the data (or it also doesn't let the exporter send X o= f Z on the same template).

[PJ] What you're proposing is possible and may be useful in some circumstan= ces. For example, for the MIB export draft, we've defined new IEs (#443, #4= 44) which are subTemplateLists, in order to give strong typing information = because the IE contains a row from a table.

(See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 and= http://www.iana.org/assignments/ipfix/ipfix.xhtml)

[ACF] A different compromise might be some generic IEs, for exampe, a strin= g IE.  Then you could have a list of aNames or bNames.  Each of w= hich put the (currently non existent) string IE ID as the ID in the strongl= y typed list.  Of course that opens the door to generic basicList of generic strings.  Having a single list encodi= ng is nice, but leaving out the ID probably isn't any worse than fixed leng= th vs var length strings.

I reserve the right to change my opinions as I reread 6313,
-Andrew

P.


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. I= t creates a new way of encoding list information which the collector must a= lso understand in addtion to the basicList encoding, which is not useful. In short, you should not create l= ist type elements; instead, use the basicList mechanism.
[Gerald] Agree. We aren't trying to redefine basicList encoding for su= re. 



_______________________________________________=0A=
IPFIX mailing list=0A=
IPFIX@ietf.org=0A=
h=
ttps://www.ietf.org/mailman/listinfo/ipfix=0A=



--_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_--