Re: [spring] draft-ietf-spring-mpls-path-segment

[[e-mail]]

Hi Cheng,

Latest version looks good to me. Thanks.
Let’s wait till end of next week for Stewart’s feedback. Otherwise ball is in Jim’s court.

Thanks
--Bruno



Orange Restricted
From: Cheng Li <[e-mail]>
Sent: Thursday, September 21, 2023 4:38 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: Weiqiang Cheng <[e-mail]>; Xipengxiao <[e-mail]>; [e-mail]; James Guichard <[e-mail]>; Stewart Bryant <[e-mail]>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your review comments.  According to your comments, we have


l  updated the draft to add all the required info of implementations from 5 vendors.

l  added  info of an interop-test among at least 5 vendors in 2018.

l  Fixed some nits of typo.

Please review the update [1] to see if it is OK for you or not.

In the end, sorry for mis-sending our private thread to the mailing list before getting confirmation from you. I have read several times of RFC1885, and find out it is very useful. Thank you for your help.

Respect,
Cheng

[1]. https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-mpls-path-segment-12&url2=draft-ietf-spring-mpls-path-segment-14&difftype=--html




From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 14, 2023 12:14 PM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: Weiqiang Cheng <[e-mail]<mailto:[e-mail]>>; Xipengxiao <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; James Guichard <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thank you for uploading the document.

Please find below some comment regarding the Implementation Section,

I would not say that the current section complies with the SPRING WG policy https://wiki.ietf.org/en/group/spring/WG_Policies  in particular for the below points:

-       bullet “1)” in the wiki [1].( i.e. indicate that all MUST & SHOULD are implemented). That should probably be easy with 0 SHOULD and 3 obvious MUST.

-       “We are asking that all items identified in section 2 of RFC 7942<https://datatracker.ietf.org/doc/rfc7942/> be included.”

[1] https://wiki.ietf.org/en/group/spring/WG_Policies


That status of Huawei and ZTE implementations are unclear to me. It’s written “The implementation is under development » and « Maturity Level: Product” which seems somewhat contradictory to me.
Would be good if you could update this section. If it’s a product, indicating the release number would be helpful.
Since there are 3 implementations, if someone rans interop test, that could be useful to indicate but that is not required.

Typo: :s/defination/definition  (*2 : ZTE, Huawei)



My laptop crashed and I may have lost some context and email orders. But probably not to the point of forgetting the email I sent you yesterday afternoon.
For the record, the email thread that you seem to quote below (From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> Sent: Wednesday, September 13, 2023 4:45 PM)

-       has been somewhat edited by you. The one I sent you is enclosed. The main point is that I was not commenting on the latest version of the text.

-       was a private reply to a private thread that you initiated deliberately off-list. Not sure how Netiquette has evolved in two generations. RFC1855 could now be considered old but that is not inline with its  “minimum set of guidelines for Network Etiquette (Netiquette)”

--Bruno



Orange Restricted
From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 13, 2023 6:45 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Weiqiang Cheng <[e-mail]<mailto:[e-mail]>>; Xipengxiao <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; James Guichard <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your confirmation. I have uploaded the draft. However, I also can not find out the non-ascii character. Crazy ☹

Now we may only need to wait for Stewart’s confirmation and then we can move into next step. Ping Stewart 😊

Thanks for your help and patience.
Li Cheng



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 13, 2023 4:45 PM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: Weiqiang Cheng <[e-mail]<mailto:[e-mail]>>; Xipengxiao <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks.
Works for me.
I’ve just added, enclosed one sentence to define the Path Segment itself (in addition to the PSID) and saying that this is a local segment:

# Path Segment

A Path Segment is a Local Segment which uniquely identify an SR path on the egress node.

Also IdNits complains about 1 instance of lines with non-ascii characters. Could you please fix it?

Thanks,
--Bruno



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 6, 2023 6:02 PM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks for your reply.
Please see inline [Bruno2]



Orange Restricted
From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 3, 2023 3:18 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Thanks for your comments. I think we are reaching the consensus soon. Please see inline.

Thanks,
Cheng


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 3, 2023 1:02 AM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Following the publication of -10, please find below some additional comments.

-10 has clarified that the PSID is a local identifier on the egress. (not a global one). I think that this calls for some cleaning in some sentences:

§2 “If the PSID is only used by the egress node to identify an SR path, the SRLB, SRGB or dynamic MPLS label pool can be used.”
I would propose to remove that historic sentence.

