Hello,

Right now I'm testing interoperability between PCEP implementation in Nokia 7750 SR routers and ODL.

Software versions:
7750 SR: TimOS 16.0.R6
ODL: Fluorine SR2

Java:
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

7750 SR configured as PCC, ODL is configured as PCE.

Looks like I'm observing quite serious issues from the very beginning.

1. PCRpt messages processing. When 7750 reporting some new LSP (PCC initiated, PCC controlled) ODL can process PCRpt messages and add corresponding LSPs to LSP-DB, but in any case it will throw a bunch of PCErr messages in return. All PCerr are the same - "LSP Object missing". And of course this object is actually present (ODL can't parse it correctly ?). I made capture of traffic exchange between PCC and PCEP (starting from PCEP session establishment) to illustrate this issue. Logs from PCE side are present as well. There are two files attached - 190321_pcrpt.pcap, 190321_pcrpt_odl.log

2. PCReq messages from 7750 can't be parsed at all by ODL. All I can get is "Failed to decode protocol message" in ODL logs. Again I made capture of traffic exchange between PCC and PCE and collected logs from ODL side. There are two files attached - 190321_pcreq.pcap, 190321_pcreq_odl.log

Maybe somebody can look in my pcaps/logs and give me some advices ? I'm already in touch with TimOS developers but any comments from ODL community are appreciated. Maybe some bugfixes are needed in ODL as well ?

--
/me from somewhere

   The definition of the PCReq message from [RFC5440] is extended to

   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

https://lists.opendaylight.org/pipermail/bgpcep-dev/2015-April/000212.html

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier

Hi Ajay,

Thank you very much for an answer. 

I’m a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp

and there is the following statement here:

https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#page-29

   The definition of the PCReq message from [RFC5440] is extended to

   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

https://lists.opendaylight.org/pipermail/bgpcep-dev/2015-April/000212.html

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 

>> The default ODL application, pcep-topology-provider, supports only 
>> active stateful PCE mode of operation and does not include support 

>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won’t be able to respond to PCReq’s anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected

 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards

Ajay

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Hi Andrey,

And for the second problem with the PCRpt message, LSPA/BANDWIDTH/METRICS could be associated with the ERO Object only. Not with RRO.

I already made some tests with Juniper and Cisco router where these objects are announced with ERO and correctly parse & handle by ODL.

Regards

Olivier

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier

Le 03/04/2019 à 01:18, Andrey Elperin a écrit :

Hi Ajay,

Thank you very much for an answer. 

I’m a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp

and there is the following statement here:

https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#page-29

   The definition of the PCReq message from [RFC5440] is extended to

   optionally include the LSP object after the END-POINTS object.

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

https://lists.opendaylight.org/pipermail/bgpcep-dev/2015-April/000212.html

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 

>> The default ODL application, pcep-topology-provider, supports only 
>> active stateful PCE mode of operation and does not include support 

>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won’t be able to respond to PCReq’s anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected

 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

Regards

Ajay

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Hi Olivier,

It's a very good news that you already have a working full implementation of RFC5440. If I can somehow help you with testing of this code in our environment (we have a plenty of Nokia and Huawei routers) - I'll be glad to help.

_Passive_ stateful PCE (RSVP-TE) using BGP-LS - it's the first setup I'm trying to test. Looks like that absence of path computation in current ODL release is the main showstopper for this test.

olivier.dugeon@... писал 03.04.2019 14:07:

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier

Le 03/04/2019 à 01:18, Andrey Elperin a écrit :

Hi Ajay,

 

Thank you very much for an answer. 

 

I'm a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp

and there is the following statement here:

 

https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#page-29

 

   The definition of the PCReq message from [RFC5440] is extended to

   optionally include the LSP object after the END-POINTS object.

 

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

https://lists.opendaylight.org/pipermail/bgpcep-dev/2015-April/000212.html

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 

>> The default ODL application, pcep-topology-provider, supports only 
>> active stateful PCE mode of operation and does not include support 

>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won't be able to respond to PCReq's anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

 

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

 

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected

 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

 

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

 

Regards

Ajay

 

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Hi Olivier,

Yes, I already figured out root cause of this problem. By default SR OS PCEP implementation is configured with "report-path-constraints" knob, which means:

---------------------------------------------

This command enables the inclusion of LSP path constraints in the PCE report messages sent from the PCC to a PCE.

In order for the PCE to know about the original constraints for an LSP that is delegated but for which there is no prior state in its LSP database; for example, if no PCReq message was sent for the same PLSP-ID, the following proprietary behavior is observed:

---------------------------------------------

When this proprietary behaviour is disabled - ODL can pasre PCRtp messages from SR OS without any errors.

olivier.dugeon@... писал 03.04.2019 14:31:

Hi Andrey,

And for the second problem with the PCRpt message, LSPA/BANDWIDTH/METRICS could be associated with the ERO Object only. Not with RRO.

I already made some tests with Juniper and Cisco router where these objects are announced with ERO and correctly parse & handle by ODL.

Regards

Olivier

Le 03/04/2019 à 13:07, Olivier Dugeon a écrit :

Hello Andrey,

Your PCReq message is correctly formatted as per RFC8231. However, LSP Object has been introduced in RFC8231 and added to the PCReq grammar while ODL support only PCReq from RFC5440 which define only LSPA Object. Thus, you got an error from ODL while your message is correct.

In addition, if PCReq messages are parsed by ODL there are not properly handle. What you get is only a message in the log telling that a PCReq message has been received but flag as "unsupported message". And you do not receive any answer which is not conform to RFC5440. At least you must get a PCRep message with a NO-PATH Object or a PCErr message.

BTW, we develop a full implementation of RFC5440 & RFC5441 for ODL. PCReq messages are handle and if you use BGP-LS our code is able to compute path. We are currently under code review process before submitting our patch. We have already open a JIRA ticket for that: https://jira.opendaylight.org/browse/BGPCEP-858 . From what you experienced with your test, I understand that we must also update the PCReq message parser in order to support LSP Object as per RFC8231 in complement to RFC5440 Objects.

Regards

Olivier

Le 03/04/2019 à 01:18, Andrey Elperin a écrit :

Hi Ajay,

 

Thank you very much for an answer. 

 

I'm a bit surprised about expected PCReq format. According to the docs, ODL PCEP plugin supports draft-ietf-pce-pce-initiated-lsp

and there is the following statement here:

 

https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#page-29

 

   The definition of the PCReq message from [RFC5440] is extended to

   optionally include the LSP object after the END-POINTS object.

 

Is it not implemented in parser ?

In the meanwhile I did some additional searches in bgpcep-dev archives and found this topic:

https://lists.opendaylight.org/pipermail/bgpcep-dev/2015-April/000212.html

with the following statement:

>> The protocol implementation, pcep-impl, does fully support RFC5440. 

>> The default ODL application, pcep-topology-provider, supports only 
>> active stateful PCE mode of operation and does not include support 

>> for PCC-initiated path computation.

Is it still true for the latest PCEP plugin version ? If yes - I can assume that ODL won't be able to respond to PCReq's anyway.

--
/me from somewhere

1 квіт. 2019 р. о 22:53 Ajay Lele <ajayslele@...> написав(ла):

Hi Andrey

 

Problem appears to be happening because message from device has some objects which are not expected there

On Fri, Mar 22, 2019 at 2:45 AM Andrey Elperin <mizzy@...> wrote:

  Hello,

  Right now I'm testing interoperability between PCEP implementation in 
Nokia 7750 SR routers and ODL.

  Software versions:
  7750 SR: TimOS 16.0.R6
  ODL: Fluorine SR2

  Java:
  openjdk version "1.8.0_181"
  OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
  OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  7750 SR configured as PCC, ODL is configured as PCE.

  Looks like I'm observing quite serious issues from the very beginning.

  1. PCRpt messages processing. When 7750 reporting some new LSP (PCC 
initiated, PCC controlled) ODL can process PCRpt messages and add 
corresponding LSPs to LSP-DB, but in any case it will throw a bunch of 
PCErr messages in return. All PCerr are the same - "LSP Object missing". 
And of course this object is actually present (ODL can't parse it 
correctly ?). I made capture of traffic exchange between PCC and PCEP 
(starting from PCEP session establishment) to illustrate this issue. 
Logs from PCE side are present as well. There are two files attached - 
190321_pcrpt.pcap, 190321_pcrpt_odl.log

 

Expected format for PCRpt is here: https://tools.ietf.org/html/rfc8231#page-25. Message in attached pcap has LSPA/BANDWIDTH/METRIC objects after RRO object which is not expected

 

  2. PCReq messages from 7750 can't be parsed at all by ODL. All I can 
get is "Failed to decode protocol message" in ODL logs. Again I made 
capture of traffic exchange between PCC and PCE and collected logs from 
ODL side. There are two files attached - 190321_pcreq.pcap, 
190321_pcreq_odl.log

 

Expected format for PCReq is here: https://tools.ietf.org/html/rfc5440#page-19. Message in attached pcap has LSP object after END-POINTS object which is not expected there 

 

Regards

Ajay

 

  Maybe somebody can look in my pcaps/logs and give me some advices ? I'm 
already in touch with TimOS developers but any comments from ODL 
community are appreciated. Maybe some bugfixes are needed in ODL as well 
?

-- 
/me from somewhere_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_______________________________________________
bgpcep-users mailing list
bgpcep-users@...
https://lists.opendaylight.org/mailman/listinfo/bgpcep-users

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.