[mpls] Re: Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Xiao,

Thank you for preparing this update. I like the design as we get rid of the conditional encoding. I will update my ballot right now.

There is one minor nit, though. Feel free to make the change if you want. All the figures will be impacted.

OLD:
Reserved (length: 3 octets)

  *   The Reserved field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

NEW:
Unassigned (length: 3 octets)

  *   The Unassigned field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

This is to be consistent with RFC8126:

      Unassigned:  Not currently assigned, and available for assignment
            via documented procedures.  While it's generally clear that
            any values that are not registered are unassigned and
            available for assignment, it is sometimes useful to
            explicitly specify that situation.  Note that this is
            distinctly different from "Reserved".

      Reserved:  Not assigned and not available for assignment.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            Reserved values are held for special uses, such as to extend
            the namespace when it becomes exhausted.  "Reserved" is also
            sometimes used to designate values that had been assigned
            but are no longer in use, keeping them set aside as long as
            other unassigned values are available.  Note that this is
            distinctly different from "Unassigned".

Thank you for all your effort.

Cheers,
Med

De : [e-mail] <[e-mail]>
Envoyé : vendredi 6 juin 2025 11:33
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)



Hi Med,



I've posted version -13 attempting to address all your comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-13

This version incorporates the resolution agreed with the WG on the approach selection for v4/v6 demux.



Cheers,

Xiao Min
Original
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
To: 肖敏10093570;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月23日 17:14
Subject: RE: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)
Hi Xiao,

Thank you for accommodating and for your patience with us. Much appreciated.

As discussed with Jim, I will be holding my DISCUSS till we close the demux pending point. Please poke me when a resolution is agreed with the WG and I will clear.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 23 mai 2025 10:51
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)



Hi Med,



I've posted the -09 version attempting to address your comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-09

This version also incorporates resolution to comments received from Ketan, Eric, Gunter, and Mahesh.

The one remaining issue is about the approach selection for v4/v6 demux.

Cheers,

Xiao Min
Original
From: 肖敏10093570
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月22日 17:22
Subject: Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)

Got it. I'll apply that fix in the next revision.

Thank you Med!



Cheers,

Xiao Min


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
To: 肖敏10093570;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月22日 17:01
Subject: RE: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)
Hi Xiao,

Thank you for action and update on the encoding part.

For the multi-tlv validation, a simple fix would be to only reflect what will be observed with the rules in place. For example, you may replace the text with multiple TLVs with a new text such as:

NEW:
These three new Target FEC Stack sub-TLVs are not expected
to be present in the same message. If more than one of these
sub-TLV is presented in a message, only the first sub-TLV
will be processed per the validation rules in Section 4.

If the WG want a stronger check, then I’m afraid a major change will be needed to the validation procedure.

Hope this helps.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 22 mai 2025 04:13
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)



Hi Med,



Thank you for the reply.

Please see inline with [XM-3]>>>.
Original
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
To: 肖敏10093570;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月21日 22:31
Subject: RE: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)
Hi Xiao,

Thanks for the follow-up and for the new version.

(1) Ketan has a point about the AF demux design. I think that we can get rid of conditional encoding by assigning a type per AF. It seems we do have plenty type space for this.

Unless this is already done, please consult with the WG which approach is better here.
[XM-3]>>> Got it. I've sent an email to the MPLS WG on this topic (https://mailarchive.ietf.org/arch/msg/mpls/udR6xlDyd5hB7Qem5je_lweODF4/)

(2) ## Presence of several TLVs

CURRENT:
   Note that the three new Target
   FEC Stack sub-TLVs are mutual exclusive and they wouldn't be present
   in one message simultaneously.

How is this reflected in the validation procedure in Section 4?

[XM]>>> I believe you raise a question more related to the base LSP Ping protocol, that's

how the responder behaves if it received more Target FEC Stack sub-TLVs than expected.

If I understand it correctly, in this case the responder would only validate the first sub-TLV

