Subject: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03

From: <[email-masked]>
Date: Fri, 4 Nov 2016 15:50:21 +0000

Hi authors,

Although I'm more familiar with IS-IS (nobody's perfect ;-) ), please find below some proposed comments

1) meaning of "TE"
As already expressed in a meeting, I'd like the document to clarify the meaning of "TE". I suspect that in this document it is used to mean "RSVP-TE" while some readers could understand it as "Traffic Engineering application". IOW, is SR-TE part of "TE" or not?

In particular, this needs to be crystal clear in the recommended approach. Current text is:
"3.3.  Selected Approach
   It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to advertise any link attributes used for non-TE purposes in OSPFv2"

IMHO, I would interpret this text as SR-TE must not use the Extended Link Opaque LSA ([RFC7684], hence presumably must use the TE Opaque TSA.
But I suspect that this is not the intent of the authors.

2) As a minor comment, I'm not that convinced with (or don't understand well) the argument 2 in section 3.2
"The TE Opaque LSA remains truly opaque to OSPFv2 as originally  defined in [RFC3630].  Its content is not inspected by OSPFv2 and  OSPFv2 acts as a pure transport."

Why should RSVP-TE info be truly opaque to OPSFv2 while SR-TE or LFA info should not be opaque?

3) §5 " Bit-1: LFA"
Could you please clarify what you mean by "LFA"?
Do you mean "LFA" ie RFC 5286? Or *LFA to include LFA, RLFA, DLFA, TI-LFA? (but this would not cover some possibly future solution) Or "FRR" in which case this would include RSVP-TE FRR? or "IP FRR"? (but I'm afraid this term is loosely defined)...

4) §5
"If, however,
   another advertisement of the same link attribute includes Application
   Bit-Mask in the Extended Link Attribute sub-TLV, applications that
   are listed in the Application Bit-Mask of such Extended Link
   Attribute sub-TLV SHOULD use the attribute advertisement which has
   the application specific bit set in the Application Bit-Mask."

Why SHOULD rather than MUST? A priori the principle is that the most specific information prevails. i.e the attribute advertisement which has
   the application specific bit set in the Application Bit-Mask is to be used.

5) §5 I have a clarification question with regards to the use of "Unidirectionnal Residual Bandwidth" for non TE applications (i.e.  for OSPFv2 Extended Link TLV).
What would be the meaning of this sub-TLV for non-TE application, given that RFC 7471 seems to have defined a meaning which is RSVP-TE specific "For a link or forwarding adjacency,
   residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus  the bandwidth currently allocated to RSVP-TE LSPs."

Same question for "Available Bandwidth" which definition is also RSVP-TE specific.

Related question for "Utilized Bandwidth", and * "Unidirectional Link Delay" which seems to measure a specific physical property, which does not seem to be possibly different on a per application basis.
e.g. " The delay advertised by this sub-TLV MUST be the delay from the advertising node to its neighbor (i.e., the forward path delay)." How could this value be application specific?

6) §6 backward compatibility
Thanks for considering the backward compatibility. I fell that one case is missing.
"If there are also OSPF routers using the link attributes
   described herein for Non-RSVP applications, OSPF routers in the
   routing domain will also need to advertise these attributes in OSPF
   Extended Link Attributes LSAs [RFC7684]."

At the beginning, some OSPF routers not (yet) upgraded to be compliant with this spec, won't be capable of advertising these attributes in OSPF  Extended Link Attributes LSAs. So "new" routers won't be able to understand "old" routers. A more graceful way to introduce this change, would be to ask "new" routers also listen to "old" routers. i.e. if no "TE attributes" is advertised in Extended Link Attributes LSAs, then look for this attributes in TE Opaque LSAs, and use that information for "non-TE applications". (Using a node capability would a priori seems easier, but this is a detail)

Thanks,
Regards,
-- 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.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 07 Nov 2016 13:22:33 +0100

Hi Bruno,

thanks for your comments, please see responses inline.

We can work on details as we progress the draft in the WG.
What I would like to hear from you at this point is whether you support 
the idea described in the draft.

> As already expressed in a meeting, I'd like the document to clarify the meaning of "TE". I suspect that in this document it is used to mean "RSVP-TE" while some readers could understand it as "Traf…

TE in the context of the draft means RSVP based TE.

