Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

Greg Mirsky <gregimirsky@gmail.com> Thu, 04 April 2019 23:05 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF361200CE; Thu, 4 Apr 2019 16:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 SYZITIzECwRp; Thu, 4 Apr 2019 16:04:59 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6FC32120090; Thu, 4 Apr 2019 16:04:57 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id a6so2992566lfl.5; Thu, 04 Apr 2019 16:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NM5jXCWVT3WWQJjeTt05C6nw2p0Ayg0YobTfhKYEzYM=; b=SoAGQ24sTqFqPaR4WG8+hohnydyvVKllm2Aj6K8BmodEGXPYKwpssHAVNnrdi1XSxk 0qBYOCNjKDVQFdlxQCy+ttKlCb+GTiAu8LcJ1xXw7l49BvKVB+F9jD0UEtIY0QcCM4AD 5AjohK4sICQY+u0rmoJjIjF3dzQ5IwnrXaSxtv/bs8eEATJ1CX8u/92B6ANOknfaXRqt iwRd7/PCy7CvQB5kAB4h0zMQDYOb8BD7Q1yGBRDeLhAMrI4tWp1xcugyLH8d5Em5VB3O GNShrqoVlGPHnuZlzR9fyCHrUhMP4X+ZA8S8gRFpeeEl48tU0F3MjQzXynIrPbGn+VAg asdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NM5jXCWVT3WWQJjeTt05C6nw2p0Ayg0YobTfhKYEzYM=; b=fMAZKRUdR9e0mnlNDxNIvb5gX5GkN1NgnBOGtGrKMFHwm+lx70UZSs0SqbbI9ivUYg SEQU1A3tqY/3TuqC0JBebcaN78EZaOVtM9FhDNFgiXqqEeu7h/30G7sSfxoDo5p7s1vW KBkE1UwjptsYN1bMW94Eqj+UmPmXI9nY7w+To1PuV29KZ3G+HPRvYygGfixJaAc6fkrQ E7mVmlfdHaS5lD1RDn+HPkuUP6rNsDzN0e56iJ3ZIBAVecD0Je65JPeDxxk0z2UB34q0 BgfanRNpSekbx+qqBSk1DVc3Idh2xnwd+QIq/egMT16zxMo2KiHQH1C0oyamze1+Fz66 8Qlw==
X-Gm-Message-State: APjAAAX8phjwKid3LSole+vQgyhATpX7TjXgH4CGM29Z9bpDYypG7BU9 8WuxfXQyOEVMhrJr0/ndQBz+VHHbvKBi6iXKqqU=
X-Google-Smtp-Source: APXvYqzc14jtQujJekAw9DJjtkb2ujnnmYUaOjM/cAR0KjVmnRCkllfYkZ2kT2oy2j2bXIRDPP+quXJwubMu5sChedc=
X-Received: by 2002:a19:4b14:: with SMTP id y20mr4465321lfa.36.1554419095342; Thu, 04 Apr 2019 16:04:55 -0700 (PDT)
MIME-Version: 1.0
References: <26502_1542873261_5BF660AD_26502_47_1_9E32478DFA9976438E7A22F69B08FF924B7752E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <BL0PR05MB5025A934922FDDC316AFD2E4D4AC0@BL0PR05MB5025.namprd05.prod.outlook.com> <CA+RyBmXcu3b9dObX=G9vyHNJtEuJ4wWqMtQXvxCNxgNOSCsmWw@mail.gmail.com> <CO2PR05MB24550CC9932A560B1DC7B19BD44B0@CO2PR05MB2455.namprd05.prod.outlook.com>
In-Reply-To: <CO2PR05MB24550CC9932A560B1DC7B19BD44B0@CO2PR05MB2455.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 4 Apr 2019 16:04:42 -0700
Message-ID: <CA+RyBmV6oigz+ODY9C6QEqkDQY1X+x=yDpWqPoiODyyqVeTwHA@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Robert Kebler <rkebler@juniper.net>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Content-Type: multipart/mixed; boundary="00000000000002be6a0585bc66a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/1Jd7Oqxo9pEjslvxxkEVheMxiPw>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 23:05:08 -0000

Hi Jeffrey,
many thanks to you and Sandy for taking the time to review the remaining
questions in Prague. Attached please find the updated version -06 and its
diff to highlight the latest changes.

Regards,
Greg

On Thu, Mar 14, 2019 at 3:04 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Thomas, Bob,
>
>
>
> Some questions below for you. Some old, and some new.
>
>
>
> Greg,
>
>
>
> Sorry for the late response.
>
> Please see zzh> below. I trimmed some points that we agree on.
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Wednesday, December 5, 2018 1:38 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* EXT - thomas.morin@orange.com <thomas.morin@orange.com>om>; Robert
> Kebler <rkebler@juniper.net>et>; bess-chairs@ietf.org; BESS <bess@ietf.org>
> *Subject:* Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-mvpn-fast-failover
>
>
>
> Hi Jeffrey,
>
> thank you for the review, detailed questions and helpful comments. Please
> find my notes, answers in-line tagged GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> Hi,
>
>
>
> I have the following questions/comments:
>
>
>
>    The procedure described here is an OPTIONAL procedure that consists
>
>    of having a downstream PE take into account the status of P-tunnels
>
>    rooted at each possible upstream PEs, for including or not including
>
>    each given PE in the list of candidate UMHs for a given (C-S,C-G)
>
>    state.  The result is that, if a P-tunnel is "down" (see
>
>    Section 3.1), the PE that is the root of the P-tunnel will not be
>
>    considered for UMH selection, which will result in the downstream PE
>
>    to failover to the upstream PE which is next in the list of
>
>    candidates.
>
>
>
> Is it possible that a p2mp tunnel is considered up by some leaves but down
> by some other leaves, leaving to them choosing different UMH? In that case,
> procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE")
> of RFC 6513 must be used. I see that this is actually pointed out later in
> section 6 – good to have a pointer to it right here.
>
> GIM>> Would the following new text that follows the quoted text address
> your concern:
>
> NEW TEXT:
>
>    If rules to determine the state of the P-tunnel are not
>
>    consistent across all PEs, then some may arrive at a different
>
>    conclusion regarding the state of the tunnel, In such a scenario,
>
>    procedures described in Section 9.1.1 of [RFC 6513] MUST be used
>


> GIM>> Accepted
>



> Zzh> It’s not that the “rules … are not consistent”. It’s that by nature
> some PEs may think the tunnel is down while the others may think the tunnel
> is still up (because they’re on different tunnel branches), even when they
> follow the same rules. Traffic duplication in this case is also only with
> inclusive tunnels – so how about the following?
>
>
>
>    Because all PEs may arrive at a different
>
>    conclusion regarding the state of the tunnel,
>
>    procedures described in Section 9.1.1 of [RFC 6513] MUST be used
>
>    when using inclusive tunnels.
>
>
>
> Additionally, the text in section 3 seems to be more biased on Single
> Forwarder Election choosing the UMH with the highest IP address. Section 5
> of RFC6513 also describes two other options, hashing or based on “installed
> UMH route” (aka unicast-based). It is not clear how the text in this
> document applies to hashing based selection, and I don’t see how the text
> applies to unicast-based selection. Some rewording/clarification are needed
> here.
>
> GIM>> How would the use of an alternative UMH selection algorithm change
> documented use of p2mp BFD? Do you think that if the Upstream PE selected
> using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself
> no longer applicable?
>
>
>
> Zzh> It’s not that the alternative UMH selection algorithm change
> documented use of p2mp BFD. It’s the other way around – tunnel state
> changes the selection result. I guess hashing can still be used (this
> document only controls what goes into the candidate pool). For unicast
> based selection I thought it’d no longer work, but then I noticed the
> following:
>
>
>
>    o  second, the UMH candidates that advertise a PMSI bound to a tunnel
>
>       that is "down" -- these will thus be used as a last resort to
>
>       ensure a graceful fallback to the basic MVPN UMH selection
>
>       procedures in the hypothetical case where a false negative would
>
>       occur when determining the status of all tunnels
>
>
>
> Zzh> So this should still work, although Ideally, the PE advertising the
> next best route should be considered before going to the last resort (of
> using the PE advertising the best route but whose tunnel is down).
>
>
>
>    For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
>
>    considered up if one or more of the P2MP RSVP-TE LSPs, identified by
>
>    the P-tunnel Attribute, are in Up state.
>
>
>
> Why is “one or more of …” used in the above text?
>
> GIM>> Clariy "to the same PE"

> GIM>> Would s/one or more of/at least one of/ address your concern?
>
>
>
> Zzh> Still confused. From the tunnel head, indeed it could send setup
> multiple (sub-)LSPs, one for each leaf. From the egress point of view,
> there is only one LSP for an egress PE, right?
>
>
>
>    If tracking of the P-tunnel by using a p2mp BFD session is to be
>
>    enabled after the P-tunnel has been already signaled, the the
>
>    procedure described above MUST be followed.
>
>
>
> What if the tracking is to be enabled before the P-tunnel has been
> signaled? The text implies different behavior?
>
> GIM>> Not really, I guess. I think that the second sentence is important:
>
>    Note that x-PMSI A-D Route MUST be re-sent with exactly the same
> attributes as before and
>
>    the BGP-BFD Attribute included.
>
>
>
> Zzh> In that case, how about changing the paragraph and the next one to
> the following:
>
>
>
>    If tracking of the P-tunnel by using a p2mp BFD session is
>
>   enabled after the x-PMSI A-D route has been already advertised,
>
>    the x-PMSI A-D
>
>    Route MUST be re-sent with exactly the same attributes as before and
>
>    the BGP-BFD Attribute included.
>
>
>
>    If the x-PMSI A-D route is advertised with P-tunnel status tracked
> using
>
>    the p2mp BFD session and it is desired to stop tracking P-tunnel
>
>    status using BFD, then:
>
>
> GIM>> Agree


