Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

________________________________

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Jacni Qin
Sent: Tuesday, September 14, 2010 12:22 PM
To: mohamed.boucadair@orange-ftgroup.com
Cc: behave@ietf.org; Olivier Vautrin; Tina TSOU
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

On Mon, Sep 6, 2010 at 1:22 PM, <mohamed.boucadair@orange-ftgroup.com> wrote:

	Dear Olivier, all,

	Compression is needed whatever the scheme adopted for the port assignment, especially to reduce the amount of exchanges between the mediation platform (responsible for collecting legal storage data from several location in the network) and the CGN device.

	BTW, I agree with Joel's position: The way logs are built does not need to be standardised and this is implementation-specific.

Agree with this point. We can not unify the format and operation of logging on the NAT box, we also don't know what the log analyser(a throng of servers) will do ;-)

[Senthil] There is value in unifying and expecting a consistent behavior - because the collectors/analyzers would need to know what to expect. I have worked with the IPFIX
 wg in the past to get some of the IEs defined in IPFIX registry for NAT. 

http://www.iana.org/assignments/ipfix/ipfix.xhtml
http://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt

I have written a new I-D to define the templates of different logging events.
http://www.ietf.org/id/draft-sivakumar-behave-nat-logging-00.txt

Senthil  

	The interest I see in draft-tsou is it documents a way for optimisation (which is already supported by various vendors) and encourages the servers to store the source port information. This second point can be encouraged further if (as already suggested by Dan Wing) it has shown that the integration of the source port number is an easy task to handle by servers and this modification has no (or minor) impact on existing tools used to manipulate logs stored by the servers.

Yes, if the source addresses with timestamp are recorded on the server side, the storage needed for logs around NAT can be vastly reduced.

Regards,
Jacni

	Cheers,
	Med

	-----Message d'origine-----

	De : Olivier Vautrin [mailto:ovautrin@juniper.net]
	Envoyé : dimanche 5 septembre 2010 08:41
	À : BOUCADAIR Mohamed NCPI/NAD/TIP; Lars Eggert
	Cc : behave@ietf.org; Tina TSOU
	Objet : RE: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

	Hello Med,

	Does that mean you don't expect providers to Compress/Optimize the logs information sent per CGN device at all?

	In my understanding, this proposition will have an effect on the storage of log files only if the logs are kept *as is*. This is because the ports are randomly choosen in draft-tsou-behave-natx4-log-reduction-01, range are not created with contiguous ports so the amount of information sent by the CGN is not decreasing only the syslog message has changed.

	Regards,
	Olivier.

	> > (3) As an aside effect, when port ranges are used the size of the log
	> file is optimised (FWIW, see http://tools.ietf.org/html/draft-
	> boucadair-port-range-02#section-15.2 for a simplified exercise). Of
	> course this optimisation depends on length of the port range.
	>
	> I understand that ranges shorten the log file. The point I was trying
	> to make is that even on very large CGNs (large enough so that they'd
	> need an insane amount of bandwidth to forward all the traffic they're
	> seeing), the log sizes are not unmanageable. Sure, they can always be
	> reduced, but that's an optional optimization.
	>
	> Med: When the factor is 1000, then optimisation can not be seen as a
	> luxe.

	*********************************
	This message and any attachments (the "message") are confidential and intended solely for the addressees.
	Any unauthorised use or dissemination is prohibited.
	Messages are susceptible to alteration.
	France Telecom Group shall not be liable for the message if altered, changed or falsified.
	If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
	********************************

	_______________________________________________
	Behave mailing list
	Behave@ietf.org
	https://www.ietf.org/mailman/listinfo/behave