and ignore the following ones.

[Med] I failed to find any relevant part in these RFCs. Maybe I was looking in the wrong place. If you have a pointer where this covered, please share it. Otherwise, I think that we need to cover it here as part of the validation.

[XM-2]>>> Let me give you an example to explain how I think it works.

If the responder received a Target FEC Stack TLV carrying the three new sub-TLVs defined in this document, then according to the validation procedures defined in Section 4 (which follows RFCs 8029 and 8287), the first sub-TLV will be checked against the received PSID firstly. If the first sub-TLV is TBD2 (SR Candidate Path's PSID sub-TLV), then the following procedures apply:

Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-

      TLV at FEC-stack-depth is TBD2 (SR Candidate Path's PSID sub-TLV),

      {



      -  Set the Best-return-code to 10, "Mapping for this FEC is not

         the given label at stack-depth <RSC>" if any below conditions

         fail:



         o  Validate that the PSID is signaled or provisioned for the SR

            Candidate Path {



            +  Validate that the signaled or provisioned headend, color,

               endpoint, originator, and discriminator, for the PSID,

               matches with the corresponding fields in the received SR

               Candidate Path's PSID sub-TLV.



            }



         }



      -  If all the above validations have passed, set the return code

         to 3 "Replying router is an egress for the FEC at stack-depth

         <RSC>".



      -  Set FEC-Status to 1 and return.



      }

The last step is "Set FEC-Status to 1 and return", as I understand it, the second and third sub-TLVs won't be processed any more.

[Med] I trust your interpretation but this means that the TLV won’t be processed but this does not lead to validation error. Did I missed something?

[XM-3]>>> I think your understanding is correct. One more thing, while reviewing the procedures I found there is a copy/paste mistake that "if the Label-stack-depth is 0..." should be "if the Label-stack-depth is 1...", because the PSID label must reach the responder as the bottom label when used for LSP Ping. I'll fix that in the next revision.



Cheers,

Xiao Min


Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 19 mai 2025 17:06
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)



Hi Med,



I've posted a new -08 revision attempting to address your comments. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-08

Please see inline for responses with [XM-2]>>>.
Original
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
To: 肖敏10093570;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月16日 19:32
Subject: RE: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)
Hi Xiao,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 14 mai 2025 09:22
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)



Hi Med,



Thanks for your insightful review and comments.

Please see inline.
Original
From: MohamedBoucadairviaDatatracker <[e-mail]<mailto:[e-mail]>>
To: The IESG <[e-mail]<mailto:[e-mail]>>;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
Date: 2025年05月13日 22:47
Subject: [mpls] Mohamed Boucadair's Discuss on draft-ietf-mpls-spring-lsp-ping-path-sid-07: (with DISCUSS and COMMENT)
Mohamed Boucadair has entered the following ballot position for
draft-ietf-mpls-spring-lsp-ping-path-sid-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping-path-sid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Xiao, Shaofu, Liyan, Rakesh, and Carlos,

Thanks for the effort put into this document.

Thanks to Bing Liu for the OPSDIR and for the authors for engaging and
releasing a new version. I do agree with Bing that the changes are really
minimal. I do think the same concern still apply for this version and some more
context/background/intended use is worth be included in the specification. I do
understand that the specification extends RFC8287, which itself is based on
RFC8029 so we don’t need to repeat all these details but a minimum is needed to
help those who will make use of this extensions.

[XM]>>> OK. Propose to add some more text into the Introduction as below.

OLD

Procedures for LSP Ping

   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to

   PSID as well, which can be used to check correct operation of the

   PSID and to verify the PSID against the control plane.  Note that LSP

   Traceroute [RFC8287] is left out of this document because the transit

   node is not involved in PSID processing.

NEW

Procedures for LSP Ping

   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to

   PSID as well, which can be used to check correct operation of the

   PSID and to verify the PSID against the control plane.  Among them,
