Re: [IPFIX] new IPFIX fields for traffic classification

[Paul Aitken <[e-mail]>]

Chris,

We've been asked to export strings coming from a classification engine.

We need an extensible scheme which allows the classification team to 
export their information with zero intervention from us or from any 
external registry maintainer as they add new classifications.

An ID-based export has multiple disadvantages as you list below - not 
least of which is that it stalls the dev/rel cycle while new IDs are 
requested from the registry maintainer (say, IANA). Most importantly, 
there can be no central registry for on-box user-defined classifications.

The main disadvantages of exporting the strings directly are bandwidth 
and interoperability. However, the main advantage is that new 
classifications can be exported immediately.

Since we're exporting the strings in enterprise-specific IDs, there's 
essentially no interoperability (unless others also export cisco PEN IDs 
- which is unwise). Interoperability and bandwidth would both be 
improved by moving to IANA elements.

Cheers,
P.


On 13/06/11 16:45, Chris Inacio wrote:
> On Jun 13, 2011, at 11:22 AM, Brian Trammell wrote:
>
>> Hi, Paul,
>>
>> A suggestion: if these are encoded in strings, why not specify a delimiter-separated ID space and have a single flowClassification string with this delimiter separated space.
>>
>> IE "flowClassification" = "email.gmail", "ftp-group.ftp-data" and so on?
>>
>> This would allow sub-sub-sub categories, as well ("voip.skype.datachannel.noudp.v5")
>>
>> Cheers,
>>
>> Brian
>>
> I have a lot more to say down below; but I agree with Brian.  If there is a desire to start using string fields like this in the protocol, then I think having some structure in the strings that allows them to be somewhat hierarchal maybe, would be wise.
>
>
>> On Jun 13, 2011, at 5:04 PM, Paul Aitken wrote:
>>
>>> Dear IPFIX experts,
>>>
>>> Cisco would like to define some new IPFIX fields for traffic classification so we can attach classification information to each exported flow.
>>>
>>> Unlike many other fields, we don't propose to encode these fields numerically, so the usual option table mapping numbers to names won't be necessary.
>>>
>>> Instead, these fields would contain strings. Each field would be extensible so new strings could be added in future. In fact, we expect this to be a regular occurrence as new classifications are defined.
>>>
>>> However, it's not desirable - and perhaps not even possible - to list all the classification values. So there won't be any complete or exhaustive value list for any of these fields, and IANA won't maintain a registry for each field.
>>>
>>> This is similar to the existing wlanSSID, interfaceName and VRFname fields: while we can define the purpose of these fields, the values cannot be listed exhaustively. These can only be defined as generic strings, and no attempt should be made to register all the possible values.
>>>
>>> While we've already defined enterprise-specific fields, we feel these fields will be generally useful to the community. Nevil has asked for discussion before approving our request for new IANA field allocations.
>>>
>>> So, please discuss... ;-)
>>>
>>>
>>> Specifically, the fields which we'd like to define are:
>>>
>>>    * Category = a protocol attribute which broadly groups a set of protocols having the same characteristic.
>>>        e.g. file-sharing, email.
>>>
>>>    * Sub-category = a second level category attribute
>>>        e.g. p2p-file-transfer, gmail
>>>
>>>    * Application-group = a protocol attribute which groups a set of protocols belonging to same application.
>>>        e.g. ftp-group
>>>
>>>
>>> Cheers,
>>> P.
> Why would you (being Cisco) want to use strings?
>
> There are the obvious downsides to table mappings: have to have some type of out-of-band mechanism to distribute them, or define some new options records that allows them to be distributed.  If not sending them from probe to collector, then you need a central registry.  The consensus mechanism of the central repository is too slow, strings are agile.  Strings more easily allow ``quiet-mode'' before introducing a product to market, making the suits happy, by eliminating the central repository.  I understand that these are all problems, but I would argue these are still better problems to have than having strings.
>
>
> The problem with strings:  The model without a central repository means everyone developing their own strings, mostly incompatible ones.  (The collector will then have to guess that Cisco's "email:mua" is the same as my "smtp:user-agent".  Or push the problem back up to the user.)  Strings are a lot less efficient.  IPFIX's design is clearly architected to bandwidth reduction by sending the type-length information very infrequently, and including reduced length encoding - strings are not bandwidth friendly.
>
> I would still argue for a bandwidth efficient interoperable protocol.  I don't think adding strings would create an interoperable protocol.
>
> So that said, what I would ask of you Paul, is to describe the why's that make this string mapping so attractive?
>
> (Although if we can all figure out how to get bonuses from our respective employers for writing RFC's, we can start working on the SIP protocol model to define the strings, and I'm fully on board! :) )
>
>
> Best regards,
> Chris Inacio
>
>
>
>>> _______________________________________________
>>> IPFIX mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipfix