Re: [Teas-ns-dt] Appendix text on isolation
Kiran Makhijani <kiranm@futurewei.com> Mon, 22 June 2020 20:47 UTC
Return-Path: <kiranm@futurewei.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id BDD263A1184
for <teas-ns-dt@ietfa.amsl.com>; Mon, 22 Jun 2020 13:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001]
autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=futurewei.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 oHWKIVlG3Gxp for <teas-ns-dt@ietfa.amsl.com>;
Mon, 22 Jun 2020 13:47:15 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
(mail-bn7nam10on2136.outbound.protection.outlook.com [40.107.92.136])
(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 811E73A1180
for <teas-ns-dt@ietf.org>; Mon, 22 Jun 2020 13:47:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=mtJ53jCts7izDZjTSMklkGPS6l8TWSM3RpjVpRFvJ5ILX5Lc4mYHRXX8x35b3SrxROlK2NOhbblg/ctV28HoGd4F8QaNZPwK5IQasAqq+7ORkLOkLkniixj5mN2tqR6iJzVGUp4+FCfouTo+XPjNP7ngB4LM4JH19IDCbnTnljG8nuMzOt+47I5wrsnD1EObVmKa6D4cvYQL5V1OAFlmXTOQ6feVTj2kBJh3LXKaC5uiJABVg4gVy5uZu05RK2Cyv55NhR7ovQlboHXobFjbRn38hmS65Pmcds4ei16m7WStIeOM/cFk8I9TTmeghJeqet3VQ7fUNyRY8SeCvwR0lw==
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=6HyDne8sSpcGpSDtyWs2oGFQd8nYvMOXo2sYwI7MPRM=;
b=IxCID448LDnNDn14UQVs97F1qoWZpWSHKkYxxrYye0xVXBD4LwNBN16jWeygpzd9d2Q0aUIWBdxjIP29VGrkvJa1qTk6bP9U9kSbHqN4gSECQ6BpumvzlCCk4KDHguyS9hHNFhkJM/DMFTcR7EsGnL3VqowA84K0Z+XHy/WfdkLSIHl3nsBUvHAK3Nb11Xlh9p7asqpUYwPAvUfqwwlC3kGYCnsFdV9WKAAiB5Ga/pzG5nJ5v0AuKj3akHgYyhzmy3M0OQW/7uLYQl8Mt6GWJ4L9eP2PPW+npejDpfZbrrm+x5d89vvQY9UfSeuMrnCvs67hRriCybDAcZ8FuzcbSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=futurewei.com; dmarc=pass action=none
header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com;
s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=6HyDne8sSpcGpSDtyWs2oGFQd8nYvMOXo2sYwI7MPRM=;
b=YltzsyS87m8ImOfofdVB1ZM1bXmxq+DG2rwVoOSP9Fnn11WHDxajF4xacpWQNVvNxjaM7LoPAThWkRakkMLf3rhT94yx03Mn/QlUjNuNGWQJo4he4eM3jTs6UqVhak8RQaID/KJZtuERI5LX+7NWYogDN4XHP/HN0j6qX2dBosw=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (2603:10b6:a02:cb::23)
by BYAPR13MB2245.namprd13.prod.outlook.com (2603:10b6:a02:bf::28)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.10; Mon, 22 Jun
2020 20:47:12 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com
([fe80::3d56:a478:f62f:351e]) by BYAPR13MB2437.namprd13.prod.outlook.com
([fe80::3d56:a478:f62f:351e%4]) with mapi id 15.20.3131.017; Mon, 22 Jun 2020
20:47:12 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: LUIS MIGUEL CONTRERAS MURILLO
<luismiguel.contrerasmurillo@telefonica.com>, "teas-ns-dt@ietf.org"
<teas-ns-dt@ietf.org>
CC: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Jari Arkko
<jari.arkko=40ericsson.com@dmarc.ietf.org>
Thread-Topic: Appendix text on isolation
Thread-Index: AQHWQxMeOnwlM6C7q0au6xJVzwQhZajbG8KA///hwpCAAQKvQIAACSbQgAAWTJWAAG58IIAIO9xwgABaZ5CAAAH+fg==
Date: Mon, 22 Jun 2020 20:47:12 +0000
Message-ID: <BYAPR13MB243798B0B97A976FA689CBC6D9970@BYAPR13MB2437.namprd13.prod.outlook.com>
References: <0A04E8C3-55DF-4146-8BE0-4189AE5844CE@ericsson.com>
<846A4B09-4EDE-4617-9C7E-5E0CAD96029C@ericsson.com>
<09d82c1775574d9bb79adbe73d3877f1@huawei.com>
<BYAPR13MB2437129DFCC21CFDDE5C8063D99A0@BYAPR13MB2437.namprd13.prod.outlook.com>,
<6429055ec57f4bd483cd4f0e5716d5f2@huawei.com>
<BYAPR13MB2437864F0603D95880968F78D99A0@BYAPR13MB2437.namprd13.prod.outlook.com>
<9308d76c80654cfeae2a8ab2bedd7b2b@huawei.com>
<BYAPR13MB2437D3877A9208F6835F23CCD9970@BYAPR13MB2437.namprd13.prod.outlook.com>,
<VI1PR0601MB21578F41C1B292E140B114FB9E970@VI1PR0601MB2157.eurprd06.prod.outlook.com>
In-Reply-To: <VI1PR0601MB21578F41C1B292E140B114FB9E970@VI1PR0601MB2157.eurprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: telefonica.com; dkim=none (message not signed)
header.d=none;telefonica.com; dmarc=none action=none
header.from=futurewei.com;
x-originating-ip: [67.188.27.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9df83c8f-e367-4c7f-87a5-08d816ed70be
x-ms-traffictypediagnostic: BYAPR13MB2245:
x-microsoft-antispam-prvs: <BYAPR13MB2245392C8591805D27EB4F03D9970@BYAPR13MB2245.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0442E569BC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wwIuan3ZPjYR34DzEJBRFbMIWQmduXix1L6ZU+M+r3XAUT+HeLWQfDjwXxSKKAeeIUUYmKJ+UqYuBL/ruUQhquL37Yvfpzb/mmzuiuQYs5Jqx5TcnlJFFUp3aHaXTVGwpmUBrcrA55LhCosR2+h3cOXpNmpjMfmbGitYE0h2GQpcP++/9r/tHBL8yLptLNBAOYD037TjSJwHvJcag91+w97flMPOJUdHC4b8AGVZCs5VQiwyuS9uKlXIs0Qur0NG/n+iVtW7ve3Nagf1tw18QpiaNP9xEMwjKmzoqaLxHSIZLZFmMf3BWetq3rti5JGcsnRA4ut1UiGvsMONXcZwYA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM;
H:BYAPR13MB2437.namprd13.prod.outlook.com; PTR:; CAT:NONE;
SFTY:;
SFS:(4636009)(39840400004)(346002)(366004)(376002)(396003)(136003)(53546011)(26005)(6506007)(83380400001)(71200400001)(66574015)(7696005)(66556008)(478600001)(66476007)(316002)(296002)(110136005)(64756008)(66946007)(66446008)(76116006)(19627235002)(54906003)(55016002)(4326008)(2906002)(9686003)(8676002)(3480700007)(186003)(8936002)(33656002)(86362001)(30864003)(52536014)(5660300002);
DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: g9LJQAy/+IF9bzXDlmc1ZeG1NUkzlWzh1SEga/gtmBP8px2dvC3I9WaP/6h/tBZ4VmjDkMbgnY/vO0y2ymTAgCTq9JfgFaN1+biP5R4hLScqKTWnPr/v+GaarENdGwxgT1Bl+rhLGhzWLS4Ung52yq6z1LPwfqi9vO8DKvyYLACoP/2gL1HmxQ6Hw5S7aIupO0CqRnm9i/jtpuk3NKFRi8fdI3aeyMZzsPdseVAZcJmVBeTDu7m3wAP/Y3392oylU3Np98MBDDVjRnxBklzcOQWhluqkLOg3C9e+3QE1N11OlR63jVy1+KrItoRdMO9i0+zhDWOgnVglX5OTUnjiXhH9Lincc/aE2OgdWnfNvOTol91Zi9XOr3VsLZSLeLrPNcZGJGkmAMUR3JRAVSg+0BDUG/AOmt1yTJejnlg/5OEMAP1P9wxWZ09zAk7VDLuK32e4kXKd1eYJl1enq3+dQUAutPoySp4dwCVS3ZbwQow=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
boundary="_000_BYAPR13MB243798B0B97A976FA689CBC6D9970BYAPR13MB2437namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR13MB2437.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9df83c8f-e367-4c7f-87a5-08d816ed70be
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 20:47:12.5391 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 01wXCQLNIVeshK95SBlFF/i9NhAnoKMO7rOnobT9blzgADjAhufJPeLq+0M5Rp7+O3evJYoO+sgiPq71yMwskg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2245
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/wAD_BHpebObAcQczk7HF54crFWI>
Subject: Re: [Teas-ns-dt] Appendix text on isolation
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>,
<mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 20:47:19 -0000
Ack. I was tentative too. Regards Kiran ________________________________ From: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com> Sent: Monday, June 22, 2020 1:44:49 PM To: Kiran Makhijani <kiranm@futurewei.com>om>; teas-ns-dt@ietf.org <teas-ns-dt@ietf.org> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org> Subject: RE: Appendix text on isolation Hi Kiran, Thanks for taking care of this. Let me insist in a small but important part. It is respect to the last paragraph, where it is mentioned that any mechanisms can provide 100% of guarantee. My point is that being true, this is applicable not only for the isolation concept but for any other consideration, e.g. meeting whatever SLO such as bandwidth. Then, in my view, leaving that reference in this annex could make apparent that such statement is only related to isolation when in reality it is related to whatever characteristic of the transport slice. So I would suggest to remove it. Best regards Luis De: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> En nombre de Kiran Makhijani Enviado el: lunes, 22 de junio de 2020 22:00 Para: teas-ns-dt@ietf.org CC: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org> Asunto: Re: [Teas-ns-dt] Appendix text on isolation Hi Jie, and all, Please review the final text, considering all the comments received so far. --begin-- A.1. On isolation requirements in a transport slice Transport slices are perceived as if slice was provisioned for the customer as a dedicated network with specific SLOs. These committed SLOs for a given customer should be maintained during the life-time of the slice even in the face of potential disruptions. Such disruptions include sudden traffic volume changes either from the customer itself or others, equipment failures in the service provider network, and various misbehaviors or attacks. The service provider needs to ensure that their network can provide the requested slices with the availability agreed with its customers. Some of the main technical approaches to ensuring guarantees are about network planning, managing capacity, prioritizing, policing or shaping customer traffic, selecting dedicated resources, and so on. One term that has commonly been used in this context is "isolation" and is also discussed in the [I-D.ietf-teas-enhanced-vpn]. A customer of transport slice may ask for traffic separation, selection of dedicated resources, or interference avoidance from other traffic. The term "isolation" can refer to any or all of them. For instance, dedicated resources can help assure that traffic in other slices does not affect a given slice. Simillarly, traffic separation can be provided by VPN technologies, and interference avoidance may be provided by mechanisms such as technical approaches mentioned in previous paragraph. Moreover, these are some of the examples of particular realization of requirement for guarantees; other mechanisms may also be used. It should also be noted that neither above mentioned nor the other mechanisms can provide a 100% guarantee against outage problems. To maintain protection against resource and equipment failures techniques such as redundancy are also needed. --end-- Thanks Kiran From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: Wednesday, June 17, 2020 3:17 AM To: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> Subject: RE: Appendix text on isolation Hi Kiran, I understand your point, while since isolation is specified as a requirement of network slicing in other SDOs (e.g. GSMA, 3GPP), some customers may also ask for isolation in end-to-end network slice or transport slice. My opinion is it may be helpful to interpret and clarify isolation as more specific requirements in IETF and transport slice context (such as traffic separation, interference avoidance, etc.) Another option is to describe the specific requirement and the corresponding realization directly: “A consumer of transport slice may ask for traffic separation or interference avoidance from other transport slices. The term “isolation” implies traffic separation, or interference avoidance, or both. Accordingly, from realization’s perspective, …” Best regards, Jie From: Kiran Makhijani [mailto:kiranm@futurewei.com] Sent: Wednesday, June 17, 2020 11:05 AM To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> Subject: Re: Appendix text on isolation I am trying to say that customer should not have to ask for isolation but some abstraction of it. It may explicitly ask for specific requirements but not isolation. It’s ok to go with your suggestion if its just me. Some text is repeated from 2nd para. So that still needs some work. Regards, Kiran ________________________________ From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: Tuesday, June 16, 2020 7:26:03 PM To: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> <teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>> Subject: RE: Appendix text on isolation Hi Kiran and all, Your concern is part of the reason that I suggest to describe the requirement and realization of isolation separately. Firstly, multi-dimension can help to clarify the different requirements related to isolation, such as traffic separation and interference avoidance, in my understanding both of which can be raised by a customer as requirement, and they do not reflect implementation details. Then the implementation-specific mechanisms could be briefly described to match each dimension of the requirement. The sentence you added in the end of the paragraph looks good, while maybe it could be better if such requirement description be moved to the beginning of the paragraph. Please check the modified text below: A consumer of transport slice may ask for isolation from other transport slices. The term “isolation” can refer to multiple dimensions of requirements, such as traffic separation, or interference avoidance, or both. Accordingly, from realization’s perspective, traffic separation can be provided by VPN technologies, and interference avoidance may be provided by mechanisms such as capacity planning, policing or shaping, priority mechanisms, selecting dedicated resources, and so on. Please let me know your thoughts. Thanks. Best regards, Jie From: Kiran Makhijani [mailto:kiranm@futurewei.com] Sent: Wednesday, June 17, 2020 9:30 AM To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> Subject: RE: Appendix text on isolation Hi Jie, and all, One argument against using isolation as an SLO is that it is an implementation specific detail that customer should not have to (always) concern with. So I am not comfortable with the use of ‘multi-dimensional’. One way to separate realization and customer requirement may be we can use business objective/case. May be we can add, one sentence at the end of the original paragraph. What do you think? The term “isolation” implies in part traffic separation (a common feature in VPNs) and in part the selection of dedicated resources. Dedicated resources can help assure that, for instance, traffic in other slices does not affect a given slice. However, it should also be noted that this is one particular realization of a requirement for guarantees, and other mechanisms may also be used, such as priority mechanisms or policing amount of traffic entering a link from different sources. Business objectives may require a customer to ask for explicit traffic separation or interference avoidance mechanisms. -Kiran From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: Tuesday, June 16, 2020 3:15 AM To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> Cc: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>> Subject: RE: Appendix text on isolation Hi Jari, Thanks for considering most of my comments in this revision. And as mentioned yesterday and in my previous email, I’d like to suggest whether the description about isolation could be rephrased a bit, so as to better clarify the requirement and realization of isolation in different dimensions. The term “isolation” can refer to multiple dimensions of requirements. A customer may ask for traffic separation or interference avoidance, or both. Accordingly, from realization’s perspective, traffic separation can be provided by VPNs, and interference avoidance can be provided by mechanisms such as capacity planning, priority mechanisms, policing or shaping, selecting dedicated resources, and so on. Hope this helps. Best regards, Jie From: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Tuesday, June 16, 2020 4:26 PM To: teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org> Cc: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>> Subject: Re: [Teas-ns-dt] Appendix text on isolation Here’s a suggested 2nd revision of the suggested text, based on yesterday’s comments on the call and Kiran’s email. Transport slices are perceived as if slice was provisioned for the customer as a dedicated network with specific SLOs. These committed SLOs for a given customer should be maintained during the life-time of the slice even in the face of potential disruptions. Such disruptions include sudden traffic volume changes either from the customer itself or others, equipment failures in the service provider network, and various misbehaviors or attacks. The service provider needs to ensure that their network can provide the requested slices with the availability agreed with its customers. Some of the main technical approaches to ensuring guarantees are about network planning, managing capacity, priority mechanisms, policing or shaping customer traffic, selecting dedicated resources, and so on. One term that has commonly been also used in this context is "isolation". This is discussed further in the framework draft [I-D.nsdt-teas-ns-framework] and has also been a topic in [I-D.ietf-teas-enhanced-vpn]. The term “isolation” implies in part traffic separation (a common feature in VPNs) and in part the selection of dedicated resources. Dedicated resources can help assure that, for instance, traffic in other slices does not affect a given slice. However, it should also be noted that this is one particular realization of a requirement for guarantees, and other mechanisms may also be used, such as priority mechanisms or policing amount of traffic entering a link from different sources. It should also be noted that neither dedicated resources or the other mechanisms can provide a 100% guarantee against problems. To maintain protection against resource and equipment failures techniques such as redundancy are needed. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
- [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas-ns-dt] Appendix text on isolation Luis M. Contreras
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Xufeng Liu
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Eric Gray