Subject: [BEHAVE] logging drafts

From: Dan Wing <[email-masked]>
Date: Wed, 13 Mar 2013 14:11:05 -0400

The two NAT logging drafts were presented at the BEHAVE meeting at IETF86 (draft-sivakumar-behave-nat-logging-06 and draft-ietf-behave-syslog-nat-logging-00).  They are both WG documents and based on the feedback at the meeting, we would like to see:

 * an update of the table presented at the meeting (slide 6 of http://tools.ietf.org/agenda/86/slides/slides-86-behave-2.pdf).  
 * text added to the SYSLOG and IPFIX documents explaining their applicability.
 * discussion on the list to reach consensus that SYSLOG and IPFIX should, or should not, send different events because of their different applicability.

-d

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Mar 2013 19:17:12 +0100 (CET)

On Wed, 13 Mar 2013, Dan Wing wrote:

> * discussion on the list to reach consensus that SYSLOG and IPFIX 
> should, or should not, send different events because of their different 
> applicability.

I was the one who asked the syslog question from Jabber yesterday, forgot 
to type my name.

So I understand that syslog can be done over TCP and even TLS (even though 
this is not widely implemented), I would like some kind of discussion on 
how to actually do this in real life with hundreds of thousands of entries 
per second flowing across this logging solution.

There are boxes available today on the market that will do millions of new 
sessions per seconds. When I looked at this it seemed unfeasable to do 
logging for this amount of data, and doing the port block allocation is 
the only way to solve this problem. Is it suitable to have this kind of 
scalability discussion in these drafts (or at least a reference to one) or 
is that out of scope?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Mar 2013 14:31:57 -0400

I think it's quite reasonable to have such a discussion in the Syslog
draft. We did seem to agree yesterday that Syslog could implement all of
the events the IPFIX document does, but:

- enabling of specific reports should be configurable (a basic Syslog
functionality, I think);

- such a discussion of when you might enable per-session logging (low
volume situation, e.g., managed small office gateway) should be present.

We probably also want to address the point raised regarding blocking if
reliable transmission is used, by requiring a configurable policy regarding
whether sessions should continue to be set up even if the transmission
queue is full.

Tom Taylor

On Wed, Mar 13, 2013 at 2:17 PM, Mikael Abrahamsson <[email-masked]>wrote:

>  * discussion on the list to reach consensus that SYSLOG and IPFIX should,
>> or should not, send different events because of their different
>> applicability.
>>
>
> logging for this amount of data, and doing the port block allocation is the
> only way to solve this problem. Is it suitable to have this kind of
> ______________________________**_________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/behave<https://www.ietf.org/mailman/listinfo/behave>
>