Re: [Teas-ns-dt] 答复: Definition of transport network slicing

LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com> Thu, 17 October 2019 22:27 UTC

Return-Path: <luismiguel.contrerasmurillo@telefonica.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 2F76A120808 for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 15:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.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 TSWMWwRYwzg3 for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 15:27:34 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20126.outbound.protection.outlook.com [40.107.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD7D12012A for <teas-ns-dt@ietf.org>; Thu, 17 Oct 2019 15:27:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X4+/c8/H2qZBJRuSHpZPS/w3JwkTaR8xptKq5DgksaVrmEFNtKfjruRHS43/4arpZ3MQryFBF2IbOJgehi/8husPYAR/4jzUKV34Z71kOgqdqVo4bLelDtO8JOGW1G1IadcXfYylScA8KOcIFlCxZTErBHl4eUa0dsf0Cw0VHCQvw/swX7IEQM6Az8wv/havABeNmyu49buQbzt2MibOIsog1Y8gdMztJLC8btRXXpXm0jJGad7QoNbSR+I4CF8fsqtnSOxpNw+Q3wg9g67zGSgU+s3pMPWbG4lXCR6mMaVayXWvXjepDhyVLtUff6nPc1GLcf8AzLcO4EGR/tOhMg==
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=eOGY9aUV3EfX7WLVEh8FGuxPSqpQ72Y1Mp+CBWccqFk=; b=IzEBAOwYaupZOZ5CQJskkOO97m7B5RWnSEK8hB+MgbgF4Mg/b2f+oRxACKgNp9NPFdei6HWVTiwQNp//pc6Pg4ayHghd5DnhadZC1tr/m2XYds7k1/5JLiA8m+l0F7pe22yi+nH3z70W9Hq7dMdCZgqHTU5T+d6Os3XQz1wHWF8pGY+Yu+FhPvXtTwAPydPs5BxnDUn5bCYgTRwfVwQCSX2Q9vi64Y4NcOCiTHmJuRcYnTlaMgwyqVRte93co3TIbXn6nXaeKFQQkq+AZcnKnvBcIxAJtk1gChZnRNMorcn6CY1i2nxtpbIjNMjjcNaF+63NGaNNI6tNOHZvUagyfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eOGY9aUV3EfX7WLVEh8FGuxPSqpQ72Y1Mp+CBWccqFk=; b=PwqIGFNTl10phxes1/4vAD/q5BwldHrTX/0ycEpiyF6m7zjDJKuK+KuV70cuB+sJeUtlhP5fX6i6+3gVx23UiO332BlyMO7HIRYciKaCEZApITntYCVJ3dZookHrgmOX3ToZf5sPPYP9tHWh4zqL/qFu2N6jH2FBmNF8V6tlM3o=
Received: from AM6PR06MB6088.eurprd06.prod.outlook.com (20.179.244.206) by AM6PR06MB5718.eurprd06.prod.outlook.com (20.178.93.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Thu, 17 Oct 2019 22:27:30 +0000
Received: from AM6PR06MB6088.eurprd06.prod.outlook.com ([fe80::ad09:7fb0:c438:63ee]) by AM6PR06MB6088.eurprd06.prod.outlook.com ([fe80::ad09:7fb0:c438:63ee%6]) with mapi id 15.20.2347.024; Thu, 17 Oct 2019 22:27:29 +0000
From: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
To: Kiran Makhijani <kiranm@futurewei.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: [Teas-ns-dt] 答复: Definition of transport network slicing
Thread-Index: AQHVhJcov8PLXqPj/EGKUlyDhoBAyKde0W2A//+WOgCAAMVKQA==
Date: Thu, 17 Oct 2019 22:27:29 +0000
Message-ID: <AM6PR06MB6088E517B819B40DC6AD79689E6D0@AM6PR06MB6088.eurprd06.prod.outlook.com>
References: <57B59086-BFF0-412E-9FD2-121801FF6DB5@nokia.com> <AM6PR06MB608860D492743790B0D4E5FE9E6D0@AM6PR06MB6088.eurprd06.prod.outlook.com> <6B535592-4BF5-48F8-8437-7B3F6333396D@futurewei.com>
In-Reply-To: <6B535592-4BF5-48F8-8437-7B3F6333396D@futurewei.com>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=luismiguel.contrerasmurillo@telefonica.com;
x-originating-ip: [201.16.171.137]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a263c6e3-0c05-449a-89c3-08d753513268
x-ms-office365-filtering-ht: Tenant
x-ms-traffictypediagnostic: AM6PR06MB5718:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM6PR06MB5718190D805C414D7ADC4C099E6D0@AM6PR06MB5718.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01930B2BA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(396003)(136003)(39860400002)(346002)(199004)(189003)(40134004)(25786009)(790700001)(486006)(236005)(19627235002)(224303003)(966005)(86362001)(446003)(71200400001)(7696005)(102836004)(476003)(186003)(66066001)(71190400001)(5660300002)(11346002)(6436002)(606006)(9686003)(256004)(6306002)(54896002)(229853002)(733005)(14444005)(14454004)(8936002)(74316002)(478600001)(26005)(316002)(66574012)(6506007)(99936001)(7736002)(76176011)(52536014)(66616009)(2501003)(786003)(2906002)(55016002)(3846002)(110136005)(76116006)(99286004)(33656002)(66556008)(6116002)(6246003)(53546011)(81166006)(66446008)(64756008)(81156014)(66946007)(66476007)(30864003)(9010500006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR06MB5718; H:AM6PR06MB6088.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RymhFVwMYtwSbScgsBtfnLAelXcOtduKIyEHJmrAl/6WsE49A6Szxbkye3ajUrKxAiPdjZ0xuh6sccHNtqxpeHcxPNh7v1Dfptq+6lWtaDhPWngqWTPfTnkKRLdliJMGniOA+uA2hAFRcilkVQKnINiFSDcPjbIoVN3uESjgKPLOMqQhWIIFQsqHWh9srfJM/Kl2wt1qD8pDudbQMOmXfnhXdhg0nKHrcKT+jOFwl/81Y9rcaIgKTa/RxxM2cRgpoIdZv8n6SsEkVpGdYUjYSXsIF+jf28TaDsLlvXnAmFbW+mcxJCQKkGGKN4+OSFakQDZDM8Njw9AxicYdLeQT0Gaxtpn5FP53g5ktIY5Y82G+NwAulGF7ZypjVhu7aRuTpdL3IzgOUR+p9k3PPo2bFswocbNIryCaCSdLtYyeKQmBPB56fPGSRmCLNsSvqzlb44yy9JkiAqqgfDtN+p6dFw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_AM6PR06MB6088E517B819B40DC6AD79689E6D0AM6PR06MB6088eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a263c6e3-0c05-449a-89c3-08d753513268
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 22:27:29.7793 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Wf5MxWBTUBqyLROJUNDF9qJvLf0eDQYXFkovnb6gjLJwM3HwutSk2BoYQbAzIXTKo6d791Lc11aul3By3KzReal89Y6J1CVRpp6cp0+PEP8t+IrRgf8f/kAuoGnnF2ulsdnvAWFpxBlvsbLD5+d44Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR06MB5718
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/tL7X64MgGJBYILnPHqPiOT2Cp6U>
Subject: Re: [Teas-ns-dt] 答复: Definition of transport network slicing
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: Thu, 17 Oct 2019 22:27:40 -0000

Hi Kiran

Let me explain better, focusing on the idea of transport slice discussed today. In case the tenant would require control and management capabilities of the transport slice (e.g.,  setup / tear down a path, divert traffic from one path to another, etc) this would probably cannot be accommodated in the same slice with the connectivity for other tenants, since can be impacts or “interferences”. As you point out, maybe the slice operator could mediate on that operations, if the API offers those possibilities, limiting the capabilities about what the tenant can do.

More control and management capabilities in the tenant side will probably imply to go to dedicated resources in the network side, and viceversa.

Somehow I see similarities between this and the concept of managed and un-managed services that the operators offer today for connectivity services. I explored in the past this different approaches with the idea of provider-managed vs tenant-managed slices, you can check the following article if interested: https://sdn.ieee.org/newsletter/january-2018/a-network-service-provider-perspective-on-network-slicing

Best regards

Luis

De: Kiran Makhijani <kiranm@futurewei.com>
Enviado el: jueves, 17 de octubre de 2019 11:00
Para: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; 'Dongjie (Jimmy)' <jie.dong@huawei.com>; teas-ns-dt@ietf.org
Asunto: Re: [Teas-ns-dt] 答复: Definition of transport network slicing

Hello Luis,
any action from this customer could collide with actions from others.
^^^^
Did you mean with in the set of resources allocated to the customer or otherwise? If it is with in the allocated resources, there should not be collision. Otherwise, in my opinion customer interface should only be  allowed to request resource changes via the slice operator – which in turn will be able to figure out if such a request is possible..

--
Regards,
Kiran



From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> on behalf of LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com<mailto:luismiguel.contrerasmurillo@telefonica.com>>
Date: Thursday, October 17, 2019 at 3:23 PM
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com<mailto:reza.rokui@nokia.com>>, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>, "teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>" <teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>>
Subject: Re: [Teas-ns-dt] 答复: Definition of transport network slicing

Hi Reza, all,

Regarding: “shared or dedicated transport slices is up to the MNO which in turn depends on level of customers (i.e. customer is Gold, Silver etc) and customers’ use-cases. Not all the use cases need strict SLA” some thoughts come to my mind.

I think there is also a dependency on the level of control that could be granted to the customer/tenant for his/her slice, in the sense that if the customer requires control (e.g., reconfiguring of paths or modification of their characteristics) any action from this customer could collide with actions from others. In consequence, a separated slice would be required to be allocated. Different levels of control could be identified, and in base of that, maybe some customers could coexist on top of the same slice or not.

Best regards

Luis

De: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> En nombre de Rokui, Reza (Nokia - CA/Ottawa)
Enviado el: jueves, 17 de octubre de 2019 0:01
Para: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>; 'Dongjie (Jimmy)' <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
CC: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com<mailto:reza.rokui@nokia.com>>
Asunto: Re: [Teas-ns-dt] 答复: Definition of transport network slicing

Hi Aijun,

The isolation of transport slices shall be possible and it depends on the use-case and customer’s request (aka tenant).

For example let’s assume the customer (aka Tenant) City Of New York would like to have an E2E network slice to connect all the CCTVs in the buses across the city. In this case it asks the MNO (e.g. AT&T) to create an e2e network slice which in turn results in creation of one or more transport slices (in addition to RAN Slice and Core slice). If for example customer City of NY is gold customer for AT&T, it will decide to have dedicated transport slices to make sure the SLAs are met.
It is also possible for AT&T to share one or more transport slices for a few customers.

In summary, shared or dedicated transport slices is up to the MNO which in turn depends on level of customers (i.e. customer is Gold, Silver etc) and customers’ use-cases. Not all the use cases need strict SLA.

Cheers,
Reza


From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Date: Thursday, October 17, 2019 at 6:40 AM
To: Reza Rokui <reza.rokui@nokia.com<mailto:reza.rokui@nokia.com>>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>, "teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>" <teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>>
Subject: 答复: [Teas-ns-dt] Definition of transport network slicing

Hi, Reza,Jie and all:
For the transport, do we need to emphasize the isolation? Is any solution that can meet the application’ SLA  acceptable?
From the 5G document, the isolation concept refer mainly to its functional entities.

Best Regards.

Aijun Wang
China Telecom

发件人: teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org> [mailto:teas-ns-dt-bounces@ietf.org] 代表 Rokui, Reza (Nokia - CA/Ottawa)
发送时间: 2019年10月16日 21:57
收件人: Dongjie (Jimmy); teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
抄送: Rokui, Reza (Nokia - CA/Ottawa)
主题: Re: [Teas-ns-dt] Definition of transport network slicing

Hi Jie and all,

Your definition is correct. However, the following is my view. Please add comments.

In general a transport slice has a definition and a realization (aka implementation). The transport slice definition is whatever Jie mentioned below and I rephrase it here. i.e.

  *   Transport slice definition: A set of connections each with appropriate isolation and specific Service Level Agreement (SLA).

However an transport slice has an implementation (or realization) as well. To clarify, let’s have an example.
The following picture shows the most complex 5G network (i.e. Cloud RAN where it contains fronthaul, midhaul and backhaul networks. In this picture there are 4 different transport slices for a single E2E network slice.

Each of transport slices 1 to 4 has an implementation which potentially has different technologies and different techniques. For example, the transport slice 3 can be realized on IP network using L3VPN or VPN+ or any other techniques to satisfy certain SLAs. The fact is that we can realize the transport slice 3 using different techniques but the regardless of that, the definition of the transport slice 3 does not change (which is connectivity of CUs to Core network).

Another example is the transport slice 2 in midhaul which its definition is connectivity between DUs to CUs. In majority of  deployments, this transport slice will be realized using PON technique or IP VPNs. Again regardless of implementation, the transport slice 2’s definition is DUs to CUs connectivity with certain SLAs.

If needed, I can present a few slides during our call on Oct 17th.

Cheers,
Reza


[cid:image001.png@01D58502.FB84A260]



From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> on behalf of "Dongjie (Jimmy)" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Date: Monday, October 14, 2019 at 5:57 PM
To: "teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>" <teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>>
Subject: [Teas-ns-dt] Definition of transport network slicing

Hi,

As one of the action points of the design team conference call in last week, we will discuss and give the definition of transport network slicing. Here I’d like to reference the definition in https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cdf51b7a5bdef4a7e930d08d753051e7a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637069153824385941&sdata=gPj6StzF5QQ6LJCwaSvOTvOAHPFCXQ6y0t2Qi4naPDU%3D&reserved=0> as the starting point:

“A transport network slice is a virtual (logical) network with a particular network topology and a set of shared or dedicated network resources, which are used to provide the network slice consumer with the required connectivity, appropriate isolation and specific Service Level Agreement (SLA). “

Please feel free to provide your comments and suggestions.

Best regards,
Jie

________________________________

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

________________________________

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