Re: [spring] draft-ginsberg-spring-conflict-resolution

[Robert Raszuk <[e-mail]>]

Hi,

So we agree that you can't write a draft to define SRGB errors as those are
local design choices. Done with that :)

As far as "SID conflict" I am not sure I would agree too ... if I can
tunnel to an anycast IP address why I can not tunnel to anycast SID -
configured as same on N different nodes ?

The only sort of error which I see so far to be detected is overlapping
ranges being advertised by single node and current trend is to detect it
during configuration. But is this really an error ? Why can't we just treat
overlapping ranges as such and once received construct a SRGB for a given
node out of those overlapping or not overlapping ranges ?

Cheers,
R.


On Fri, Jan 8, 2016 at 10:23 AM, <[e-mail]> wrote:

> Hi Robert,
>
>
>
> Regarding SRGB management, it’s really a design choice. There was already
> some discussion in the past.
>
> If people/implementations uses a global SRGB which is agnostic to
> protocols, cross protocol validation does not really make sense.
>
> If people/implementations uses per protocol SRGB, cross protocol
> validation makes sense.
>
> I do not see a real use case for the partial overlapping between protocols.
>
>
>
> I agree with you that using a common SRGB for all protocols works well and
> only SID conflict management in necessary in this case.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, January 07, 2016 17:19
> *To:* LITKOWSKI Stephane SCE/OINIS
> *Cc:* Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [e-mail]
> *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution
>
>
>
> Hi Stephane,
>
>
>
> > For example, if user tries to configure a BGP SRGB that
>
> > overlaps with ISIS SRGB
>
>
>
> Can you elaborate why that would be a bad thing to have two protocols
> advertise even not partially overlapping but identical SRGB from a given
> node ?
>
>
>
> Also while we are at the node doing the check during configuration let's
> do not forget that not all configurations these days are real time and
> inline. To add concepts of forward referencing are also used which may
> allow on purpose to configure overlapping blocks before even given IGP (or
> protocol in general) is activated on any interface.
>
>
>
> Best,
>
> r.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 7, 2016 at 5:12 PM, <[e-mail]> wrote:
>
> Hi,
>
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs.
> This would indeed increase the complexity and I am not convinced we would
> gain much.
> SID conflict detection is a different matter - there we do indeed want to
> include all protocols.
>
> [SLI] IMO, complexity of SRGB cross protocol validation  depends on how
> the implementation is done. The SRGB may or may not really be owned by the
> protocol directly. Protocol just do the advertisement, but SRGB may be
> owned by SR that may do suballocation for a particular protocol. That
> really depends on how it has been coded. I'm not sure that in Cisco
> implementation that ISIS requests label range directly from the label
> manager ? If "SR process" owns all the labels and just receive requests
> from protocols to reserve a particular SRGB, it has the global view and can
> manage overlap easily. For example, if user tries to configure a BGP SRGB
> that overlaps with ISIS SRGB, it can be easily refused by the SR process.
>
> So we go back to the question of the requirements ... I think it would be
> really helpful that the WG agree on the requirement before talking about
> solutions.
>
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> Sent: Thursday, January 07, 2016 00:03
> To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
> Cc: [e-mail]
>
> Subject: RE: draft-ginsberg-spring-conflict-resolution
>
> Bruno -
>
> I think there are two questions for me below - look for my answers inline.
> Let me know if I missed anything.
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, January 06, 2016 10:04 AM
> > To: LITKOWSKI Stephane SCE/OINIS
> > Cc: [e-mail]; Les Ginsberg (ginsberg)
> > Subject: RE: draft-ginsberg-spring-conflict-resolution
> >
> > Hi Stéphane,
> >
> > Many thanks for contributing on this subject and for your comments.
> >
> > Please see inline [Bruno]
> > Les, there is a specific question for you at the penultimate comment.
> >
> > I'll send an updated text and diff in a few days, after considering
> > comments from currently unread emails.
> >
> > Bruno
> >
> > > -----Original Message-----
> > > From: LITKOWSKI Stephane SCE/OINIS
> > > Sent: Monday, January 04, 2016 9:41 AM
> > > To: DECRAENE Bruno IMT/OLN; [e-mail]; Les Ginsberg (ginsberg)
> > > Subject: RE: draft-ginsberg-spring-conflict-resolution
> > >
> > > Hi Bruno,
> > >
> > > And best wishes all for this new year.
> > >
> > >
> > > It seems that posting your txt back as attachment to the list does
> > > not work so I will put my comments on the text directly in the email :
> >
> > [Bruno] sorry for the inconvenience. To avoid commenting twice, you
> > could have copy / past the .txt attachment into the email body.
> >
> >
> > > - In §2.2 : you keep the statement "The following ranges are used:"
> > > empty, may be it would be better to change with something like :
> > > "None of the ranges are used in this case"
> >
> > [Bruno] This is already spelled out lines above "In case of conflicts,
> > all the ranges advertised are invalidated and dropped."
> > But I see what you mean. On the other hand, the goal was to have a
> > short summary to allow comparison between options.
> > Currently I've changed to
> > "The following ranges are used:
> >       <none>"
> >
> > But any other option is welcomed
> >
> >
> > > - §2.6 : It should be mentioned that this kind of behavior should
> > > never happen because the sender must have local configuration
> > > procedures to avoid this kind of behavior.
> >
> > Added: These SRGB ranges are advertised by a single node. As per
> > [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a
> > SRGB range conflict means a bug in the implementation of the originator.
> >
> > > But in case there is something going wrong and such advertisement is
> > > received, routers must have a consistent behavior.
> > > IMO, as the local implementation must avoid this kind of
> > > advertisement (and I think we need to state this somewhere),
> >
> > [Bruno] I agree with you. I think this should be mentioned in §2.7
> > "Discussion" rather than in §2.6. I propose to add:
> > "These SRGB ranges are advertised by a single node. As per [SR-IS-IS],
> > a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range
> > conflict means a bug in the implementation of the originator. However,
> > bugs happen and we need a consistent error handling behaviour across
> > the network to minimize mis-routing and to allow ingress to know the
> > state of the network and act upon (e.g. reroute around the bug)"
> >
> > > drop all
> > > sounds the best option because as this might be a bug, nothing says
> > > that the forwarding is correctly setup on the node sending the bad
> > advertisement.
> >
> > [Bruno] At this point in time, I would rather write down the pro&con
> > of each option, in order to allow technical discussion, refinement and
> > hopefully drive the discussion toward consensus.
> > Personally, as of today, I would favor either "Drop all" or "Drop from
> conflict".
> > The latter have the nice property that, assuming that the network was
> > running correctly before, the issue is with the added SRGB range which
> > may be expected to be added to allow for future growth. i.e. not
> currently used.
> > So this seems overkill to drop all traffic, for a SRGB range which has
> > been added and is not even used by global SIDs.
> >
> >
> > > - §3. : IGP LSDB may be too restrictive, as depending of the label
> > management
> > >    implementation, there might be cross protocol conflicts of SIDs.
> >
> > [Bruno] Agreed. But:
> > - this is a text from Les, I'll leave the resolution to Les
> > - I'd rather avoid making the issue more complex, while we still can't
> > agree on conflict resolution within a protocol.
> >
>
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs.
> This would indeed increase the complexity and I am not convinced we would
> gain much.
> SID conflict detection is a different matter - there we do indeed want to
> include all protocols.
>
>
> > >
> > > - §3.2.1 :
> > > [SLI] Maybe we should mention that this kind of conflict has a
> "limited"
> > impact.
> > > On the LSR, we have more LFIB consumption but no traffic impact, as
> > > we are creating multiple parallel LSPs towards the same destination.
> > > At the iLSR side, there might be some churn in the FIB (IP to MPLS
> > > entry) as it will have to choose one or the other advertisement in
> > > order to program the entry.
> >
> > [Bruno] Agreed. Good point thanks.
> > Added in 3.2.1 (1 prefix, multiple SIDs): "The consequences of this
> > conflict is that multiple MPLS FIB entries would be programmed for a
> single IP Prefix.
> > This has no impact on the traffic but use more MPLS FIB entries, which
> > may or not be problematic  for the network equipments."
> >
> >
> > > - §3.2.2 :
> > > [SLI] As previous comment, we may need to mention the impact of such
> > > conflict : inconsistent routing (even possible loops)  if there is
> > > disagreement between routers (LSRs).
> >
> > [Bruno] Agreed. Good point thanks.
> > Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of this
> > conflict is that in the absence of conflict resolution two IP prefixes
> > would be forwarded to the same destination. If they are part of the
> > same FEC (Forwarding Equivalent Class), this is not an issue.
> > Otherwise, this leads to mis-routing of a prefix to a wrong
> > destination. In a VPN network, this may lead to VPN breach which is very
> problematic (even if the breach would be unidirectional only).
> > In case of inconsistent conflict resolution across nodes, this may
> > lead to persistent forwarding loops."
> >
> >
> > > - §3.3 :
> > > [SLI] We must mention, that traffic is dropped for the destination
> > > affected by the conflict.
> > > So if a new advertisement is received after a while leading to a
> > > conflict, traffic will be blackholed for the affected destination
> >
> > [Bruno] From an editorial standpoint, I have chosen to describe the
> > options from a specification standpoint. So that those sections should
> > be non controvertials.
> > Discussion is done in §3.6 "Discussion".
> >
> > From a technical standpoint, I agree with you and this is discussed in
> > 3.6.2 'Network operation"
> >
> > >which is IMO not a good option.
> > [Bruno] Personally, I agree with you. I would even say that this is
> > not acceptable that a single typo in a MS advertisement shut down half
> > of the network.
> > But at this point in the document and discussion, I'd rather stick to
> > facts and remove opinions.
> >
> > > - §3.4 :
> > > [SLI] What happens if BGP sends the same SID ?
> >
> > [Bruno] At this point, I'm focusing to conflict within a single
> > protocol. Given the disagreements, I'd rather reduce the scope to
> simplify.
> > But I agree with you that this is a valid question.
> >
> > >
> > > -§3.5 :
> > >    [SLI] Maybe we need to remind that we already have a tiebreaking
> > > rule between MS entries and Prefix SIDs :
> > >    "For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
> > >    and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received,
> the
> > >    Prefix-SID advertised within the Prefix TLV MUST be preferred while
> > >    the MS entry MUST be ignored."
> > >
> > >    [SLI] Giving a preference to MS entries may be a very good idea from
> > >    an operational point of view, especially if someone wants to migrate
> > >    mappings from one range to another for example. This discussion is
> out of
> > >    scope but we may need to think about it.
> >
> > [Bruno] Excellent point. But as the resolutions rules proposed in
> > draft- ginsberg-spring-conflict-resolution do not seem achieve the
> > above goal, I had assume that this current text from
> > draft-ietf-isis-segment-routing- extensions would be removed and
> > replaced by the resolutions rules described in
> draft-ginsberg-spring-conflict-resolution.
> > Les, could you please clarify this point?
> >
> [Les:] I "think" you are referring to this text from the IS-IS draft
> (Section 2.4.5):
>
> " For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
>    and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the
>    Prefix-SID advertised within the Prefix TLV MUST be preferred while
>    the MS entry MUST be ignored."
>
> This text should be removed - the protocol drafts should simply reference
> the spring-conflict-resolution draft. Indeed one of the motivations for
> spring-conflict-resolution draft is to unblock the protocol drafts and
> isolate the conflict resolution to a single common draft. This means the
> protocol drafts MUST be agnostic and if they say anything at all it would
> be to reference spring-conflict-resolution draft.
>
>    Les
>
>
> >
> > > - there are multiple small typo issues in SRGB examples : e.g. Range
> > > 3: (500,
> > > 5990 <=> Range 3: (500, 599) ; Range 1: (100, 199] <=> Range 1:
> > > (100,
> > > 199)
> >
> > [Bruno] Thanks. Fixed. (at least I'm consistent in my typos ;-) (which
> > is expected when copy/pasting) )
> >
> >
> > >
> > > -----Original Message-----
> > > From: spring [mailto:[e-mail]] On Behalf Of
> > > [e-mail]
> > > Sent: Thursday, December 17, 2015 18:27
> > > To: [e-mail]; Les Ginsberg (ginsberg)
> > > Subject: [spring] draft-ginsberg-spring-conflict-resolution
> > >
> > > Hi Les, authors, WG
> > >
> > > As an individual contributor, please find below some more detailed
> > > comments and considerations on the draft.
> > >
> > > Following the "please send text" request expressed during the
> > > meeting, please find enclosed some proposed text. (xml, txt, diff
> > > versus public
> > version).
> > >
> > > I wished I had sent this before, but writing the text took longer
> > > than
> > expected.
> > > BTW I still not happy with my text, but hopefully current text  (or
> > > at least the table of content) should be enough to give an idea on
> > > the direction I have in mind.
> > >
> > > Thanks,
> > > Regards,
> > > Bruno
> > >
> > > __
> > > As previous expressed on the mailing list and during the meeting,
> > > I'm especially concerned with Mapping Server advertisement where a
> > > single typo/bug can conflict with many/all SIDs in the network. In
> > > this case, I don't think that dropping all traffic to those SIDs is a
> desirable option.
> > > One option is to prefer individual advertisement (prefix SID) over
> > > general ones (Mapping Server). i.e. more specific wins. Note that
> > > this is the approach currently taken by the IS-IS draft:
> > > "   For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
> > >    and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received,
> the
> > >    Prefix-SID advertised within the Prefix TLV MUST be preferred while
> > >    the MS entry MUST be ignored."
> > >
> > > We can probably assume that this is already implemented (by
> > > compliant implementations), so I'm not sure to see the value of
> > > changing existing implementations if this is to get a more
> > > disruptive result for the
> > network.
> > > __
> > > Regarding SID conflict, the current draft proposes to drop all
> > > conflicting information.
> > > Looking at the big picture, this means: the more (Mapping Server)
> > > redundancy, the more risk of conflict, the less availability.
> > > This is probably not the property that we are looking for.
> > > __
> > >
> > > I support the comment to consider the error handling work "recently"
> > > done in the IDR WG. IMHO, WG and authors did a good work on such a
> > > difficult subject (just like for SID conflicts, at the beginning
> > > opinions were diverse, and everyone had good reasons).
> > > I'm not sure how much reading the end result (RFC 7606) helps in
> > > understanding all the trade-off considered during the work. Reading
> > > the operational requirements, given that the IGP infrastructure is
> > > probably even more important than BGP for network
> > > operators/clients/traffic, it may be worthwhile to read BGP error
> > > handling operation requirements (
> > > https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-h
> > > an
> > > dling-07
> > > ) Discussion with the people involved may help. FYI, as for me, the
> > > point I learnt are:
> > > - when we detect an error on the receiving side, there is a bug. In
> > > general, it's difficult to know whether the bug is on the sending
> > > side or the
> > receiving side.
> > > Clearly, for the receiving side, the first reaction is to blame the
> > > sending
> > side.
> > > For each error, it's useful to consider both options (i.e. error may
> > > be on my/receiving side). And even if the error is on the sending
> > > side, the receiver may run the same implementation (so "sender is
> > > too buggy to live" may apply to your own implementation i.e. the
> > > receiving
> > side).
> > > - when we detect an error, it's useful to consider all possible
> > > causes and consequences before deciding to make things worse (e.g.
> > > killing a session/transit node/prefix). In particular, there may not
> > > be a single error but many (SIDs, source routers (especially if the
> > > error is on the receiving side)). So it's useful to consider that
> > > the decision may be
> > multiplied 10 or 100 times.
> > >
> > > Clearly there are difference between IGP & BGP: usually more
> > > redundancy in BGP (more signaling path (redundant RR) and more AS
> > > exit points), more prefixes hence the cost of dropping one prefix is
> > > relatively less important, two-way point to point signaling channel,
> > > messages are flooded unchanged so people are less likely to shoot
> > > the messenger and errors are less likely to be multiplied during
> propagation....
> > >
> > > __
> > > "An
> > >    alternative is to ensure at the nodes which originate these
> > >    advertisements that no such overlap is allowed to be configured.
> > >    Such overlaps can then be considered as a conflict if they are
> > >    received.  This allows a simpler and more efficient implementation
> of
> > >    the database.  This is the approach assumed in this document."
> > >
> > > I encourage implementation to check the configurations before
> > > accepting
> > it.
> > > And to check its routing advertisement before sending it. I would
> > > assume that state of the art implementation will do it. Yet, I don't
> > > think it should be considered as an excuse to avoid error handling
> > > at the
> > protocol level.
> > > BTW, I'm not sure how much you expect implementation checks to be
> > done
> > > before committing/sending. e.g. If an operator configure a range on
> > > the SRMS, and this ranges conflict with existing SID advertised by
> > > other nodes, would you expect the implementation to detect such
> > > conflict and reject the configuration?
> > > More generally, if we assume some extensive checks by
> > > implementations before committing/sending, and that given such
> > > assumption we define a light error handling, I'd like such
> > > assumptions be documented in the document and probably be made
> > > normative (since the receiving side, is expected a specific behavior
> from the sending side, this is normative).
> > > Also "implementation of the database" is implementation dependent
> > > and is probably just one aspect of the implementation
> simplicity/efficiency.
> > > And speaking for myself, simplicity/efficiency/availability of 100s
> > > networks running segment routing significantly out weight the
> > > "simplicity and efficiency" of one to ten implementations.
> > >
> > > __
> > > "The occurrence of conflicts is
> > >           easily diagnosed from the behavior of the network as the
> forwarding
> > >           of traffic which would, in the absence of conflicts, utilize
> > >           segments no longer does so."
> > >
> > > I don't think that we need to kill customer's traffic to raise
> > > awareness of the network operator. And I don't support the idea that
> > > the more traffic you kill, the easier and faster the error is resolved.
> > > If you need to raise an error, please do so! e.g. in logs, syslogs,
> > > SNMP traps, netconf event notification... Dropping the traffic is
> > > not providing more information, it is increasing the pressure and
> > > hence the probability of quick erroneous actions. Not to mention
> > > that as all services will run over packet networks, and as there is
> > > a pressure to reduce costs we may have a single converged network for
> all services.
> > > In this case, there is a chance that if the network is down, some
> > > people/tools/equipment may not be reached anymore/easily. e.g.
> > > calling people on their cell phone does not work when the packet
> > > network is
> > down.
> > >
> > > __
> > > "   The downside of ignoring conflicting entries is that forwarding of
> > >    all packets with destinations covered by the conflicting entries
> will
> > >    always be negatively impacted."
> > >
> > > Let's call a spade a spade. (btw, I prefer the French version
> > > :s/spade/cat which nowadays should be more popular on the Internet
> > > ;-)
> > > ) The traffic is not "negatively impacted", the traffic is "dropped".
> > > And for all services/customers/BGP routes using theses SIDs.
> > >
> > > __
> > > 3.2.2.  Preference Algorithm
> > > [...]
> > > "This approach requires that conflicting entries first be identified"
> > >
> > > All approach requires conflicting entries to be identified. This is
> > > not a drawback of the "preference algorithm"
> > >
> > > "Based on which  entry is preferred this in turn may impact what
> > > other entries are  considered in conflict"
> > >
> > > This is not additional rule/work. This is applying the same
> > > rule/algo to subsequent entries.
> > > Also, from the network perspective, in the end, this will not drop
> > > more entries than the "ignore rule", quite the contrary.
> > >
> > > "Based on
> > >           which entry is preferred this in turn may impact what other
> entries
> > >           are considered in conflict i.e. if A conflicts with B and B
> > >           conflicts with C - it is possible that A does NOT conflict
> with C.
> > >           Hence if as a result of the evaluation of the conflict
> between A and
> > >           B, entry B is not used the conflict between B and C will not
> be
> > >           considered."
> > >
> > > I'm not sure to get what is implied. As A and B conflicts and B and
> > > C conflicts, with "ignore conflicting entries", I would assume that
> > > all A, B, C be ignored, no? Or do you plan to ignore conflicting
> > > entries until there is no conflict? In which case we would only
> > > remove one of the two conflicting entries and end up with a
> > > "preference" resolution 'and never drop both conflicting entries
> > > since once we drop the first, there is no more conflict) ___
> > >
> > >
> > >
> > >
> > __________________________________________________________
> > __
> > >
> > __________________________________________________________
> > __
> > > _
> > >
> > > 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.
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>