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

[<[e-mail]>]

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. 

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.

Cheers,
Med
 

-----Message d'origine-----
De : Olivier Vautrin [mailto:[e-mail]] 
Envoyé : dimanche 5 septembre 2010 08:41
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Lars Eggert
Cc : [e-mail]; 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.
********************************