checking correct operation of the PSID means that the initiator can use
LSP Ping to check whether the PSID reached the responder and got processed
by the responder correctly; verifying the PSID against the control plane
means that the initiator can use LSP Ping to verify whether the responder
has the same understanding with the initiator on how the PSID was constructed
by the control plane. Note that LSP Traceroute [RFC8287] is left out of this
document because the transit node is not involved in PSID processing.

[Med] Thanks. Please find a proposal below:



OLD :

   This document provides Target Forwarding Equivalence Class (FEC)
   Stack TLV and sub-TLV definitions for PSID.  Procedures for LSP Ping
   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to
   PSID as well, which can be used to check correct operation of the
   PSID and to verify the PSID against the control plane.  Note that LSP
   Traceroute [RFC8287] is left out of this document because the transit
   node is not involved in PSID processing.

NEW:

   Procedures for LSP Ping

   [RFC8029] as defined in [RFC8287] and [RFC8690] are also applicable to

   PSID. Concretely, LSP Ping can be used to check the correct operation of a

   PSID and verify the PSID against the control plane. Checking correct operation means that

   an initiator can use LSP Ping to check whether a PSID reached the intended node and got processed
   by that node correctly. Moreover, verifying a PSID against the control plane
   means that the initiator can use LSP Ping to verify whether a given node has the same understanding with the initiator on how the PSID was constructed
   by the control plane. To that aim, this document specifies new Target Forwarding Equivalence Class (FEC)

   Stack TLV and sub-TLVs for such PSID checks.



   LSP Traceroute [RFC8287] is left out of this
   document because transit nodes are not involved in PSID processing.

[XM-2]>>> Thank you! Your text looks better, and I've used it with a little tweak. I modified the Abstract accordingly.

[Med] Thanks.
# DISCUSS

## Demux v4/v6

Other than that, I have an additional DISCUSS point about the procedure to
demux IPv4 vs IPv6 TLVs. I suspect that we may rely on the length (although
this is not said explicitly), but I’m afraid this may not be reliable. For
example, a truncated TLV (for whatsoever reason) with an IPv6 address to 44
octets might be interpreted as valid TLV with IPv4. BTW, not sure if mixed
forms are allowed (they shouldn’t) such as having a head as an IPv4-mapped IPv6
address and the endpoint as an IPv4 address?

Any reason why an explicit approach is not followed here (similar to the “Adj.
Type” used in the IGP-Adjacency Segment ID in RFC8287) to indicate the address
family of a TLV?

Can we please clarify this in the specification?

[XM]>>> Thank you for raising this point. I noticed RFC 8287 uses "Adj. Type" and

RFC 9703 uses "Adj type" to differentiate between IPv4 and IPv6, and I was looking for

a concrete reason to make that change. I believe now you give me a concrete reason and

so I'm happy to make that change following RFC 8287 and 9703 in the next revision.

[Med] Great. Thanks



For

the question on if mixed forms are allowed, I agree with you that the answer is no.

[Med] Thanks. This is not an issue anymore if you add the explicit AF field.
## Presence of several TLVs

CURRENT:
   Note that the three new Target
   FEC Stack sub-TLVs are mutual exclusive and they wouldn't be present
   in one message simultaneously.

How is this reflected in the validation procedure in Section 4?

[XM]>>> I believe you raise a question more related to the base LSP Ping protocol, that's

how the responder behaves if it received more Target FEC Stack sub-TLVs than expected.

If I understand it correctly, in this case the responder would only validate the first sub-TLV

and ignore the following ones.

[Med] I failed to find any relevant part in these RFCs. Maybe I was looking in the wrong place. If you have a pointer where this covered, please share it. Otherwise, I think that we need to cover it here as part of the validation.

[XM-2]>>> Let me give you an example to explain how I think it works.

