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

From: Tina TSOU <[email-masked]>
Date: Wed, 01 Sep 2010 15:11:53 +0800

B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Dan Wing" <[email-masked]>
Cc: "'Tina TSOU'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 01, 2010 12:08 AM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

>I may be missing something, but given the variations, it seems a heck of a 
>lot more reliable, and more compliant with rules, for operator NATs to log 
>what information they can, and for server logging to be a separate matter.
> The quesiton of how the NAT writes its logs, and what it writes, depends 
> upon the style of NAT and other implementation details.
> (For full cone NAT, it seems that logs which show source port allocation, 
> with timestamps, are sufficient to meet most regulatory regimes.)
[Tina: Joel, thanks a lot for your comments. What's your specific suggestion 
for this work?]
>
> Yours,
> Joel
>
> Dan Wing wrote:
>>> -----Original Message-----
>>> From: Tina TSOU [mailto:[email-masked]]
>>> Sent: Tuesday, August 31, 2010 2:25 AM
>>> To: [email-masked]; Dan Wing
>>> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
>>> NATs
>>>
>>>
>>> B. R.
>>> Tina
>>> http://tinatsou.weebly.com/index.html
>>> ----- Original Message -----
>>> From: "Dan Wing" <[email-masked]>
>>> To: "'Tina TSOU'" <[email-masked]>; <[email-masked]>
>>> Sent: Monday, August 30, 2010 12:30 PM
>>> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
>>> NATs
>>>
>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Tina TSOU
>>>>> Sent: Saturday, August 28, 2010 2:19 AM
>>>>> To: [email-masked]
>>>>> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale
>>> NATs
>>>>> Hi Behaver,
>>>>> Here is an updated version, thanks to the wonderful review from Med.
>>>>> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01
>>>>>
>>>>> It is a short, straight forward I-D. I would like to hear your
>>> opinion
>>>>> and more comments. What's the next step for it?
>>>> Should the block-allocated source ports be re-used?  If so, can text
>>>> be added to describe advantages / disadvantages of such re-use?
>>> [Tina] Thanks for your thorough review. OK, will add a section to
>>> describe
>>> the advantages/disadvantages
>>>
>>>
>>>
>>> Source port blocks could be reused. When a port block is not used by a
>>> user
>>> for a while, the NAT device could allocate this port block to another
>>> user.
>>>
>>> If a port block is not reusable, there could be two scenarios:
>>>
>>> 1. Statically configure the same number of ports for each user, e.g.
>>> each
>>> can have 2000 ports in this case, there may be a waste of source port
>>> resource, because maybe not all the users would need so many ports;
>>> meanwhile some users may need more ports
>>>
>>> DS-Lite draft has some discussion about port allocation,
>>> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-
>>> 06#section-8.4
>>>
>>>
>>>
>>> 2. Initially, give a user a port block, e.g. a block of 300 ports; when
>>> the
>>> user need more port, give the user another port block, e.g. a block of
>>> 100
>>> ports, and so on
>>>
>>> In this case, a user may need a lot of ports for a while, but later
>>> this
>>> user does not need so many ports, one or more port blocks could be
>>> released.
>>>
>>>
>>>
>>> Compared to the above two cases, if a port block is reusable, I can
>>> increase
>>> the usage of port resource.
>>>
>>>
>>>
>>> However, if the block is not reusable, the implementation could be a
>>> bit
>>> simpler, e.g. timeout for a port block would not be necessary.
>>>
>>>
>>>> Can a NAT operator determine when a server operator is logging the
>>>> source port?
>>> [Tina] No, a NAT operator can not determine that.
>>
>> It is useful to point that out in the I-D.
>>
>>>> What is the impact if a server is not logging the source port?  For
>>>> example, what happens if a subscriber made a post to a web
>>>> server and law enforcement asked the ISP for the identity of the
>>>> subscriber, but the server didn't log the source port?  This seems
>>>> to place the ISP in a difficult situation, requiring the ISP to
>>>> reveal the identity of all subscribers that were using that IP
>>>> address at that time.
>>> [Tina] The impact is that it may not be possible to trace back to a
>>> single
>>> if a server is not logging the source port.
>>
>> Agreed.  It is useful to point that out in the I-D.
>>
>>> A NAT device can log the destination IP address of each session, though
>>> that would not resolve all the problems.
>>>
>>> Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is
>>> quite
>>> possible that some users behind a same NAT would visit a same famous
>>> web
>>> server, like YouTube, at the same time. In such a case, if the server
>>> does
>>> not log the source port and the NAT log the destination IP address, I
>>> can
>>> not trace back to a single user, even if "the ISP to reveal the
>>> identity of
>>> all subscribers that were using that IP address at that time".
>>
>> Agreed.  It is useful to point that out in the I-D.  So, the scenarios 
>> are:
>>
>>  1. IF server logs source port of incoming connections,
>>       THEN the NAT does not need to log destination.  The
>>       server's logs and the NAT's source port logs will be
>>       sufficient to identify the subscriber.
>>
>>  2. IF server does not log source port of incoming connections,
>>       AND the NAT does not log destination
>>       THEN the ISP cannot identify which subscriber made the
>>            connection to the server.  This might mean the
>>            ISP has to disclose the identity of all the subscribers that 
>> were sharing that IP address.
>>
>>   3. If server does not log source port of incoming connections,
>>        AND the NAT does log destination
>>        THEN the ISP can identify the subset of users that were accessing 
>> that server at that time, but
>>             the ISP cannot identify the specific user in
>>             that subset.
>>
>> (And, as we agreed above, it is impossible for the NAT to determine if 
>> the server is logging the source port, so the
>> NAT cannot distinguish between 1 and 2 or between 1 and 3).
>>
>>> Since it is required by regulations (rather than by ISP), the server
>>> should be liable to log the source port.
>>
>> What is "it"?  I guess you are referring to regulatory requirements that
>> servers log ports?  I am aware of some activity with some regulatory 
>> agencies to include source port in their recommended/required logging, 
>> but I also know that those changes are not yet final.
>>
>>> This is discussed in draft-ietf-intarea-shared-addressing-issues-01
>>>
>>> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-
>>> 01#section-11
>>>
>>>
>>>> In an appendix it would be useful to provide configuration examples
>>>> for popular server software to log the source port (e.g., Apache,
>>>> IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP).  For example, I
>>>> believe it was in Apache version 2.1 that added the ability to log
>>>> the source port using "%{remote}p" described at
>>>> http://httpd.apache.org/docs/2.1/mod/mod_log_config.html.
>>>> And be sure to mention that, for all log file modifications, the
>>>> source port needs to be added to the log in a way that will work
>>>> with the server's log analysis scripts.
>>> [Tina] To be honest, I do not know much about all kinds of the server
>>> software, I only do network devices. However I will try to find out
>>> whether/how they could log source port, and if possible I will add an
>>> appendix. I need help from the list for this point.
>>
>> The I-D is explaining the drawbacks of logging destination port and the 
>> I-D is encouraging server operators to log the source port.  It seems
>> useful to point out how easily the server operators can add source port
>> logging.
>>
>> -d
>>
>>
>>>
>>>> -d
>>>>
>>>>
>>>> _______________________________________________
>>>> Behave mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>
>>
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 11:49:09 +0300

