Re: [IPFIX] basicList clarification
Paul Aitken <[email protected]> Tue, 15 Dec 2015 13:14:20 +0000
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============3114759548112551598== Content-Type: multipart/alternative; boundary="------------040507070602010909070607" This is a multi-part message in MIME format. --------------040507070602010909070607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. 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. 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. > > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix --------------040507070602010909070607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Gerald,<br> <div class="moz-cite-prefix"><br> </div> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> Yes, where the list contains zero or more instances of a single IE.<br> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> Yes, that's how the protocol is defined.<br> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> 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> <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.<br> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> Yes. The encoding would not be interoperable without it.<br> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> 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> <br> P.<br> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <div dir="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> 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> <br> <br> <blockquote cite="mid:CAJR=o+GSJah4cvjroN0raeAXj+7h2W2Vah4pi4V6u0BM7Sc1DA@mail.gmail.com" type="cite"> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ IPFIX mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/mailman/listinfo/ipfix</a> </pre> </blockquote> <br> </body> </html> --------------040507070602010909070607-- --===============3114759548112551598== 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 --===============3114759548112551598==--