Re: draft-ietf-rtgwg-spf-uloop-pb-statement

Chris Bowers <chrisbowers.ietf@gmail.com> Tue, 29 May 2018 02:28 UTC

Return-Path: <chrisbowers.ietf@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981812D947; Mon, 28 May 2018 19:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0GhOPf7uxw9; Mon, 28 May 2018 19:28:24 -0700 (PDT)
Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C18312D954; Mon, 28 May 2018 19:28:24 -0700 (PDT)
Received: by mail-yw0-x242.google.com with SMTP id b125-v6so1379765ywe.1; Mon, 28 May 2018 19:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FLZp79tjZ8dmwvlH1gvuIxZKfSc7WBFYUgR17EZEiNo=; b=poNzYaT10OnlNbo2YzFp6H1G+3wZwE1hWw2+QGALmR8XEdsRiKhR8SaWGe4ncNVb3e pC9ECfMkMy2DqtSszpYfpZ37szv0TDpTCTySPGL6juCxa7l7/3N2EWwlhzh7a1hufoyQ EYU2BDu6X7ohCYxSLnv1JycfmCH4CUwsfU1yx4SwsFVQCSq5qR9BaNGwghLR1HP4E1Id mBtNQ1v9Chwcfkxb60oCqLJjWkEhJLIPzgaYy+YB5o5gKE96TQviJ2lS9m5igcHXZsoU Szl4walRwnLgJKn0qWCxvqofdOnpw/L20kcN/gnrmu8WSsDWZBO61A047KuXvqYe3lAC vKjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FLZp79tjZ8dmwvlH1gvuIxZKfSc7WBFYUgR17EZEiNo=; b=gSfK9LzWYY8xvi9zIjU/183uonDKC6i0WuWG5SIZ9ewQ8km4aYtvQ4r49xwfcY98Qw 7z3YVawTd3FErxiIbf084Gmz61ggOdXX3uuZzZqOwfUngMFsTAJTdzP+bunkzayXUV2f +yKIUqh9rLJnnpx13coJOvXBzNrAT3c9O2gH1E6LObzadyTIciGQvlsHfvzTMaRsBpOK s6jq1e7xgoVzMaimHne7aKsIfkGv5kL0kvkC3+diNVzoprdpSZgnjwgtpP5kNSN1/aog L0TOn8zDYsluROHoc+6BZ2Amf3TUugcd7rLB2ch51DmpY+K2Z3rX8ErlT76UHnQOPOOh Lcmg==
X-Gm-Message-State: ALKqPwdlR8jfLcDTR9NxJU/fbY8Nr9hUVWzLnl12TEuwyikOrAtaBNYV yyy611Z+ejSNLoFOfOlpSVWFsef136o6X8Xpjwc=
X-Google-Smtp-Source: AB8JxZrAHZGQChwZXnvt6uYPacBGU/sPwVGCrPdexFeZ+OW7/tPNjEBDAelAQ7MlSw1gHHY3j5oyujuYl40UwF5mkEg=
X-Received: by 2002:a81:46d6:: with SMTP id t205-v6mr8315477ywa.481.1527560903246; Mon, 28 May 2018 19:28:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:4583:0:0:0:0:0 with HTTP; Mon, 28 May 2018 19:28:02 -0700 (PDT)
In-Reply-To: <4767_1527070553_5B053F59_4767_419_1_9E32478DFA9976438E7A22F69B08FF924B1607CE@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <CAHzoHbtneDuiWLpTy+pA1zYRGxQJLRx_jPz2wKLiwpN3_vZ5mQ@mail.gmail.com> <4767_1527070553_5B053F59_4767_419_1_9E32478DFA9976438E7A22F69B08FF924B1607CE@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Mon, 28 May 2018 21:28:02 -0500
Message-ID: <CAHzoHbsYEK=mkDqWkgoRDShE-OYuFWQazr8517gey7piMYV7og@mail.gmail.com>
Subject: Re: draft-ietf-rtgwg-spf-uloop-pb-statement
To: stephane.litkowski@orange.com
Cc: "draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org" <draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002c803056d4efd28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/bNKBrZB8cYDWQOdoTGOQVivvY80>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 02:28:29 -0000

Thanks.  The new revision addresses my comments.  I have completed the
shepherd write-up.

