Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS

[David Harrington <[e-mail]>]

Hi,

I agree we should try to standardize a limited **information model** (see
rfc3444) for nat logging.
Then we should standardize one or more protocol-specific data models.

I do not think we should produce every variant of data model just because
we can; there should be solid justification for each standard model.
I would like to see what proprietary solutions are already being used
widely, and would benefit from standardization.

--
David Harrington
Internet Engineering Task Force (IETF)
[e-mail]
[phone]





On 7/16/12 6:42 PM, "Reinaldo Penno (repenno)" <[e-mail]> wrote:

>I see the question a bit differently.
>
>I believe we should provide some level of standardization across these
>protocols. For example, binding type representation, port ranges,  mapping
>count, etc should be represented by the same data model in all protocols.
>We proposed that in Taipei but at that time maybe the problem wasn't ripe.
>
>Going on step further, in case of NAT logging we should agree on basic
>information set irrespective if somebody would use Radius, IPFix or any
>other protocol.
>
>Thanks,
>
>Reinaldo  
>
>On 7/16/12 3:19 PM, "Tassos Chatzithomaoglou" <[e-mail]>
>wrote:
>
>>Imho, every protocol is destined to cover specific needs.
>>
>>For auditing reasons (which is my primary concern curtently) i would
>>prefer to use RADIUS
>>(or DIAMETER or anything AAA related), as long as the frequency of acct
>>records remains 
>>within limits. Passing information to subscriber sessions could also be
>>done through 
>>RADIUS push.
>>SYSLOG is good for fast one way communication and maybe it could be used
>>for alerting.
>>SNMP (notifications) could also be used for alerting, but its usage for
>>on-demand or 
>>historical detailed statistics gatherings should be preferred.
>>IPFIX could be used for near realtime logging and of course for
>>statistics.
>>
>>Generally i agree with your concerns, but instead of "choosing" only one
>>protocol, i would
>>prefer to have the scope of each protocol clearly/strictly defined, so
>>depending on my 
>>needs i knew what to deploy.
>>For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in
>>order to have the
>>historical correlation of username & IP-related stuff.
>>
>>--
>>Tassos
>>
>>Dan Wing wrote on 16/7/2012 20:55:
>>> As an individual, I have been worried about the possibility of
>>>disparate
>>> data models for NATs.  We currently have four ways to report
>>>information
>>> about a NAT or other address-sharing device,
>>>
>>> SYSLOG, 
>>>http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00
>>> IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05
>>> SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib
>>> RADIUS,
>>> 
>>>http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#sect
>>>i
>>>on-
>>> 4.2
>>>
>>> My concern is that operators may find it necessary to deploy all four
>>> protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging
>>>and.
>>> This seems undesirable.  Imagine, for example, that only one of those
>>> protocols supported pseudo-random port assignment but only one other
>>> protocol provided alarms for when a subscriber consumed all their ports
>>>(and
>>> thus might open a support case with the operator that "the Internet is
>>> down").
>>>
>>> Are my concerns misplaced?
>>>
>>> -d
>>>
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>
>>
>>_______________________________________________
>>Behave mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/behave
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave