Re: [IPFIX] basicList clarification
Gerald Naveen A <[email protected]> Tue, 15 Dec 2015 20:34:17 +0530
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <CAJR=o+HycZ6nwgs_bB0pcJ1cwdHZXAem7EVYh2KBZWpOYx-ygw@mail.gmail.com> |
--===============2558833578122342228== Content-Type: multipart/alternative; boundary=001a113de314804b510526f11a87 --001a113de314804b510526f11a87 Content-Type: text/plain; charset=UTF-8 Hi Paul, Thanks for the responses. It clarifies for most part; while I would also like to clarify few things on my question. (tagged [Gerald] inline) So it appears we would need to define Y as IE and mark X as basicList of Y. Thanks again On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken <[email protected]> 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 > 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. > [Gerald] This is definitely a choice. However, as I mentioned, this makes 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) > > 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. > [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). > > 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. > [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 same 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 of Z on the same template). > 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. 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. > [Gerald] Agree. We aren't trying to redefine basicList encoding for sure. > > > > _______________________________________________ > IPFIX mailing [email protected]://www.ietf.org/mailman/listinfo/ipfix > > > --001a113de314804b510526f11a87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Hi Paul,<br><br></div>Thanks for the responses. = It clarifies for most part; while I would also like to clarify few things o= n my question. (tagged [Gerald] inline)<br><br></div>So it appears we would= need to define Y as IE and mark X as basicList of Y.<br><div><div class=3D= "gmail_extra"><br></div><div class=3D"gmail_extra">Thanks again<br><br></di= v><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, Dec 15, 201= 5 at 6:44 PM, Paul Aitken <span dir=3D"ltr"><<a href=3D"mailto:pjaitken@= gmail.com" target=3D"_blank">[email protected]</a>></span> wrote:<br><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Gerald,<span class=3D""><br> <div><br> </div> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div> <div> <div> <div> <div>Hi all,<br> <br> </div> It is my understanding from the RFCs that basicList type is an encoding for list of IPFIX Information Elements.<br> </div> </div> </div> </div> </div> </div> </blockquote> <br></span> Yes, where the list contains zero or more instances of a single IE.<spa= n class=3D""><br> <br> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div> <div> <div>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).<br> <br> </div> 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 ?</div> </div> </div> </div> </blockquote> <br></span> Yes, that's how the protocol is defined.<span class=3D""><br> <br> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div> <div> 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.<br> <br> </div> 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.<br> </div> </div> </div> </blockquote> <br></span> 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.<br>= </div></blockquote><div>[Gerald] This is definitely a choice. However, as I= mentioned, this makes the template weakly typed (ie., the element is just = #291 basicList). We would like to enforce stronger types at the template it= self (this was the motive behind defining X) <br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> 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.<span class=3D""><br></span>= </div></blockquote><div>[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 typ= ed templates). <br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FF= FFFF" text=3D"#000000"><span class=3D""> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div>I realize that the basicList encoding has a information-element ID of the item in payload -- is this mandatory?</div> </div> </div> </blockquote> <br></span> Yes. The encoding would not be interoperable without it.<span class=3D"= "><br> <br> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div> Or for a strongly typed item X, we could expect the IPFIX parser to be aware of contents (interface name) by contract?</div> </div> </div> </blockquote> <br></span> 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.<br></d= iv></blockquote><div>[Gerald] X is not a different encoding. X is a basicLi= st (sort of more strongly typed. ie., X is a basicList of Y). So the encodi= ng is just the same as #291 standard basicList. But when the template decla= res a element as X, it is clearly typed even without having to look into th= e data (or it also doesn't let the exporter send X of Z on the same tem= plate).<br>=C2=A0 <br></div><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"= #FFFFFF" text=3D"#000000"> P.<span class=3D""><br> <br> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div> <div>Pls let me know if my question is unclear.<br> </div> <div><br> </div> Thanks in advance.<br> </div> - Gerald Naveen<br> </div> </blockquote> <br> <br></span> 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.<br></div></blockqu= ote><div>[Gerald] Agree. We aren't trying to redefine basicList encodin= g for sure. <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFF= F" text=3D"#000000"> <br> <blockquote type=3D"cite"> <br> <fieldset></fieldset> <br> <pre>_______________________________________________ IPFIX mailing list <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> <a href=3D"https://www.ietf.org/mailman/listinfo/ipfix" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/ipfix</a> </pre> </blockquote> <br> </div> </blockquote></div><br></div></div></div> --001a113de314804b510526f11a87-- --===============2558833578122342228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix --===============2558833578122342228==--