It can be found at:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/shepherdwriteup/

There are a few editing items mentioned in the shepherd write-up (and
copied below)
to be addressed in the next revision, but I will go ahead and submit it to
the IESG for publication.

Thanks,
Chris

The following two warnings should be addresed in a future revision.

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.
	
  == Outdated reference: draft-ietf-rtgwg-uloop-delay has been published as
     RFC 8333

All references have been identified as normative or informative.
There are currently 4 normative references.  Since this is
an informational document, it might make sense to classify some
or all of those references as in informative.



On Wed, May 23, 2018 at 5:15 AM, <stephane.litkowski@orange.com> wrote:

> Hi Chris,
>
>
>
> I have uploaded a new revision. Let me know if it correctly addresses your
> comments.
>
>
>
> Brgds,
>
>
>
>
>
> *From:* Chris Bowers [mailto:chrisbowers.ietf@gmail.com]
> *Sent:* Monday, April 16, 2018 22:02
> *To:* draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; RTGWG
> *Subject:* draft-ietf-rtgwg-spf-uloop-pb-statement
>
>
>
> As part of doing the shepherd write-up for this document, I did a review
> of the draft.
>
>
> My comments are shown below as a diff on draft-ietf-rtgwg-spf-uloop-pb-
> statement-06.txt.
>
> They can also be viewed at:
> https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2018/commit/
> c1c5018f857e9c7c0f4123c3de1e87041178e387
>
> Thanks,
> Chris
>
> =============
>
> diff --git a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt
> b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt
> index 353ce3c..3dff746 100644
> --- a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt
> +++ b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt
> @@ -21,7 +21,16 @@ Abstract
>
>     In this document, we are trying to analyze the impact of using
>     different Link State IGP implementations in a single network in
> -   regards of micro-loops.  The analysis is focused on the SPF triggers
> +   regards of micro-loops.
> +
> +=======
> +[CB]
> +   In this document, we are trying to analyze the impact of using
> +   different Link State IGP implementations in a single network, with
> +   respect to micro-loops.
> +
> +========
> +   The analysis is focused on the SPF triggers
>     and SPF delay algorithm.
>
>  Requirements Language
> @@ -95,13 +104,39 @@ Table of Contents
>     Link State IGP protocols are based on a topology database on which an
>     SPF (Shortest Path First) algorithm like Dijkstra is implemented to
>     find the optimal routing paths.
> -
> +
> +   =====
> +  [CB] proposed modified text since the Shortest Path First algorithm and
> +   Djikstra algorithm are essentially synonomous.  Also propose to use
> +   "consistent set of non-looping routing paths", since shortest path
> routing
> +   is often not optimal from a traffic engineering perspective.
> +
> +   [proposed text]
> +   Link State IGP protocols are based on a topology database on which the
> +   SPF (Shortest Path First) algorithm is run to
> +   find a consistent set of non-looping routing paths.
> +
> +   =====
> +
>     Specifications like IS-IS ([RFC1195]) propose some optimizations of
>     the route computation (See Appendix C.1) but not all the
>     implementations are following those not mandatory optimizations.
>
> +============
> +[CB]  [proposed text]
> +but not all implementations follow those non-mandatory
> +optimizations.
> +=============
> +
>     We will call "SPF trigger", the events that would lead to a new SPF
>     computation based on the topology.
> +
> +============
> +[CB]  [proposed text]
> +   We will call "SPF triggers", the events that would lead to a new SPF
> +   computation based on the topology.
> +=============
> +
>
>     Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS
>     ([RFC1195]), are using multiple timers to control the router behavior
> @@ -118,11 +153,27 @@ Internet-Draft                spf-microloop
>         January 2018
>
>     Some of those timers are standardized in protocol specification, some
>     are not especially the SPF computation related timers.
> +
> +============
> +[CB] [proposed text]
> +   Some of those timers are standardized in protocol specification, while
> some
> +   are not.  The SPF computation related timers have generally remained
> +   unspecified.
> +=============
>
>     For non standardized timers, implementations are free to implement it
>     in any way.  For some standardized timer, we can also see that rather
>     than using static configurable values for such timer, implementations
>     may offer dynamically adjusted timers to help controlling the churn.
> +
> +============
> +[CB] In the dicussion above, it is unclear about what the meaning of
> "timer" is.
> +Is it the numerical value of a timer?  Is it the trigger conditions and
> logic
> +for a timer to start or be reset?  Is the the action taken when the timer
> expires?
> +Perhaps the text could clarified by referring to "timer behavior" and
> "timer values"
> +
> +=============
> +
>
>     We will call "SPF delay", the timer that exists in most
>     implementations that specifies the required delay before running SPF
> @@ -138,6 +189,17 @@ Internet-Draft                spf-microloop
>       January 2018
>     Some micro-loop mitigation techniques have been defined by IETF (e.g.
>     [RFC6976], [I-D.ietf-rtgwg-uloop-delay]) but are not implemented due
>     to complexity or are not providing a complete mitigation.
> +
> +==========
> +[CB]
> +This paragraph needs to be clearer.
> +[proposed text]
> +   Two micro-loop mitigation techniques have been defined by the IETF.
> +   [RFC6976] has not been widely implemented, presumably due to the
> complexity
> +   of the technique.  [I-D.ietf-rtgwg-uloop-delay] has been implemented.
> +   However, it does not prevent all micro-loops that can occur
> +   for a given topology and failure scenario.
> +==========
>
>     In multi-vendor networks, using different implementations of a link
>     state protocol may favor micro-loops creation during the convergence
> @@ -185,17 +247,24 @@ Internet-Draft                spf-microloop
>         January 2018
>     will forward the traffic to C through B, but as B as not converged
>     yet, B will loop back traffic to A, leading to a micro-loop.
>
> +========
> +[CB]
> +Figure 1 and figure 4 are essentially the same topology, but the nodes
> +have different names.  I think it would be much better for the reader of
> this
> +document to consolidate the two figures into a single figure.
> +========
> +
>     The micro-loop appears due to the asynchronous convergence of nodes
>     in a network when an event occurs.
>
> -   Multiple factors (and combination of these factors) may increase the
> +   Multiple factors (or a combination of these factors) may increase the
>     probability for a micro-loop to appear:
>
>     o  the delay of failure notification: the more B is advised of the
>        failure later than A, the more a micro-loop may have a chance to
>        appear.
>
> -   o  the SPF delay: most of the implementations supports a delay for
> +   o  the SPF delay: most implementations support a delay for
>        the SPF computation to try to catch as many events as possible.
>        If A uses an SPF delay timer of x msec and B uses an SPF delay
>        timer of y msec and x < y, B would start converging after A
> @@ -204,8 +273,8 @@ Internet-Draft                spf-microloop
>       January 2018
>     o  the SPF computation time: mostly a matter of CPU power and
>        optimizations like incremental SPF.  If A computes its SPF faster
>        than B, there is a chance for a micro-loop to appear.  CPUs are
> -      today faster enough to consider SPF computation time as
> -      negligeable (order of msec in a large network).
> +      today fast enough to consider SPF computation time as
> +      negligible (on the order of milliseconds in a large network).
>
>     o  the SPF computation order: an SPF trigger can be common to
>        multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for
> @@ -215,8 +284,8 @@ Internet-Draft                spf-microloop
>       January 2018
>        done in A and B for each area/level/topology/SPF-algorithm is
>        different, there is a possibility for a micro-loop to appear.
>
> -   o  the RIB and FIB prefix insertion speed or ordering: highly
> -      implementation dependant.
> +   o  the RIB and FIB prefix insertion speed or ordering.  This is highly
> +      dependent on the implementation.
>
>
>
> @@ -225,22 +294,21 @@ Litkowski, et al.         Expires July 28, 2018
>             [Page 4]
>  Internet-Draft                spf-microloop                 January 2018
>
>
> -   This document will focus on analysis SPF delay (and associated
> -   triggers).
> +   This document will focus on analysis of the SPF delay behavior and the
> associated
> +   triggers.
>
>  3.  SPF trigger strategies
>
> -   Depending of the change advertised in LSP/LSA, the topology may be
> +   Depending on the change advertised in an LSPDU or LSA, the topology
> may be
>     affected or not.  An implementation may avoid running the SPF
>     computation (and may only run IP reachability computation instead) if
> -   the advertised change is not affecting topology.
> +   the advertised change does not affect the topology.
>
>     Different strategies exists to trigger the SPF computation:
>
> -   1.  An implementation may always run a full SPF whatever the change
> -       to process.
> +   1.  An implementation may always run a full SPF for any type of change.
>
> -   2.  An implementation may run a full SPF only when required: e.g. if
> +   2.  An implementation may run a full SPF only when required.  For
> example, if
>         a link fails, a local node will run an SPF for its local LSP
>         update.  If the LSP from the neighbor (describing the same
>         failure) is received after SPF has started, the local node can
> @@ -250,26 +318,28 @@ Internet-Draft                spf-microloop
>         January 2018
>     3.  If the topology does not change, an implementation may only
>         recompute the IP reachability.
>
> -   As pointed in Section 1, SPF optimizations are not mandatory in
> -   specifications, leading to multiple strategies to be implemented.
> +   As noted in Section 1, SPF optimizations are not mandatory in
> +   specifications.  This has led to the implementation of
> +   different strategies.
>
>  4.  SPF delay strategies
>
>     Implementations of link state routing protocols use different
> -   strategies to delay the SPF computation.  We usually see the
> -   following:
> +   strategies to delay the SPF computation.  The two most
> +   common SPF delay behaviors are the following.
>
> -   1.  Two steps delay.
> +   1.  Two phase delay.
>
>     2.  Exponential backoff delay.
>
> -   Those behavior will be explained in the next sections.
> +   These behaviors are described in the following sections.
>
> -4.1.  Two steps SPF delay
> +4.1.  Two phase SPF delay
>
> -   The SPF delay is managed by four parameters:
> +   For the two phase SPF delay, the SPF delay is managed by four
> parameters:
>
> -   o  Rapid delay: amount of time to wait before running SPF.
> +   o  Rapid delay: amount of time to wait before running SPF, after the
> +   initial SPF trigger event.
>
>
>
> @@ -281,13 +351,13 @@ Litkowski, et al.         Expires July 28, 2018
>             [Page 5]
>  Internet-Draft                spf-microloop                 January 2018
>
>
> -   o  Rapid runs: amount of consecutive SPF runs that can use the rapid
> -      delay.  When the amount is exceeded the delay moves to the slow
> +   o  Rapid runs: the number of consecutive SPF runs that can use the
> rapid
> +      delay.  When the number is exceeded, the delay moves to the slow
>        delay value .
>
>     o  Slow delay: amount of time to wait before running SPF.
>
> -   o  Wait time: amount of time to wait without events before going back
> +   o  Wait time: amount of time to wait without receiving SPF trigger
> events before going back
>        to the rapid delay.
>
>     Example: Rapid delay = 50msec, Rapid runs = 3, Slow delay = 1sec,
> @@ -308,7 +378,9 @@ Internet-Draft                spf-microloop
>       January 2018
>             |  |   |  | || |            |
>                             < wait time >
>
> -                   Figure 2 - Two steps delay algorithm
> +                   Figure 2 - Two phase delay algorithm
> +
> +
>
>  4.2.  Exponential backoff
>
> @@ -394,13 +466,20 @@ Internet-Draft                spf-microloop
>         January 2018
>
>
>     for delaying PRC.  We consider that E is using a SPF trigger strategy
> -   that always compute Full SPF and exponential backoff strategy for SPF
> +   that always computes a Full SPF for any change,  and uses the
> exponential backoff strategy for SPF
>     delay (start=150ms, inc=150ms, max=1s)
>
>     We also consider the following sequence of events (note : the time
>     scale does not intend to represent a real router time scale where
>     jitters are introduced to all timers) :
>
> +==========
> +[CB]
> +This note about jitter and time scale (or timeline) is not clear.  I
> suggest describing
> +it in more detail or deleting it.
> +==========
> +
> +
>     o  t0=0 ms: a prefix is declared down in the network.  We consider
>        this event to happen at time=0.
>
> @@ -487,12 +566,12 @@ Internet-Draft                spf-microloop
>         January 2018
>                      Route computation event time scale
>
>     In the table above, we can see that due to discrepancies in the SPF
> -   management, after multiple events (of a different type), the values
> -   of the SPF delay are completely misaligned between nodes leading to
> -   long micro-loops creation.
> +   management, after multiple events of a different type, the values
> +   of the SPF delay are completely misaligned between node S and node E,
> +   leading to the creation of micro-loops.
>
> -   The same issue can also appear with only single type of events as
> -   displayed below:
> +   The same issue can also appear with only a single type of event as
> +   shown below:
>
>     +--------+--------------------+------------------+------------------+
>     |  Time  |   Network Event    | Router S events  | Router E events  |
> @@ -587,6 +666,28 @@ Internet-Draft                spf-microloop
>       January 2018
>
>  6.  Proposed work items
>
> +===============
> +[CB]
> +Since we are publishing this document after the SPF backoff algorithm
> +draft is published, I think the list of three proposed work items below
> will be
> +confusing.  Someone reading this RFC will wonder why the
> +SPF backoff algorithm RFC (which will have an earlier RFC number)
> +doesn't satisfy the list of proposed work items.
> +
> +Perhaps this section should be renamed something like
> +"Benefits of standardized SPF delay behavior", and the list of proposed
> +work items should be removed.
> +
> +It may also make sense to explicitly say that the
> +SPF backoff algorithm draft/RFC is a solution that
> +satisfies this problem statement.
> +And that we are publishing the document in order to
> +capture the reasoning that led to that draft.  Text to this
> +effect should probably go in the introduction, instead
> +of this section.
> +
> +===============
> +
>     In order to enhance the current Link State IGP behavior, authors
>     would encourage working on standardization of some behaviours.
>
> @@ -603,14 +704,23 @@ Internet-Draft                spf-microloop
>         January 2018
>
>     Using the same event sequence as in figure 2, we may expect fewer
>     and/or shorter micro-loops using standardized implementations.
> +
> +===========
> +[CB] I think the text should refer to one of the previous tables and not
> Figure 2.
> +Figure 2 shows the two step delay algorithm.
> +===========
>
>     +--------+--------------------+------------------+------------------+
>     |  Time  |   Network Event    | Router S events  | Router E events  |
>     +--------+--------------------+------------------+------------------+
>     |  t0=0  |    Prefix DOWN     |                  |                  |
>     |  10ms  |                    | Schedule PRC (in | Schedule SPF (in |
> -
> -
> +
> +===========
> +[CB]
> +It seems like there is a typo here.  Presumably router E should schedule a
> +PRC (not an SPF) at 10ms in this table.
> +===========
>
>  Litkowski, et al.         Expires July 28, 2018                [Page 11]
>  ^L
> @@ -677,13 +787,48 @@ Internet-Draft                spf-microloop
>         January 2018
>     +--------+--------------------+------------------+------------------+
>
>                      Route computation event time scale
> -
> +
> +=============
> +[CB]
> +I think the term "time scale" throughout this document is not the right
> one.
> +Perhaps the term "timeline" would be better or the phrase "sequence of
> events".
> +=============
> +[CB]
> +There are several different tables with the same caption
> +"Route computation event time scale".
> +Regardless of the replacement term for "time scale", it would be helpful
> to make a
> +distinction between the tables with each caption.  For example, this last
> +table could have a caption like "Route computation when S and E use the
> +same standardized behavior".
> +
> +==========
>     As displayed above, there could be some other parameters like router
>     computation power, flooding timers that may also influence micro-
>     loops.  In Figure 4, we consider E to be a bit slower than S, leading
> -   to micro-loop creation.  Despite of this, we expect that by aligning
> +   to micro-loop creation.
> +
> +=================
> +[CB]
> +There is nothing in Figure 4 that shows that that E is slower than S.
> +Perhaps it would be clearer to say something like:
> +"In all of the
> +examples in this document comparing the SPF timer behavior of
> +router S and router E, we have made router E a bit slower than
> +router S.  This can lead to microloops even when both S and E use
> +a common standardized SPF behavior.
> +=================
> +
> +
> +   Despite of this, we expect that by aligning
>     implementations at least on SPF trigger and SPF delay, service
>     provider may reduce the number and the duration of micro-loops.
> +===================
> +[CB]
> +"Despite of this" should read "In spite of this" or "Despite this".
> +Or in this case "However" might be better.
> +
> +s/service provider/service providers/
> +==================
>
>  7.  Security Considerations
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>