Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Shraddha Hegde <shraddha@juniper.net> Fri, 11 September 2020 11:43 UTC

Return-Path: <shraddha@juniper.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49473A0F18; Fri, 11 Sep 2020 04:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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=juniper.net header.b=QuzxLsdD; dkim=pass (1024-bit key) header.d=juniper.net header.b=lDOyu9m2
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 zr1gIZGkxVX3; Fri, 11 Sep 2020 04:43:12 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED8B3A0ED5; Fri, 11 Sep 2020 04:43:12 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08BBhAtp020907; Fri, 11 Sep 2020 04:43:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=PpYTWeSxbhBa8/uyi9MqEWZKupORPd6nh/EgU9UrT04=; b=QuzxLsdDfAwkLsBwkc5qbSdVeRnkqU36n97pMZz+zRwmBlQ+R9eWmYkD/C7bWQDyGWWv k5iwqBz0HRYS5f1p1Tv+ffLtVcfpT10zz9raGTiY+XL3XRPmK9rL/s2Sl59gRVCywpc6 u5xQlkzQwo1uJypuvk8HOWYQP0SlH8Npw80SAQTu/hcxvba06P38u2evmYMWRi3uRDrt +9YmixlugGZKd5UxVF6bbB1t5H8fAYdgYTrWOF1T4lBg3cv3bBXI747yWr6XWXLjnmPN jLkIRqk7f9Tdx6/AGwTDSd2iXK/C4LiWaLE0C6GPXsYmATt45nBB2ndS2YGH4fLLqTYM 3Q==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2057.outbound.protection.outlook.com [104.47.36.57]) by mx0b-00273201.pphosted.com with ESMTP id 33cs9h95rf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Sep 2020 04:43:10 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dKJKw43v6wtc5s+lp24ScUrdowzE0o1zzaV2nRjXKjY018Ap4fTKIy4Y/gArnE2JoKezWs+JCP7noV9Wc1XjNb24mP5YOw/fItwntqNKSvD7BIldlwiMozdfTw3+/INTS/oG2SyutbuKhhnN61iNfIOxhpgp0zfKF7HvWNsg/kWw+4rqaK4KdkZuICT7ahio5hIfnov+siJxy4+xD/hf0CKiJeRs1WI7zIX2H3RxcWk/OqYRBN/flbR3bpk5AkkugzDDh/qkWnj+gIYVKuj7SLSEC2/iL9saMglonv/BzsCocZAVVkWa9KtAkaijnxuBT4m9Qu/bsDJX86WxZOTGFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpYTWeSxbhBa8/uyi9MqEWZKupORPd6nh/EgU9UrT04=; b=N3+sny9GIHrXzZAcXKkTeIDTSeUxsmEhxkMnQBQZ9K4Ve5l+wO8rJFRfXXZ+a4iQoPN1lEBsfud8Nr8uYhpxGiJbWRUY707wKERexPlDgxPR+8rWJuuMcheHQ5YeRzGLL3Oddr7tE5yJJmfrsRDm4nnPwqzCpg6+tI8LcxA1XEpFKU2OkSBd7TfOqxuxox8vDuxx8xMcBHC8TdM0fCyVIXwSzcqtzJchfEV6eUc958L0wbHI3/jce4wBhRr0UIXQ8kNBeqT6aB+EybhWeu2HZnnZAan5wzrXH0P+MHZ/yiG/G2DhFz7Kd6zc3UhLeeMxQMYZZwP+bnz++frFf7s8NQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpYTWeSxbhBa8/uyi9MqEWZKupORPd6nh/EgU9UrT04=; b=lDOyu9m2bofNOHc3pKjvzCXtDIw4qPuZjfiv5hZVMj2n8MRsJIM4KLn+NXv/pUeXcXp36KFGqZ49FwWlxAMuBm68e9fAUrXiTruvPJ8BCHo9rFghidexI78PurSGspXoiBhSelfo1FPVUCYfV3dgVtfvO5dbnD1Ajjaf1u1VYQg=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3301.namprd05.prod.outlook.com (2603:10b6:910:55::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Fri, 11 Sep 2020 11:43:03 +0000
Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.032; Fri, 11 Sep 2020 11:43:03 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" <draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths
Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewgMNufgAFqWvsA=
Date: Fri, 11 Sep 2020 11:43:03 +0000
Message-ID: <CY4PR05MB3576EE5A33F8B0DBE1E28305D5240@CY4PR05MB3576.namprd05.prod.outlook.com>
References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <28149_1599664617_5F58F1E9_28149_171_1_53C29892C857584299CBF5D05346208A48F644A8@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <28149_1599664617_5F58F1E9_28149_171_1_53C29892C857584299CBF5D05346208A48F644A8@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-09-11T11:42:58Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9e6dff0e-09ab-4d32-945b-2e40c4b28f41; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ef21c86d-4337-4b22-b1f5-08d85647d794
x-ms-traffictypediagnostic: CY4PR05MB3301:
x-microsoft-antispam-prvs: <CY4PR05MB3301CDC0B805CDA24B051181D5240@CY4PR05MB3301.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ipMeD0tESw8RD7r90J5DvJTCdP840EK8pHLNt1UvNEoJgbFhO/PfOq0VYAgHyxvMsWmniXh1pl8Q1RvywjB0sfyygnQdn70viLrF9jieInpO4862BM1nIti4VGpLwdxmnJLA/x//fRyAxaTIGsfrORKltLWpJl5c7KD87ljjU4BxReQmSnBcO7oJEAYenf9w9VMeSH4rwSx9+4VHAy1ziGJCDs6DNoZjiaCDibUI3YtjeSiXVblNP8gDAP4mIUm8ekonT4SJpeny1OM5jQ0tO1H3e8OyLcrGHoFRY4ZiV6ZDWwKs/Cj+kBQgtT4NyCWaX05B3L41bS8JVOtyis/hbplaC1ODnl3oXIqrVm+bt8hs7f3+tZywhVKVwCkTsfiY2Q226aq/z/Pe5Atdu96Gnw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(346002)(39860400002)(396003)(6506007)(966005)(478600001)(66946007)(186003)(5660300002)(76116006)(9686003)(64756008)(316002)(110136005)(66446008)(52536014)(66574015)(55016002)(8936002)(86362001)(66556008)(166002)(83380400001)(33656002)(26005)(9326002)(7696005)(53546011)(66476007)(4326008)(8676002)(71200400001)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xBTJDm4DoeazmazLOiAlnRmCj2qbs8ctphkl7VhJRdAMG/HQz90RnUBpHElVdG/eF8LmsTX1Gs+wTCzxoyETXqMR4ehCXNZCve+xnPqmhfd2a3PmfpsQnmk/uTwqT4PAOlA7xSFu+eIp1zpoRG0zq3dNe81rWQD0PGoDL3xOT1v6x/YUjpBenanjuQdVCBtUnx2eOGTJcSK4tmH4xQgJ5M7hJFoDVq4XKZNmJktnFGHoDGcF2c0jnd33Jn73EtwXhpphcjaOaqKDQT33BmZsthqCnaHMRZ0cdXZ4mpdLjlXVnaJUU9Z6ppchbnpBq6tpRjcODOMT++x3Yd7vuLI+Ei6bREeJv5GAY+dvUqMDFMjC5VbDaJr7ENl3NrCDWvFrku4GUJuB7tSHVniQ08rpi0dXqRvCWlpoBn7OeXfuyZUvJLjKfO/2pqyv2YAL06Q1S+cyWLmGBh8aC7RxSbIj3Wx7TcQRrgJWN0LsuVojy6hVSZPxvEvkvO47PiiBr3k/eLJNo71G4ln4NFiTL6ryVbk+Hay5WRp/JSOBcfJPxjO4AVWTuQHlmggcGFCxQK7XZhkFp+7Vt60qzP867ZvAlCZ9QyCXU3BzS8hmCReOHbRhC97vF1cLV+ffGeV/hp9KUrQZhmOuXC7zh8n3YJ2qjA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3576EE5A33F8B0DBE1E28305D5240CY4PR05MB3576namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef21c86d-4337-4b22-b1f5-08d85647d794
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 11:43:03.2058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: crrSHNjLHN2Lk7pA7z0FRtE/AsiiEoWpPv+67H/i/KVooLvra5P8H9qhsGUTPSV3mN42VGt71+D4xwPM3slBdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3301
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-11_04:2020-09-10, 2020-09-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 mlxscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 adultscore=0 suspectscore=0 phishscore=0 clxscore=1011 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009110096
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/PxmuRAk87iaPNE_t5HFKYl_LIRs>
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 11:43:15 -0000

Hi Bruno,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: bruno.decraene@orange.com <bruno.decraene@orange.com>
Sent: Wednesday, September 9, 2020 8:47 PM
To: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
Cc: spring@ietf.org
Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

[External Email. Be cautious of content]

Hi authors, all,

As an individual contributor, I have two non-blocking comments.


  1.  I feel that the terminology "node protection"  in the name of the draft could be misleading.


"Node Protection" is already used in [LFA] and [RLFA]. It refers to a property of the alternate path avoiding the next node on the path to the egress/destination. It does not change the destination/egress.
It looks to me that the function been proposed in the draft is more along [Egress Protection] which protects from the failure of the egress/destination, and hence do change the destination/egress. (full disclosure, I'm co-author of [Egress Protection] )

I think that both are different and that properties are different, hence using the same name is misleading.
In particular, in the first one, the destination/egress is unchanged and hence properties of the destination/egress is unchanged: no problem. While in the second case, a node (a 'protector' in [Egress Protection]) is claiming to provide a similar service, but possibly only a subset of the original services or without the stateful states). Cf some discussion on the mailing list along "How do I know that I can safely pretend that I'm the original destination?"


Personally I would propose to replace "Node Protection" by "Segment Protection" or "Segment Egress Protection" or "IGP Segment Egress Protection" since the proposal seem restricted to IGP knowledge.
<Shraddha> I agree that using the term node protection is confusing. I think that "segment protection" is the  right  term.  Using egress keyword may cause other confusions because term egress is used in egress protection RFCs to mean the egress nodes on which the services reside. In this draft the focus is on nodes that are not egresses.

[LFA] https://tools.ietf.org/html/rfc5286<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5286__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5Zs8bjDj_k$>
[RLFA node protection] https://tools.ietf.org/html/rfc8102<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8102__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZszUA3CEW$>
[Egress Protection] https://tools.ietf.org/html/rfc8679<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8679__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZswTcjaLe$>



  1.  At best, the proposal ignores [Egress Protection]. At worst, the draft breaks [Egress Protection]

Both do not seem to co-operate.
<Shraddha> Actually, egress protection as defined in RFC 8679 works well with procedures defined in this draft. Section 3.4 briefly talks about this.
Initial versions of this draft had examples to describe how egress protection works in conjunction with procedures described in this draft.
Basically, egress protection described in RFC 8679 uses a context-id and context label. When the penultimate hop creates protection for the context-id routes
It follows the procedures described in RFC 8679 ( in conjunction with mirror-sid for SR networks). We also have a simplified version of RFC 8679 which uses anycast SIDs and static service labels
Described in draft-hegde-rtgwg-egress-protection-sr-network. This anycast based egress protection also works well with protection procedures described in this document.
I'll add a section with examples to describe this which can help clarify.

The draft applies the egress protection even though it can only protections IGP segments/labels while [Egress Protection] would provide a much broader protection, including service (e.g. VPNs) protection. Hence it seems to break [Egress Protection] VPN service protection.
<Shraddha> No this draft does not break VPN service protection. I'll add detailed examples.

I would propose that the draft refers a bit more to [Egress Protection], uses its terminology if/when appropriate and then elaborate on the above issue. From a technical standpoint, I would propose to privilege the use of a (complete) Protector (as per [Egress Protection] ) if available.
<Shraddha> This draft makes use of looking up the second label in the stack for protection. It is different from protector based approach.
draft-hu-spring-segment-routing-proxy-forwarding Is more closer to protector based approach I think. It comes with an overhead of  configuring the
primary and proxy pairs for set of nodes.

Finally, as also raised by Zhibo, the scalability properties of the draft is not optimal, and in particular less optimal than [Egress Protection].
<Shraddha>I'll add some more text on scalability.  Section 5 of the draft proposes an optimisation to reduce scale.
Indeed, most of the work/states is on a Protector node (having the context mpls forwarding table). For a given failure, [Egress Protection] allows for a single Protector while this drafts requires N Protectors (one per neighbour). So more states in the network and on nodes. Also [Egress Protection] allows to distribute this load while the draft requires the PLR to handle the protection for all its neighbhors.
Since this draft restricts to IGP Segments, the scalability impact his limited but still exist.
(on the pro side, the draft avoids the additional transport cost/delay required to reach the Protector (since PLR and Protector are co-located)/
<Shraddha> Fair point. I would see the advantage of this draft is more from operational perspective since it does not require primary protector configs.
Enabling the feature with one single knob on the router will be good enough.
Regards,
Bruno


From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Thursday, July 30, 2020 2:25 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org<mailto:draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org>
Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi SPRING WG,

Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked for WG adoption.

Please indicate your support, comments, or objection, for adopting this draft as a working group item by August 20th 2020. (*)

Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this.

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZsxQ-MBcB$>
(*) 3 weeks to account for the IETF meeting week and the august/summer period.


_________________________________________________________________________________________________________________________



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.