Hi,

On 2010-8-28, at 12:18, Tina TSOU wrote:
> It is a short, straight forward I-D. I would like to hear your opinion and more comments. What's the next step for it?

I'm struggling a bit to understand the motivation for this draft. In the introduction, it says:

>   Some high performance NAT devices may need to create a large amount
>   of new sessions per second.  If logs are generated for each mapping
>   entry, the log traffic could reach tens of megabytes per second or
>   more, which would be a problem for log generation, transmission and
>   storage.

Let's run some numbers. How large is a log entry? Let's assume two IPv4 addresses plus two ports numbers, which is 12 bytes, plus a timestamp, which is maybe 4 bytes, plus some random bytes of stuff. Say, in total 32 bytes.

At a rate of     1,000 bindings/sec, that causes  32 KB/sec of log traffic.
At a rate of    10,000 bindings/sec, that causes 320 KB/sec of log traffic.
At a rate of   100,000 bindings/sec, that causes   3 MB/sec of log traffic.
At a rate of 1,000,000 bindings/sec, that causes  32 MB/sec of log traffic.

So we're really only going to his the "tens of megabytes per second" range for CGNs that see a million bindings per second. You'd need an awfully big box to handle this, and a significant amount of IPv4 space to number it.

As for storage, with a million bindings per second and 32 MB/sec of log traffic, you need about 2GB/min, i.e., 2.7 TB/day. And this is without compression - these logs should be highly compressable.

All in all, I'm not fully convinced we have a problem here. Or maybe I'm missing something?