[Bruno2] you did not comment on this. Is there any disagreement? Is this doc specifying a use of the PSID on a node different than the egress node? If yes, where? If not, there is no such case/”if”
[Cheng2] Agree, I have deleted related text.

BTW, is there still any reason to allocate a PSID from the SRGB?
If not, I would propose to remove that case..

That would make the “Path Segment” a “Local Segment” as per RFC 8402. I would propose to state this.
e.g.
OLD: A Path Segment Identifier(PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or Segment Routing Global Block (SRGB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or dynamic MPLS label pool of the egress node of an SR path.
NEW: A Path Segment is a Local Segment [RC8402]. The Path Segment Identifier (PSID)  is a single label assigned as per [8402]

“because of mis-matching if the PSID is allocated from a SRLB.”
PSID is allocated from the SRLB, so there is no such “if”. If would propose to remove the quoted text.
[Cheng] I may not agree here. Because actually, there is no limitation or assumption of which block a PSID will be allocated. As long as the value of it is unique on the egress, then everything is ok. It can be allocated from any block, SRGB, SRLB, any other block you want. Is it correct?

[Bruno2] The PSID is only processed by one node: the egress.
As per RFC8402, this looks like a local segment to me.

Local Segment: […] The instruction associated with the segment is defined at the node level.

Global Segment: […] The instruction associated with the segment is defined at the SR domain level.



Why would you allocate a local segment from the SRGB ? (SR Global Block (SRGB): the set of global segments in the SR domain.)
https://www.rfc-editor.org/rfc/rfc8402#section-2
[Cheng2]Though I may think it is not forbidden. People can allocated a label from any label range(except special range) to a PSID, since it will be read by the egress node only, so no error will occur. But it may be wasteful to allocate a Global label to it. But it might have some advantages in operation I guess. Anyway, limiting PSID to be allocated from SRLB works to me.


Other comments:
§2 “When a PSID is used, the PSID MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.”

-       Actually “MUST” would be violated if multiple PSDI were used. e.g. when nested in used (cf §4) in a single Segment List (not requiring binding SID as §4 described)

-       This sentence is not needed if we say that the Path Segment is a local segment (see above) as this is how Local Segment are used.
[Cheng] I see your point. Yes, it is hard to explain here. The sentence is described under a context that when talking about egress and ingress, it is about the path that starts from the egress and the ingress. Therefore, when talking about a egress of a path associated with the PSID, it is the egress node allocated the PSID. Though, in a case of nesting, the whole label stack may combine with other labels, and make the label not at the final bottom.

We might not need the first part, because no matter where the path Segment is used, as long as it can be inserted correctly, that is fine.

Regarding the second part, the label MUST immediately follow the last label  of THE SR path, I think it is correct. What do you think?

[Bruno2] Not sure what you mean by “THE SR path”.
Looking at section3.4 where path monitoring is done at both sub-path and end-to-end path, the ingress is pushing two PSID (s-PSID and e-PSID). Please look at Figure 2.  One PSID (s-PSID) is not the last label of the stack.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment#name-nesting-of-path-segments

+------------+
~A->B SubPath~
+------------+
 |s-PSID(A->B)|
 +------------+
 | BSID(B->C) |
 +------------+
 | BSID(C->D) |
 +------------+
 |e-PSID(A->D)|
 +------------+


So it may become,
“When a PSID is used, it MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.”

[Bruno2] If the doc says that PSID is a local segment, we don’t need anything new. Let’s see if we agree that the Path Segment is a local segment.
[Cheng2]Yes, fixed.


“3. PSID Allocation and Distribution

There are some ways to assign and distribute the PSID. The PSID can be configured locally or allocated by a centralized controller or by other means, this is out of the scope of this document”

The first sentence does not say much (if anything) and the formulation does not seem precise enough for a STD track document.
Regarding allocation, if we say the Path Segment is a Local Segment (just like a BSID) I don’t think that there is anything new. Hence probably there is nothing to say about this.
Regarding signaling, I think it’s ok to say this this is out of cope of the document.

So proposed NEW

3. PSID and Distribution

Signaling of the PSID between the egress, ingress and possibly a centralized controller is out of the scope of this document.
[Cheng]Reviewing it again, I think the section can be deleted, and your proposed text can be added in to the above section. BTW, I think the nesting of Path Segment can be putted into the section of use case, which can make the logic clearer.
Please see the proposed update.

[Bruno2] “A PSID is allocated by an egress node and distributed to an ingress.” Text is good but I’m not sure I would have specified this as part of the “Security Considerations” section. I would have moved or copied in the spec. (in section 2)
[Cheng2]OK, refine the text.

__NEW__
The distribution of a PSID from an egress nodes to an ingress nodes is performed within an SR trusted domain, and it is out of the scope of this document. The details of the mechanism and related security considerations will be described in other documents.


-----

§5, §6, §7.
My reading is that those 3 sections do not specify behaviors (which would typically be specified in other WGs) but are uses cases that could leverage the Path Segment.
I would propose to move those 3 sections into a new section “Use cases”.
Proposed NEW

§5 Uses cases
This section described uses cases which can leverage the Path Segment.
§5.1 Path Segment for Performance Measurement
[…]
§5.2 Path Segment for Bidirectional SR Path
[…]
§5.3 Path Segment for End-to-end Path Protection
[…]

[Cheng]OK, reorganized.

[Bruno2] OK.

----
“Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>], when GAL is used, it the ACH appears immediately after the bottom of the label stack.”
IMO :s/MAY/may

Also this sentence could be rephrase to use the same style than the Entropy Label case.
e.g. proposed NEW
If Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks, as per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>], the ACH would appear immediately after the bottom of the label stack and hence does not interfere with the PSID which is placed above.”
[Cheng]how about this?
If a Generic Associated Label (GAL) is used for Operations, Administration and Maintenance (OAM) in MPLS networks, as per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>], the ACH would appear immediately after the bottom of the label stack and hence does not interfere with the PSID which is placed above.”

