Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05
Andrew Feren <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
On 03/28/2012 06:48 AM, Chris Inacio wrote: > http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05 > > ClassEngineID + SelectorID - shouldn't this be 32-bits and possible to be shortened using reduced size encoding? I'm not sure there is any advantage to saying you won't know until you see the Engine ID; and seriously, from an implementation point of view; building the decoder, I'm not going to care while parsing the information. I will only care when doing the human display level - when I have to do the lookups. For the protocol, (on the wire,) I prefer a 32-bit field. Hi Chris, I don't see how it can be just 32-bits since according to section 4.2 classificationEngineId=12(PANA-L2) + selectorId = 6 bytes. I'm also not sure I agree on using reduced size encoding. If NetFlow v9 is being exported and you are trying to minimize your encoding size you don't have much choice. The problem I have with the reduced size encoding described for legacy protocols is that an applicationId that should be common to anyone implementing this draft (1..1 for example) can actually be encoded encoded 5 different ways. Gross. I'd prefer to burn some extra bytes for v9 rather than try and deal with the normalizing different encodings, but I think that genie is already out of the bottle. I definitely wouldn't want to see that continue in IPFIX since we have a perfectly nice variable length octetArray. With a variable length octetArray at least equivalent applicationIds can be matched without having to decompose them. -Andrew _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix