Subject: Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05

From: Andrew Feren <[email-masked]>
Date: Tue, 10 Apr 2012 17:06:16 -0400

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

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Apr 2012 16:03:08 +0200

Andrew, Chris,
>> 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'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 
> I definitely wouldn't want to see that continue in IPFIX since we have 
> a perfectly nice variable length octetArray.  With a variable length 
Exactly.

And what if, in the future, we have a registry, which is even bigger 
than the ones we have today?
With variable length, we're ready.

Regards, Benoit.

>
> -Andrew
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Apr 2012 16:19:45 +0200

Hi Chris,

Thanks for your review.
> 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 Engi…
See the answer I just sent to the IPFIX mailing list.
>
> I think the reference to the Cisco L7 registry should be removed from the main body text; and if possible added to some type of appendix.
This issue is that this is a list that keeps updating all the time. So a 
reference is actually required.
>
> Is defaulting to TCP for protocol conflicts the best answer?  Why not just make it relevant to the transport contained in another IE?
Because we would break the following rule: the semantic of one IE would 
depend on the value of a different one.
>
> Aren't the IEEE standards you reference, well standards: e.g. normative, not informative?
Good catch. Corrected.
>
> Can we add the definition of how to get an online registry into the document, and the XML definition of the registry?  We have all those possible registry entries - why not define the interchange (lightweight) to get registry of app labels, and an options record to to be to specify its address.
That makes a lot of sense, and we should/will do it. This will take a 
little bit of time to make it right.
However, the proposal for this draft is to put on paper the 
specifications of what has been implemented.
Copying Ron Bonica, the new AD sponsored for this draft (transferred 
from Dan Romascanu)
>
> e.g.
>
> Name: applicationRegistry
>        Description:
>          Specifies a URN where section 8.x well formed application registry information may be retrieved.
>        Abstract Data Type: string
>        Data Type Semantics: URN
>        ElementId:<to be assigned>
>        Status:
>
>
>
>
> <xml…>
> 	<registry ID major="1" minor="0">
> 		<provider>Cisco</provider>
> 		<release>_date_</release>
> 	<major>VER</major>
>    		<minor>VER</minor>
> 	</registry>
> 	<app_labels>
> 		<label>
> 			<id>80</id>
> 			<name>HTTP</name>
> 			<description>Primarily designed for transferring web pages, but extended to transfer *everything* on the net, because it is the only open port.</description>
> 			<category></category>
> 			<subCat></subCat>
> 			.
> 			.
> 			.
> 		</label>
> 		<label>
> 			.
> 			.
> 			.
> 		</label>
> 		.
> 		.
> 		.
> 	</app_labels>
> </xml>
>
>
>
> Then the Cisco specific references within the document above can be moved into the section related to how to get specific registries.
>
>
> What missing:
>
> I need data extracted from fields as well; with a big question on how to efficiently index into it.  I see two possibilities:
Sure ;-)
Many of us need this. This would be a second building block...
>
> (1)  We have a general registry of useful fields (I have no idea how to build this even close to comprehensively):
> 	1 - user
> 	2 - organization
> 	3 - command
> 	4- command path
> 	5 - …
>
> and then using structured data, under an application level, you can have something like application id:
> 	+--------------+---------------------------------------+
> 	|    1              | (string) inacio                            |
>          +--------------+---------------------------------------+
>          |    2              | (string) CERT                            |
>          +--------------+---------------------------------------+
>
> for something like an X.509 certificate.
>
> (2) define the fields specifically to the application protocols, which means extending the registry type information from above:
>
> X.509.user = inacio
> X.509.org = CERT
>
> for example.  But that leads to IE explosion.
>
>
> Lastly, also, why all the reserved registry numbers?  We're inventing something new, aren't we?  ;)
We started this project years ago, so let's say a few beginner mistakes.
On top of that, we might need some more registries for custom protocols ...

Regards, Benoit (as a contributor)

> Chris