>     It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to advertise any link attributes used for non-TE purposes in OSPFv2"

sure, we can make that clarification.

> But I suspect that this is not the intent of the authors.

In a long run, we would like the SRTE to use the Extended Link Opaque 
LSA ([RFC7684].

> Why should RSVP-TE info be truly opaque to OPSFv2 while SR-TE or LFA info should not be opaque?

both are opaque to OSPF. What is important is that SRTE advertisements 
would not cause any node in the network to believe that RSVP TE is 
available on the link - that's why we need to separate the two 
advertisements.

> Do you mean "LFA" ie RFC 5286? Or *LFA to include LFA, RLFA, DLFA, TI-LFA? (but this would not cover some possibly future solution) Or "FRR" in which case this would include RSVP-TE FRR? or "IP FRR…

any type of LFA. These is detail though and subject to changes if required.

>     the application specific bit set in the Application Bit-Mask is to be used.

sure, this is a small detail. No problem to change to MUST.

> Same question for "Available Bandwidth" which definition is also RSVP-TE specific.

the short answer is that these are bandwidth minus the bandwidth 
allocated/used by RSVP TE.

> e.g. " The delay advertised by this sub-TLV MUST be the delay from the advertising node to its neighbor (i.e., the forward path delay)." How could this value be application specific?

we can debate which attributes make sense to be application specific. 
I'm open for that discussion.

> At the beginning, some OSPF routers not (yet) upgraded to be compliant with this spec, won't be capable of advertising these attributes in OSPF  Extended Link Attributes LSAs. So "new" routers won't be able to understand "old" routers.

new routers would always understand the old advertisements.

A more graceful way to introduce this change, would be to ask "new" 
routers also listen to "old" routers. i.e. if no "TE attributes" is 
advertised in Extended Link Attributes LSAs, then look for this 
attributes in TE Opaque LSAs, and use that information for "non-TE 
applications".

absolutely, that is the idea. I will make sure the text is clear on that.

thanks,
Peter

(Using a node capability would a priori seems easier, but this is a detail)
> .

---

From: <[email-masked]>
Date: Mon, 7 Nov 2016 14:35:56 +0000

Hi Peter,

Many thanks for your replies.
Please see inline [Bruno]

> From: Peter Psenak [mailto:[email-masked]]  > Sent: Monday, November 07, 2016 1:23 PM
> 
 > Hi Bruno,
 > 

[Bruno] Sure. We can also work on these details independently of the WG adoption (question). This was purpose of this thread (even though it was at the same time of the WG adoption thread)

 > the idea described in the draft.
 
[Bruno] 
- I support the problem statement and the need for a solution.
- Regarding the encoding (type of LSA/TLV), if the question is specific to the OSPF WG, and the IS-IS WG will be free to make a fully independent decision/solution, I'd rather leave this choice to OSPF users/implementers/experts (rather than adding noise on the mailing list). If the OSPF choice is likely to influence the IS-IS choice, I'd prefer waiting for the IS-IS document to express my comments/support. 

 > > As already expressed in a meeting, I'd like the document to clarify the meaning of "TE".
 > I suspect that in this document it is used to mean "RSVP-TE" while some readers could
 > understand it as "Traffic Engineering application". IOW, is SR-TE part of "TE" or not?
 > 
 
[Bruno] Thanks for the crystal clear clarification. Looks good to me.
 
 > >     It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to advertise
 > any link attributes used for non-TE purposes in OSPFv2"
 > 
 > > IMHO, I would interpret this text as SR-TE must not use the Extended Link Opaque LSA
 > ([RFC7684], hence presumably must use the TE Opaque TSA.
 > > "The TE Opaque LSA remains truly opaque to OSPFv2 as originally  defined in [RFC3630].
 > Its content is not inspected by OSPFv2 and  OSPFv2 acts as a pure transport."
 > >
 > available on the link

[Bruno] Agreed. Here comes a naïve question: What (signaling) would "cause a node in the network to believe that RSVP TE is available on the link"? Is this standardized or implementation specific?

e.g. reading RFC 7471, I'm not seeing that advertising "OSPF Traffic Engineering (TE) Metric Extensions" is limited to RSVP-TE

"   The data distributed by OSPF TE Metric Extensions is meant to be used
   as part of the operation of the routing protocol (e.g., by replacing
   cost with link propagation delay or considering bandwidth as well as
   cost), by enhancing Constrained Shortest Path First (CSPF), or for
   use by a PCE [RFC4655] or an Application-Layer Traffic Optimization
   (ALTO) server [RFC7285]."

Even reading RFC 3630 applicability
" A more accurate (albeit bland) designation is
   "extended link attributes", as the proposal is to simply add more
   attributes to links in OSPF advertisements."
[..]
"Uses of the traffic engineering database include:

      o  monitoring the extended link attributes;
      o  local constraint-based source routing; and
      o  global traffic engineering."

I could read the second item as applicable to (written for? ;-) ) Segment Routing... And the first item applicable to regular IP Shortest Path routing.

> - that's why we need to separate the two advertisements.

[Bruno] At this point, I'm not seeing the causality, but this is due to my lack of OSPF knowledge. cf my first point.
 
 > > Do you mean "LFA" ie RFC 5286? Or *LFA to include LFA, RLFA, DLFA, TI-LFA? (but this
 > would not cover some possibly future solution) Or "FRR" in which case this would include
 > RSVP-TE FRR? or "IP FRR"? (but I'm afraid this term is loosely defined)...
 > 
 > > Why SHOULD rather than MUST? A priori the principle is that the most specific
 > information prevails. i.e the attribute advertisement which has
 > > 5) §5 I have a clarification question with regards to the use of "Unidirectionnal Residual
 > Bandwidth" for non TE applications (i.e.  for OSPFv2 Extended Link TLV).
 > > What would be the meaning of this sub-TLV for non-TE application, given that RFC 7471
 > seems to have defined a meaning which is RSVP-TE specific "For a link or forwarding
 > adjacency,
 > >     residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus  the
 > bandwidth currently allocated to RSVP-TE LSPs."
 > >
 > > Related question for "Utilized Bandwidth", and * "Unidirectional Link Delay" which
 > seems to measure a specific physical property, which does not seem to be possibly
 > different on a per application basis.
 > > e.g. " The delay advertised by this sub-TLV MUST be the delay from the advertising node
 > to its neighbor (i.e., the forward path delay)." How could this value be application
 > specific?
 > 
 
[Bruno] Sure. Thanks.
Unfortunately, this is partly related to the interest in duplicating the TLV advertisement or not: if by design their value is application un-specific, advertising the TLV multiple times will just increase the configuration/code/interop/error handling complexity.
However, I agree that some TLV may/could be application specific, in which case it is/would be a feature to be able to advertise it on a per application basis.
 
 > > At the beginning, some OSPF routers not (yet) upgraded to be compliant with this spec,
 > won't be capable of advertising these attributes in OSPF  Extended Link Attributes LSAs.
 > So "new" routers won't be able to understand "old" routers.
 > 

[Bruno] Sure.
 
 > attributes in TE Opaque LSAs, and use that information for "non-TE
 
[Bruno] Yes, that's the point I had in mind. Thanks for reading my mind when my emails are not clear enough.
 
 > absolutely, that is the idea. I will make sure the text is clear on that.
 
[Bruno] Thanks.
1 more point/question: 
"When an OSPF routing domain includes routers using link attributes from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF routers in that domain should continue to advertise such TE Opaque LSAs. "
If there are drawbacks, they should probably be mentioned. e.g. some RSVP-TE routers will assume that RSVP-TE is enabled on a link, even if this not the case. Which will cause RSVP-TE to return an error, and hence a new RSVP-TE signaling.
If there are no drawbacks, what would be the motivation to implement and deploy this new behavior (TE advertisement in Extended Link Opaque LSA [RFC7684])? E.g. as a network operator, if I ask for RFC 7471 TLV to be implemented inside TE Opaque LSA, it will work for both current/old and new routers. If I ask it inside Extended Link Opaque LSA it will only work for new/future implementations. Based on this, it seems safer for me to ask for TE Opaque LSA and don't bother with Extended Link Opaque LSA. (cf IPv4 vs IPv6 at the "beginning" of IPv6.)

Thanks again for your clear clarifications.

--Bruno
 
 > _________________________________________________________________________
 > ________________________________________________
 > >

---

From: Peter Psenak <[email-masked]>
Date: Tue, 08 Nov 2016 10:26:21 +0100

Hi Bruno,

please see inline (##PP):

> - Regarding the encoding (type of LSA/TLV), if the question is specific to the OSPF WG, and the IS-IS WG will be free to make a fully independent decision/solution, I'd rather leave this choice to…

##PP
encoding is one thing, what I would like to hear from you is whether you 
support the idea of per application link-attribute values.

> [Bruno] Agreed. Here comes a naïve question: What (signaling) would "cause a node in the network to believe that RSVP TE is available on the link"? Is this standardized or implementation specific?

##PP

as all existing link attributes have been defined for RSVP TE, almost 
any implementation interpret the presence of these link attributes as an 
indication that RSVP TE is enabled on the link.

draft-hegde-isis-advertising-te-protocols in chapter 1 lists the 
behavior of three different implementations.

> I could read the second item as applicable to (written for? ;-) ) Segment Routing... And the first item applicable to regular IP Shortest Path routing.

##PP

RFC3630 also says:

    "The extensions provide a way of describing the traffic engineering
    topology (including bandwidth and administrative constraints) and
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,"

> [Bruno] At this point, I'm not seeing the causality, but this is due to my lack of OSPF knowledge. cf my first point.

##PP
problem is not specific to OSPF, applies the same way to ISIS.

> However, I agree that some TLV may/could be application specific, in which case it is/would be a feature to be able to advertise it on a per application basis.

##PP
right. Which ones are eligible for app specific values is something we 
can work on. We have few that we know would be eligible.

> "When an OSPF routing domain includes routers using link attributes from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF routers in that domain should continue to advertise such TE Opaque LSAs."

##PP
that is correct.

> If there are no drawbacks, what would be the motivation to implement and deploy this new behavior (TE advertisement in Extended Link Opaque LSA [RFC7684])? E.g. as a network operator, if I ask for…

##PP
As far as we keep the link attributes for non RSVP-TE apps in TE Opaque 
LSA we have a problem (as described above). To solution is to move them 
to Extended Link LSA.

If some implementation uses TE Opaque LSA for no RSVP-TE purposes, it 
may continue to do so during transition, but eventually all routers 
would move to the new behavior.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 06:52:44 +0000

Hi,

We agreed during the OSPF meeting that a use case/requirement draft should be written before progressing with any solution.
I propose to take the point to initiate the work and I will first try to list the possible situations and then we can really agree on the use cases that are relevant. We have some in Orange but there may be additional as well.

Brgds,

Stephane

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Peter Psenak
Sent: Tuesday, November 08, 2016 18:26
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; [email-masked]
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03

Hi Bruno,

On 07/11/16 15:35 , [email-masked] wrote:
> [Bruno] Sure. We can also work on these details independently of the 
> WG adoption (question). This was purpose of this thread (even though 
> it was at the same time of the WG adoption thread)
>

##PP
encoding is one thing, what I would like to hear from you is whether you support the idea of per application link-attribute values.

##PP

as all existing link attributes have been defined for RSVP TE, almost any implementation interpret the presence of these link attributes as an indication that RSVP TE is enabled on the link.

draft-hegde-isis-advertising-te-protocols in chapter 1 lists the behavior of three different implementations.

>
> e.g. reading RFC 7471, I'm not seeing that advertising "OSPF Traffic 
> Engineering (TE) Metric Extensions" is limited to RSVP-TE
>

##PP

RFC3630 also says:

##PP

> However, I agree that some TLV may/could be application specific, in which case it is/would be a feature to be able to advertise it on a per application basis.

##PP
right. Which ones are eligible for app specific values is something we can work on. We have few that we know would be eligible.

##PP
that is correct.

> If there are no drawbacks, what would be the motivation to implement 
> and deploy this new behavior (TE advertisement in Extended Link Opaque 
> LSA [RFC7684])? E.g. as a network operator, if I ask for RFC 7471 TLV 
> to be implemented inside TE Opaque LSA, it will work for both 
> current/old and new routers. If I ask it inside Extended Link Opaque 
> LSA it will only work for new/future implementations. Based on this, 
> it seems safer for me to ask for TE Opaque LSA and don't bother with 
> Extended Link Opaque LSA. (cf IPv4 vs IPv6 at the "beginning" of 
> IPv6.)

##PP
As far as we keep the link attributes for non RSVP-TE apps in TE Opaque LSA we have a problem (as described above). To solution is to move them to Extended Link LSA.

If some implementation uses TE Opaque LSA for no RSVP-TE purposes, it may continue to do so during transition, but eventually all routers would move to the new behavior.

thanks,
Peter
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 22 Nov 2016 16:29:07 +0000

Stephane -

> From: OSPF [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, November 16, 2016 10:53 PM
> To: Peter Psenak (ppsenak); DECRAENE Bruno IMT/OLN
> We agreed during the OSPF meeting that a use case/requirement draft
> should be written before progressing with any solution.

[Les:] Both as minute-taker and WG member, I think you have not accurately reflected what happened at the meeting.
It is true that there was discussion about writing a use case document - and multiple people (myself included) believe that writing a use case document would be a good idea.

It is inaccurate however to say that the WG decided to do this - and it is particularly inaccurate to say that the WG decided that progress on the solution drafts should be halted until the use case document is written.

Please see another post I sent to the list a few minutes ago reflecting how I think the  WG should move forward. I do think writing a use case document is a good idea, but I also think we already understand use cases and requirements well enough to know what extensions to the protocol are required. 

   Les
 
> I propose to take the point to initiate the work and I will first try to list the
> possible situations and then we can really agree on the use cases that are
> relevant. We have some in Orange but there may be additional as well.
> 
> Brgds,
> 
> Stephane
> 
> > - Regarding the encoding (type of LSA/TLV), if the question is specific to the
> OSPF WG, and the IS-IS WG will be free to make a fully independent
> decision/solution, I'd rather leave this choice to OSPF
> users/implementers/experts (rather than adding noise on the mailing list). If
> the OSPF choice is likely to influence the IS-IS choice, I'd prefer waiting for
> the IS-IS document to express my comments/support.
> 
> ##PP
> >   > > Although I'm more familiar with IS-IS (nobody's perfect ;-) ), please
> find below some
> >   > proposed comments
> >   > >
> >   > > 1) meaning of "TE"
> >   > > In particular, this needs to be crystal clear in the recommended
> approach. Current text
> >   > is:
> >   > > "3.3.  Selected Approach
> >   > > 2) As a minor comment, I'm not that convinced with (or don't
> understand well) the
> >   > argument 2 in section 3.2
> >   > > Why should RSVP-TE info be truly opaque to OPSFv2 while SR-TE or
> LFA info should not
> >   > be opaque?
> >   >
> > [Bruno] Agreed. Here comes a naïve question: What (signaling) would
> "cause a node in the network to believe that RSVP TE is available on the
> link"? Is this standardized or implementation specific?
> 
> ##PP
> 
> as all existing link attributes have been defined for RSVP TE, almost any
> implementation interpret the presence of these link attributes as an
> > I could read the second item as applicable to (written for? ;-) ) Segment
> Routing... And the first item applicable to regular IP Shortest Path routing.
> 
> ##PP
> 
> RFC3630 also says:
> 
> > Unfortunately, this is partly related to the interest in duplicating the TLV
> advertisement or not: if by design their value is application un-specific,
> advertising the TLV multiple times will just increase the
> configuration/code/interop/error handling complexity.
> > However, I agree that some TLV may/could be application specific, in which
> case it is/would be a feature to be able to advertise it on a per application
> basis.
> 
> ##PP
> right. Which ones are eligible for app specific values is something we can
> work on. We have few that we know would be eligible.
> 
> >
> >   > >
> > "When an OSPF routing domain includes routers using link attributes from
> TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF routers in
> that domain should continue to advertise such TE Opaque LSAs."
> > If there are drawbacks, they should probably be mentioned. e.g. some
> RSVP-TE routers will assume that RSVP-TE is enabled on a link, even if this not
> the case. Which will cause RSVP-TE to return an error, and hence a new
> RSVP-TE signaling.
> 
> ##PP
> that is correct.
> 
> As far as we keep the link attributes for non RSVP-TE apps in TE Opaque LSA
> we have a problem (as described above). To solution is to move them to
> Extended Link LSA.
> 
> If some implementation uses TE Opaque LSA for no RSVP-TE purposes, it may
> continue to do so during transition, but eventually all routers would move to
> the new behavior.
> 
> thanks,
> Peter
> >
> 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.
> >   > >
> privileged information
> >   > that may be protected by law;
> >   > > 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.
> >   > >
> >   > > .
> >   > >
> >
> >
> >
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.