Lars

---

From: <[email-masked]>
Date: Fri, 3 Sep 2010 14:09:58 +0200

Dear Lars, all,

The use of port ranges instead of assigning individual port in CGNs has several effects, not only optimising the logs:

(1) The performance of the device are not impacted due to the writing operation (of each individual binding). For some implementations, we have seen a severe degradation when the device (in our case, it is a CGN DS-Lite) must log each individual entry. Note that, we have seen some implementations which loss packets when the port range bindings are not yet in place. But, I guess this is implementation-specific. 

(2) The amount of new sessions to be handled per second are drastically enhanced when a port range scheme is used instead of individual port assignment.
 
(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.

(4) The drawback of assigning port ranges in the CGN is that the destination address is not kept by the device. This may not be convenient in early stages of deployment of shared IP mechanisms in SPs domains. Indeed: 

(a) If a high address sharing ratio (e.g., 1:1000) is used, to avoid revealing the identity of all subscribers sharing the same address to answer to an abuse complaint by the authorities, we may rely on the destination address as an indicator to identify a/the concerned customer. In the meantime, we need to encourage servers to log the source port number in addition to the destination IP address. 
(b) If a small address sharing ratio (e.g., 1:5) is used, storing the destination address in the CGN may not be useful. 

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lars Eggert
Envoyé : vendredi 3 septembre 2010 10:49
À : Tina TSOU
Cc : [email-masked]
Objet : Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hi,

Lars
*********************************
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.
********************************

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Sep 2010 15:28:27 +0300

Hi,

> (1) The performance of the device are not impacted due to the writing operation (of each individual binding). For some implementations, we have seen a severe degradation when the device (in our cas…

right, I wouldn't diagnose a fundamental issue with the technology based on one implementation that has issues.

> (2) The amount of new sessions to be handled per second are drastically enhanced when a port range scheme is used instead of individual port assignment.

You still need to install or at least update a binding for each connection, in order to keep track of which external ports in the range are in use or available, and keep track of which internal port maps to which external port.

> (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).…

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.

Lars

---

From: <[email-masked]>
Date: Fri, 3 Sep 2010 14:34:13 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Lars Eggert [mailto:[email-masked]] 
Envoyé : vendredi 3 septembre 2010 14:28
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Tina TSOU; [email-masked]
Objet : Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hi,

Med: Yes, but you don't need to log it and this why the performance are enhanced.

Med: When the factor is 1000, then optimisation can not be seen as a luxe.

Lars

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Sep 2010 09:59:52 -0400

Control over log generation and log volume is an implementation issue. 
(Compression, buffering, and suitable allocation strategies are all well 
known local implementation techniques for improving the behavior.)
Arguably a very important implementation issue.  But different NATs with 
different strategies will all interoperate with the end users and the 
content.

Unless we want to standardize the log content (we usually don't.  I hope 
we don't want to get into that), I would agree with Lars that there does 
not seem to be a problem for the IETF to solve here.

Yours,
Joel

Lars Eggert wrote:
> ------------------------------------------------------------------------
>

---

From: Tina TSOU <[email-masked]>
Date: Sat, 04 Sep 2010 20:35:15 +0800

Dear Joel and Lars,
You are right. I completely understand your original intention.
My answer is in line with the other two emails sent by Med.
http://www.ietf.org/mail-archive/web/behave/current/msg08803.html

B. R.
Tina

On Sep 3, 2010, at 9:59 PM, Joel M. Halpern wrote:

> Control over log generation and log volume is an implementation  
> issue. (Compression, buffering, and suitable allocation strategies  
> are all well known local implementation techniques for improving the  
> behavior.)
> Arguably a very important implementation issue.  But different NATs  
> with different strategies will all interoperate with the end users  
> and the content.
>
> Unless we want to standardize the log content (we usually don't.  I  
> hope we don't want to get into that), I would agree with Lars that  
> there does not seem to be a problem for the IETF to solve here.
>
> Yours,
> Joel
>
> Lars Eggert wrote:
>> Hi,
>>> opinion and more comments. What's the next step for it?
>> Let's run some numbers. How large is a log entry? Let's assume two  
>> IPv4 addresses plus two ports numbers, which is 12 bytes, plus a  
>> timestamp, which is maybe 4 bytes, plus some random bytes of stuff.  
>> Say, in total 32 bytes.
>> So we're really only going to his the "tens of megabytes per  
>> second" range for CGNs that see a million bindings per second.  
>> You'd need an awfully big box to handle this, and a significant  
>> amount of IPv4 space to number it.
>> As for storage, with a million bindings per second and 32 MB/sec of  
>> log traffic, you need about 2GB/min, i.e., 2.7 TB/day. And this is  
>> without compression - these logs should be highly compressable.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 4 Sep 2010 19:57:48 +0000

Tina,

As Joel and Lars point out, the port management that you describe affects how NAT are built, and then how they are operated. There are clearly multiple ways to manage the allocation of port numbers in NAT, and multiple ways to organize the log. These are implementation issues. The IETF only deals with implementation issues when they affect interoperation. The particular port management that you describe does not affect interoperation. Neither clients nor servers need to be aware of it. It is thus not something that the IETF should standardize.

The implementation issues that you describe are interesting and worth publishing, but scientific conferences or journals seem like a better venue. For example, ACM's Computer Communication Review regularly publishes work of this nature.

-- Christian Huitema

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Saturday, September 04, 2010 5:35 AM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Dear Joel and Lars,

B. R.

Control over log generation and log volume is an implementation issue. (Compression, buffering, and suitable allocation strategies are all well known local implementation techniques for improving the behavior.)
Arguably a very important i mplement fferent NATs with different strategies will all interoperate with the end users and the content.

Unless we want to standardize the log content (we usually don't.  I hope we don't want to get into that), I would agree with Lars that there does not seem to be a problem for the IETF to solve here.

Yours,
Joel

Lars Eggert wrote:

Hi,

Let's run some numbers. How large is a log entry? Let's assume two IPv4 addresses plus two ports numbers, which is 12 bytes, plus a timestamp, which is maybe 4 byt es, plus ff. Say, in total 32 bytes.
As for storage, with a million bindings per second and 32 MB/sec of log traffic, you need about 2GB/min, i.e., 2.7 TB/day. And thi s is wit logs should be highly compressable.
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: Olivier Vautrin <[email-masked]>
Date: Sat, 4 Sep 2010 23:41:01 -0700

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.
>

---

From: <[email-masked]>
Date: Mon, 6 Sep 2010 07:22:10 +0200

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:[email-masked]] 
Envoyé : dimanche 5 septembre 2010 08:41
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Lars Eggert
Cc : [email-masked]; Tina TSOU
Objet : RE: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hello Med,

Regards,
Olivier.

---

From: Xing Li <[email-masked]>
Date: Fri, 10 Sep 2010 22:02:57 +0800

> (b) If a small address sharing ratio (e.g., 1:5) is used, storing the destination address in the CGN may not be useful. 

+1.

xing

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Sep 2010 16:47:01 +0200

Hi Med,

+1, provided it applies more generally, i.e. to "port sets", instead of just "port ranges".
(draft-despres-softwire-sam-01 sec 2.1, describes a solution where port sets derived from extended IPv4 addresses are more optimized if comprising up to 4 continuous port ranges.)

Thoughts?

Cheers,
RD
    
Le 10 sept. 2010 à 16:02, Xing Li a écrit :

>> (a) If a high address sharing ratio (e.g., 1:1000) is used, to avoid revealing the identity of all subscribers sharing the same address to answer to an abuse complaint by the authorities, we may rely on the destination address as an indicator to identify a/the concerned customer. In the meantime, we need to encourage servers to log the source port number in addition to the destination IP address. (b) If a small address sharing ratio (e.g., 1:5) is used, storing the destination address in the CGN may not be useful. 
>> 
>>  
> 
> +1.
> 
> xing

+1, provided it applies more generally to "port sets", instead of just port"ranges".
(draft-despres-softwire-sam-01 sec 2.1, deriving a solution where port sets derived from extended IPv4 addresses are more optimized if comprising up to 4 continuous port ranges.    
>> 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.

---

From: Jacni Qin <[email-masked]>
Date: Wed, 15 Sep 2010 00:22:05 +0800

On Mon, Sep 6, 2010 at 1:22 PM, <[email-masked]>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 ;-)

> 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

> 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.
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 14 Sep 2010 19:38:30 -0700

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jacni Qin
Sent: Tuesday, September 14, 2010 12:22 PM
To: [email-masked]
Cc: [email-masked]; 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, <[email-masked]> wrote:

	Dear Olivier, all,

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  

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-----

	Hello Med,

	
	Regards,
	Olivier.