> zzh> BTW, the same applies to 3.1.7 as well.
>
GIM>> Agree

>
>
>    When such a procedure is used, in the context where fast restoration
>
>    mechanisms are used for the P-tunnels, leaf PEs should be configured
>
>    to wait before updating the UMH, to let the P-tunnel restoration
>
>    mechanism happen.  A configurable timer MUST be provided for this
>
>    purpose, and it is recommended to provide a reasonable default value
>
>    for this timer.
>
>
>
> What does “such a procedure” refers to?
>
> GIM>> Would s/When such a procedure is used/In such a scenario/
>
>
>
> Zzh> I looked at the surrounding (new) text:
>
>
>
>    If the Downstream PE's P-tunnel is already up, its state being
>
>    monitored by the p2mp BFD session, and the Downstream PE receives the
>
>    new x-PMSI A-D Route without the BGP-BFD Attribute, the Downstream
>
>    PE:
>
>
>
>    o  MUST accept the x-PMSI A-D Route;
>
>
>
>    o  MUST stop receiving BFD control packets for this p2mp BFD session;
>
>
>
>    o  SHOULD delete the p2mp BFD session associated with the P-tunnel;
>
>
>
>    o  SHOULD NOT switch the traffic to the Standby Upstream PE.
>
>
>
>    In such a scenario, in the context where fast restoration mechanisms
>
>    are used for the P-tunnels, leaf PEs should be configured to wait
>
>    before updating the UMH, to let the P-tunnel restoration mechanism
>
>    happen.
>
GIM>> Remove the last paragraph?

>
>
> Zzh> Now I have the following two questions:
>
> Zzh> a) Should the “MUST stop receiving BFD control packets for this p2mp
> BFD session” be removed? How would you “stop receiving BFD control
> packets”? Isn’t it implied by the next bullet point already?
>
> Zzh> b) What does the last clause “to let the P-tunnel restoration
> mechanism happen” mean? The scenario is that an x-PMSI route update is
> received w/o the BGP-BFD attribute – where does the tunnel restoration come
> from?
>
>
>
> 3.1.7.  Per PE-CE link BFD Discriminator
>
>
>
>    The following approach is defined for the fast failover in response
>
>    to the detection of PE-CE link failures, in which UMH selection for a
>
>    given C-multicast route takes into account the state of the BFD
>
>    session associated with the state of the upstream PE-CE link.
>
>
>
> 3.1.7.1.  Upstream PE Procedures
>
>
>
>    For each protected PE-CE link, the upstream PE initiates a multipoint
>
>    BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward
>
>    downstream PEs.  A downstream PE monitors the state of the p2mp
>
>    session as MultipointTail and MAY interpret transition of the BFD
>
>    session into Down state as the indication of the associated PE-CE
>
>    link being down.
>
>
>
> Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my
> understanding is that the BFD discriminator is still for the tunnel and not
> tied to the PE-CE link; but different from the previous case, the root will
> stop sending BFD messages when it detects the PE-CE link failure. As far as
> the egress PEs are concerned, they don’t know if it is the tunnel failure
> or PE-CE link failure.
>
>
>
> If my understanding is correct, the wording should be changed.
>
> GIM>> There are other than stopping transmission of BFD control packets
> ways to distinguish two conditions for the egress PE. For example, the
> MultipointHead MAY set the State to AdminDown and continue sending BFD
> control packets. If and when PE-CE link restored to Up, the MultipointHead
> can set the state to Up in the BFD control packet.
>
>
>
>    …  If the route to the
>
>    src/RP changes such that the RPF interface is changed to be a new PE-
>
>    CE interface, then the upstream PE will update the S-PMSI A-D route
>
>    with included BGP-BFD Attribute so that value of the BFD
>
>    Discriminator is associated with the new RPF link.
>
>
>
> If the RPF interface changes on the upstream PE, why should it update the
> route to send a new discriminator? As long as there is a new RPF interface
> couldn’t the upstream PE do nothing but start tracking the new RPF
> interface?
>
> GIM>> I'll defer this one to Thomas and Rob.
>
>
>
> Zzh> I re-read section 3.1.6 and 3.1.7 and have more questions 😊
>
> Zzh> 3.1.6 seems to be about tracking tunnel itself while 3.1.7 is about
> tracking PE-CE interfaces. From an egress point of view, (how) does it know
> if the discriminator is for the tunnel or for PE-CE interface 1 or PE-CE
> interface 2? Does it even care? It seems to me that an egress PE would not
> need to care. If so, why are there different procedures for 3.1.6/3.1.7 (at
> least for the egress PE behavior)? Even for the upstream PE behavior,
> shouldn’t 3.1.6.1 apply to 3.1.7 as well?
>
GIM>> Added the following text to the first paragraph of section 3.1.7:
NEW TEXT:
The mechanism to communicate the mapping between the PE-CE link
and the associated BFD session is outside the scope of this document.