If the responder received a Target FEC Stack TLV carrying the three new sub-TLVs defined in this document, then according to the validation procedures defined in Section 4 (which follows RFCs 8029 and 8287), the first sub-TLV will be checked against the received PSID firstly. If the first sub-TLV is TBD2 (SR Candidate Path's PSID sub-TLV), then the following procedures apply:

Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-

      TLV at FEC-stack-depth is TBD2 (SR Candidate Path's PSID sub-TLV),

      {



      -  Set the Best-return-code to 10, "Mapping for this FEC is not

         the given label at stack-depth <RSC>" if any below conditions

         fail:



         o  Validate that the PSID is signaled or provisioned for the SR

            Candidate Path {



            +  Validate that the signaled or provisioned headend, color,

               endpoint, originator, and discriminator, for the PSID,

               matches with the corresponding fields in the received SR

               Candidate Path's PSID sub-TLV.



            }



         }



      -  If all the above validations have passed, set the return code

         to 3 "Replying router is an egress for the FEC at stack-depth

         <RSC>".



      -  Set FEC-Status to 1 and return.



      }

The last step is "Set FEC-Status to 1 and return", as I understand it, the second and third sub-TLVs won't be processed any more.

[Med] I trust your interpretation but this means that the TLV won’t be processed but this does not lead to validation error.


BTW, you may reword as follows:

NEW1:
   These three new Target
   FEC Stack sub-TLVs are mutually exclusive (i.e., they must not be present
   in the same message).

[XM]>>> OK. I'll use this one in the next rev.

[Med] Thanks.


Or simply

NEW2:
   These three new Target
   FEC Stack sub-TLVs are mutually exclusive.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Section 3.1

CURRENT
      This field is set to the length of the sub-TLV's Value field in

I think I understand what is meant here but there is formally no such field in
the figure. Better to refer to the fields used in the Figure.

[XM]>>> Suggest to change it as below.

NEW

      This field is set to the length of the sub-TLV in octets, not including the first 4 octets.

[Med] OK, thanks.
# Figure 2/Figure 3

CURRENT:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Endpoint  (4/16 octets)                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol-Origin|                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

…

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol-Origin|                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

“Reserved” Field is not provided in the description. Consider adding:

NEW:
   Reserved

      The Reserved field MUST be set to 0 when sent and MUST be ignored
      on receipt.

[XM]>>> OK.

[Med] ACK.


# Section 3.2

CURRENT:
      The same as defined in Section 2.3 of [RFC9256].  The value of
      this field follows the IANA registry requested in Section 8.4 of
      [I-D.ietf-idr-bgp-ls-sr-policy].

What is the expected behavior when unregistered values are used?

[XM]>>> If unregistered values are used, the validation at the responder would fail.

[Med] Can we say this in the doc please?

[XM-2]>>> Yes, I added it.



Cheers,

Xiao Min


BTW, may consider rewording as follows:

NEW:
      The same as defined in Section 2.3 of [RFC9256]. This field takes
      a value from the IANA registry defined in Section 8.4 of
      [I-D.ietf-idr-bgp-ls-sr-policy].

[XM]>>> OK.

[Med] Thanks.


# Section 6

OLD:
     Sub-Type   Sub-TLV Name                Reference
     --------   -------------------------   ------------
      TBD1      SR Policy's PSID            Section 3.1
      TBD2      SR Candidate Path's PSID    Section 3.2
      TBD3      SR Segment List's PSID      Section 3.3

NEW:
     Sub-Type   Sub-TLV Name                Reference
     --------   -------------------------   ------------
      TBD1      SR Policy's PSID            Section 3.1 of THIS_DOCUMENT
      TBD2      SR Candidate Path's PSID    Section 3.2 of THIS_DOCUMENT
      TBD3      SR Segment List's PSID      Section 3.3 of THIS_DOCUMENT

As this will be in a public registry.

[XM]>>> OK.

[Med] Thanks.

Thank you again for the thorough review!



Cheers,

Xiao Min


Cheers
Med



_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



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



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



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



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


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