[Bruno2] OK.

---
§8
“A Path Segment is used within an SR-MPLS domain [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] and SHOULD not leak outside the domain,”

“SHOULD not’ is not allowed. It’s either SHOULD NOT or should not.
IMO is in this context it’s “should not”
[Cheng]Fixed


[Bruno2] OK.

Thanks
--Bruno

Thanks,
--Bruno




Orange Restricted
From: DECRAENE Bruno INNOV/NET
Sent: Wednesday, August 2, 2023 2:47 PM
To: Cheng Li <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks for the updated draft.

Please see some follow-up points inline [Bruno].




Orange Restricted
From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 17, 2023 12:43 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your work! I am addressing the comments received from the WG, so it is fine/good to me that address your comments in the same time 😊
Please see my reply inline. The diff is generated by comparing with 09. The proposed update tries to address the comments from you, Ketan and Stewart.

If you like to use Github, the link is here: https://github.com/muzixing/SR-MPLS-Path-Segment/commit/3ace59b1e87859950dfac8a967ee560128843b6b

Respect and thanks,
Cheng


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 12, 2023 10:41 PM
To: [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>
Subject: draft-ietf-spring-mpls-path-segment

Hi authors,

Since Jim is now the responsible AD, the shepherd for this document has been changed from Jim to myself.
As a result you/this document benefit/suffer from another review.

Please find below my comments/questions.

On a side note, I have two questions for you (for the shepherd writeup):
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan to implement the specification?

[Cheng]Weiqiang has replied to you on these two questions. Path Segment has been implemented by a significant number of vendors for several years, and it has been used in large scale networks.

[Bruno] Thank you.
Actually the SPRING WG has a policy to mandate an implementation section in the document. https://wiki.ietf.org/en/group/spring/WG_Policies
Could you please add one?

---

[…]

-----
§2
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."
"MUST" is a pretty strong statement. What is the reason for this? What is the egress supposed to do if this is not the case?
Interestingly, RFC 6790 has a oppositive position with regards to the Entropy Label: "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding." while the case seems similar (addition of a label "not used for forwarding")
https://datatracker.ietf.org/doc/html/rfc6790#section-4.2

Is there any rule for the TC field? (if not, please say so; if so, please specify the rule)
[Cheng] because we do not use Path Segment for forwarding, so IMHO, the TTL can be any, like 0, or same as the previous one.  How about the following modifications?
___OLD____
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."

___NEW___
"The value of the TTL field in the MPLS label stack entry containing the PSID can be set to any value including 0, or the same value as the TTL of the last label stack entry for the last segment in the SR path."

[Bruno] I disagree with the setting of the TTL to zero. If PHP is enabled, the PSID will appear top of stack and sending an MPLS packet with a TTL zero in the top of stack is not allowed in MPLS
cf https://datatracker.ietf.org/doc/html/rfc3032#section-2.4.2
(Entropy Label could do that because it never appears top of stack)

Actually, the TTL field in the path segment does not seem much different than the TTL field in a binding or adjacency segment. So may be the whole text on TTL may be removed.

-----
§2

"In some deployments, service labels may be added after the Path Segment label in the MPLS label stack. In this case, the egress node MUST be capable of processing more than one label. The additional processing required, may have an impact on forwarding performance."
I belive that when the PSID is used, there is _always_ an extra processing work on the data plane (the processing of the PSID). So I don't think that this is specific to "some deployments" or "service label".
If so, please rephrase.


[Cheng]Well, to me, the sentence is trying to explain the cases that the egress node needs to support processing of multiple labels. But we do have some use cases that the only label is processed on the egress node is the PSID. For example, we only encode the labels of the LSP and PSID in the label stack while the last forwarding label is a PHP enable label. Therefore, when a packet arrives on the egress node, only one single label(The PSID) will be processed. In this case, multiple labels processing is not required.

In other words, this paragraph is only for info that it explains we may have differences with or without services label. If without services label, then the requirement of processing multiple labels MAY not changed. Indeed, the processing of PSID is new in any cases.

[Bruno] A label below the PSID is not limited to the use of service label. e.g, cf section 4 but also with a single PSID followed by transit labels. So at minimum the first sentence is misleading.
Again, I would rather cover the general case. Some proposed text as replacement.
The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing (such as a below MPLS label or the MPLS payload). The additional processing required, may have an impact on forwarding performance


---
[…]

 ----
§2
"Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID."

Reading RFC 5586, that seems to be already the rule for GAL.  Hence I don't think that this needs to be defined as a new rule (MUST). Especially as this seems to indicate a variation (before BoS vs after BoS) hence this may add confusion.
I would propose:
OLD: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID.
NEW: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586], when GAL is used, it the ACH appears immediately after the bottom of the label stack.
[Cheng] OK, thank you!

[Bruno] Actually I introduced a typo  (:s/it the/the)

---
[…]


 ----
§3
"If an egress cannot support the use of the PSID, it MUST reject the attemption of configuration."

If a egress doest not support PSID, how would it support the above rule?
It would seem easier to put the rule/burden on one pushing the PSID (e.g. the 'centralized controller" although the latter is "out of scope of this document")
[Cheng]You are right. We might delete it directly, because it is obvious as well.

[Bruno] You did remove this sentence. However the sentence was written _twice_ in -09, so as a result, in -10 the sentence is still present so there is still a need to remove it.

---
§ 8. Security Considerations

 "no new security threats are introduced comparing to current SR-MPLS"
In general, such statement may be read by security guys as "we did not really bothered studying the security implications". IMO it's better to put more text to explain _why_ there is no impact on security.
As a matter of fact, I'm not sure to agree with this statement: the one (e.g. an attacket) having the ability to signal a PSID value to an ingress, would have the ability to signal any label including a label value used as a service (VPN) label. This would trigger a VPN breach (injecting packets in the VPN).
This may not be not specific to the PSID, but even an "old" RFC with "old" security considerations is doing an effort well beyond "nothing new". https://datatracker.ietf.org/doc/html/rfc5036#section-5
So please consider enhancing the security consideration.

[Cheng] I have to say sorry here, because I am not an expert of security. How about the following modifications?

___NEW___
A Path Segment in SR-MPLS is a label similar to other labels/Segment, such as a VPN label or a Prefix SID, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node, or an egress node, which follows the same logic of existing MPLS dataplane.

A Path Segment is used within an SR-MPLS domain {{RFC8402}} and SHOULD not leak outside the domain, therefore no new security threats are introduced comparing to current SR-MPLS. The security consideration of SR-MPLS, such as boundary filtering described in {{Section 8.1 of RFC8402}} applies to this document.

A PSID is allocated by an egress node and distributed to an ingress. The distribution is performed within an SR trusted domain. However, the mechanism of distributing a PSID is out of the scope of this document, and its security consideration will be described in other documents.

[Bruno] I think that you mean :s/SHOULD/should
(there is no special new thing to be done)

Thanks,
Bruno

Thanks,
BR
--Bruno

____________________________________________________________________________________________________________

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