>
>
> Regardless which way (the currently described way and my imagined way),
> some text should be added to discuss how the downstream would not switch to
> another upstream PE when the primary PE is just going through a RPF change.
>
> GIM>>  Would appending the following text be acceptable to address your
> concern:
>
> NEW TEXT:
>
>    To avoid unwarranted switchover a downstream PE MUST gracefully handle
> the
>
>    updated S-PMSI A-D route and switch to the use of the associated BFD
>
>    Discriminator value.
>
>
>
> 4.  Standby C-multicast route
>
>
>
>    The procedures described below are limited to the case where the site
>
>    that contains C-S is connected to exactly two PEs. The procedures
>
>    require all the PEs of that MVPN to follow the single forwarder PE
>
>    selection, as specified in [RFC6513].
>
>
>
>
>
> Why would it not work with more than two upstream PEs?
>
> Why is it limited to single forwarder selection? What about unicast based
> selection?
>
> GIM>> Again, asking for Thomas and Rob to help.
>
>
>
>    If at some later point the local PE determines that C-S is no longer
>
>    reachable through the Primary Upstream PE, the Standby Upstream PE
>
>    becomes the Upstream PE, and the local PE re-sends the C-multicast
>
>    route with RT that identifies the Standby Upstream PE, except that
>
>    now the route does not carry the Standby PE BGP Community (which
>
>    results in replacing the old route with a new route, with the only
>
>    difference between these routes being the presence/absence of the
>
>    Standby PE BGP Community).
>
>
>
> Additionally the LOCAL_PREF should also change?
>
> GIM>> Like normative SHOULD?
>
>
>
> Zzh> I meant that there should also be text talking about changing
> LOCAL_PREF.
>
GIM>> Added to the paragraph:
NEW TEXT:
Also, a LOCAL_PREF attribute MUST be set to zero.

> 5.  Hot leaf standby
>
>
>
>    The mechanisms defined in sections Section 4 and Section 3 can be
>
>    used together as follows.
>
>
>
> This section is a little confusing to me. It seems that it really should
> be how a leaf should behave when hot root standby is used, not that there
> is a “hot leaf” mode. A leaf is just a leaf, not a
> cold/warm/hot/primary/standby leaf.
>
> GIM>> Would re-naming the section to "Use of Standby C-multicast Route" better
> reflect the content of the section?
>
>
>
> Zzh> It seems to me that the title should really be changed to “Hot Root
> Standby”. Bob/Thomas?
>
GIM>> Agree

>
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
> *From:* BESS <bess-bounces@ietf.org> *On Behalf Of *
> stephane.litkowski@orange.com
> *Sent:* Thursday, November 22, 2018 2:54 AM
> *To:* bess@ietf.org
> *Cc:* bess-chairs@ietf.org
> *Subject:* [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-mvpn-fast-failover
>
>
>
> Hello Working Group,
>
>
>
> This email starts a two-week Working Group Last Call on
> draft-ietf-bess-mvpn-fast-failover-04  [1]
>
>
>
> This poll runs until *the 6th of December*.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this Document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> Currently two IPRs have been disclosed against this Document.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2].
>
>
>
>     Thank you,
>
>     Stephane & Matthew
>
>
>
>     [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dfast-2Dfailover_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=21UeMvv2ofELpScacCIlRV64tml5G3zQ3NN5NqhC90s&s=ZKwzFkFZdTKGHJdgRZ6PExBQcl1Ck5CGjhXDxYQYvvI&e=>
>
>
>
>     [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bess_cG3X1tTqb-5FvPC4rg56SEdkjqDpw&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=21UeMvv2ofELpScacCIlRV64tml5G3zQ3NN5NqhC90s&s=fR1eK_EmnRha7QRf37WKaJmt1F5OLq7ynG7afcmPhM0&e=>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>