Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Wed, 21 July 2021 05:01 UTC

Return-Path: <ke-oogaki@kddi.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6783A1317 for <teas@ietfa.amsl.com>; Tue, 20 Jul 2021 22:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=o365kddi.onmicrosoft.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 t1KoNOdTN8wN for <teas@ietfa.amsl.com>; Tue, 20 Jul 2021 22:01:36 -0700 (PDT)
Received: from kddi.com (athena7.kddi.com [27.90.165.212]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7953A1313 for <teas@ietf.org>; Tue, 20 Jul 2021 22:01:35 -0700 (PDT)
Received: from kddi.com ([127.0.0.1]) by LTMC3103.kddi.com (mc MTA5 1.4) with ESMTP id 521072114012813600.12604 for <teas@ietf.org> ; Wed, 21 Jul 2021 14:01:28 +0900
Received: from kddi.com ([10.206.2.120]) by LTMC3103.kddi.com (mc MTA4 1.4) with ESMTP id 421072114012753800.12554 for <teas@ietf.org> ; Wed, 21 Jul 2021 14:01:27 +0900
Received: from kddi.com ([127.0.0.1]) by LTKC3123.kddi.com (mc MTA19 1.4) with ESMTP id j21072114012664000.00999 for <teas@ietf.org> ; Wed, 21 Jul 2021 14:01:26 +0900
Received: from localhost ([10.206.20.239]) by LTKC3123.kddi.com (mc MTA16 1.4) with SMTP id g21072114012557300.00792 for <teas@ietf.org> ; Wed, 21 Jul 2021 14:01:22 +0900
Received: from localhost ([10.206.20.239]) by LTKC3123.kddi.com (mc MTA11 1.4) with SMTP id b21072114012455300.00522 ; Wed, 21 Jul 2021 14:01:22 +0900
Received: from localhost ([10.206.20.239]) by LTKC3123.kddi.com (mc MTA8 1.4) with SMTP id 821072114012358500.00392 ; Wed, 21 Jul 2021 14:01:22 +0900
Received: from LTKC3133.kddi.com ([10.206.20.239]) by LTKC3123.kddi.com (mc MTA6 1.4) with ESMTP id 621072114012266000.32728 ; Wed, 21 Jul 2021 14:01:22 +0900
Received: from LTKC3133.kddi.com (localhost.localdomain [127.0.0.1]) by LTKC3133.kddi.com with ESMTP id 16L51MmQ019209; Wed, 21 Jul 2021 14:01:22 +0900
Received: from LTKC3133.kddi.com.mid_2318259 (localhost.localdomain [127.0.0.1]) by LTKC3133.kddi.com with ESMTP id 16L4pKfK014188; Wed, 21 Jul 2021 13:51:20 +0900
X-SA-MID: 2318259
Received: from LTKC3146.kddi.com ([10.206.20.232]) by LTKC3124.kddi.com (mc MTA 1.4) with ESMTP id 121072113511982000.01510 ; Wed, 21 Jul 2021 13:51:19 +0900
Received: from LTKC3146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id B2B9013C006A; Wed, 21 Jul 2021 13:51:19 +0900 (JST)
Received: from kddi.com (LTMC3101 [10.206.2.41]) by LTKC3146.kddi.com (Postfix) with ESMTP id A31AB13C0055; Wed, 21 Jul 2021 13:51:19 +0900 (JST)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com ([104.47.92.57/tls]) by LTMC3101.kddi.com (mc MTA 1.4) with ESMTP id 121072113511874100.28612 ; Wed, 21 Jul 2021 13:51:18 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MipJYXFbaTUYNEQ4mApOtcrIfSXb50Ihfi5IU3etceSf2IdkgQeJODGmBKooEC6JQkbjxZNhvows44RnYXX3Myo+g9VJ9auxVSIwamTpKacGiq+pGCEsFckNMEzlVbyi8wwyesM/AnQk6tMvxZl999o9KUaoQgQyu4Jwe9cljYoZZEzNqrZ8NGR/d94h3BU4zFQQ7B2ZwZB0wMZS7/v0RHwevr4hvTyD2ziQdl0//Il8Layix829UbhdoS1wHQhgKRf4anIT4r0HRdhaEnxAxQQLd5UHE3R4rtvj6QVqiF6M2gPrTXHSAA3a5IxyYMB7/gQH5VqczOP3NxC+hpaY8w==
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=be+X6BonACq6Cp5f5syVxwZzUx7ypCQ1SqCcA/aaggU=; b=Jqvlmfi88YJqjc2VUpeLLdvWxCUgbV/f84FzJq4q0kivPw4vohbZL3vm2oo8w78Dv8jUy7hj/lMStJ/h/MQ5O8d9KvXmR0+1dVvNYyOqBafNsAgAYEClFZKqoBcAeFAuhCTMZ2UVLlzpp5oWHnw9iJEv+13LZoJZz0mLNhzT+nfptTFD6dbZkg6K5SKn+zrgtNcEwFZC/W399ar8IOzsr8wAprRUaF1UvufTYWojUYibWgwNO0oAy+5tl9q8cMteUUydhxiqrqD+Yb8RTteNGo6sJeYvssZKbOxAtO1odFgcLNPoJqn2AgNXK439ibJPxkpguHPokiR/s734v4z+aw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kddi.com; dmarc=pass action=none header.from=kddi.com; dkim=pass header.d=kddi.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o365kddi.onmicrosoft.com; s=selector2-o365kddi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=be+X6BonACq6Cp5f5syVxwZzUx7ypCQ1SqCcA/aaggU=; b=UEQblufs4I/LfjJfm730OkZeV2g4ZepnunaQpwjYlesoyAGrPMicRIbJB+0QJNHcStVwMWbIxMLAA6RdFu9wwDyQ54C76PCTAZl/k+ieWmrH+Jpa/St7DpHc2tOnp8ndfsjmTm/4jSjPTbEkrDgI/7ZM0UXOgcTPMn1e83Q4Dkg=
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com (2603:1096:404:d5::14) by TYCPR01MB6671.jpnprd01.prod.outlook.com (2603:1096:400:9c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Wed, 21 Jul 2021 04:51:17 +0000
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com ([fe80::7ccb:3ec9:a0c1:25b4]) by TY2PR01MB3562.jpnprd01.prod.outlook.com ([fe80::7ccb:3ec9:a0c1:25b4%3]) with mapi id 15.20.4331.034; Wed, 21 Jul 2021 04:51:17 +0000
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
CC: "ta-miyasaka@kddi.com" <ta-miyasaka@kddi.com>, "ry-fukui@kddi.com" <ry-fukui@kddi.com>
Thread-Topic: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt
Thread-Index: AddQGgjjPNHIAy4gQdSE1NyxH116pQB+BsvQCvX9eGA=
Date: Wed, 21 Jul 2021 04:51:17 +0000
Message-ID: <TY2PR01MB35623E741B9FDC36E0EB244490E39@TY2PR01MB3562.jpnprd01.prod.outlook.com>
References: <009201d7501a$233de670$69b9b350$@olddog.co.uk> <16404_1622023054_60AE1B8E_16404_76_7_787AE7BB302AE849A7480A190F8B93303538F308@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <16404_1622023054_60AE1B8E_16404_76_7_787AE7BB302AE849A7480A190F8B93303538F308@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=kddi.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 072e7e5f-5fca-4dbc-43ee-08d94c032d2e
x-ms-traffictypediagnostic: TYCPR01MB6671:
x-ld-processed: 040b5c43-0c27-49b3-b8e6-cdec886abcee,ExtFwd
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <TYCPR01MB6671A43854462F151C28E20C90E39@TYCPR01MB6671.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wqSBtG6m/klCQ5nzbivNpu7LWxyCYa5nWDzlc6ew5lF8YedYkVQIsGayyIqjj1HKCx/cXESFJc9/R4ZMvjmTd8larS7VsKEEoOQnqL8tfwOh4+dOP67voSjq+0UzRUiSpXZWt71ovanNlxa2QgEHw7ZkF31gMi956xR75pYwAWegbs5Q4Iz8r5/YHAohOGzjwCvhaEBy45H3fEmSmQyj9ukrzJbTYgZ508MyiFX+9dU1a0PfYCbxGrhcvhpZCpzsTA2otP2rUSt8KnB0Oe+le+XD4w7ZjpGtKTrYvF7i3FgmMV78O1IhRqYKiWn3kDFC2JxujPPZn3wiOhI2h08igLMCnuMS+pGUoRESHxOaMWu2vt2NuEdwuyi3nmzuBrxOh/1Gi+MviXWgOAwnM54+xcdVibTX2O+Oaq+a7jKPlTQMEx+u11QfKLFXKmzYkAqNwmTa1iLlwSe0Tzvro6X49tBK2EQyjxmaEhehupZLB4IngyS+llHb4DLLtODB9HtzisfsnacbmZY9Sx0YpoWcZNca23HdbtcZlG94g2uJPks5HgimJPck9mNlclaDaSLfTemdpFQYgoCqbVXbzNK0DO5pDzYrGK9iQeyJB2FJvnJ6AjPWsI1UkAJ9mBh7nHpERQXYvkwmvjBxzFw8fftsxOB3Pb33a82QDmbDA5xTnNrHFidGlwnsdth5FsdsTAfsG/D4gI7Jt4Fhr9JYCUDANf1TR03/BxdNKljyKf07sOIPtKetJ9x3aJeAHwgy8R92WnaJGlkKq/jcGsG1ZB6oMQEV96/NRFDTH0aBX/pELem7GSt2sdiTmCnD8G8sFHp0fs4juF//aDw8eEHMBItaXQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB3562.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(396003)(366004)(39860400002)(85182001)(66556008)(38100700002)(107886003)(122000001)(966005)(26005)(64756008)(2906002)(83380400001)(478600001)(8676002)(53546011)(33656002)(55016002)(5660300002)(66476007)(66574015)(6506007)(66946007)(52536014)(9686003)(71200400001)(76116006)(54906003)(110136005)(316002)(66446008)(86362001)(8936002)(186003)(7696005)(4326008)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YjlubWZyazFoVzc4elBWSEo4czlieEluWUh1L0VkZkZGbGlvZjBub24yV3hY?= =?utf-8?B?Um9nVnEvck56VU85SFNDdEZmaXNJWXE1bmNkZmV6cEhlUnlwamZ6L1EwZDI5?= =?utf-8?B?bHFlMHhyVk5XUnBjVXV1elNDL1Y0NEUyd1UyMWMwTEE2Rm01eVZoK1NWMjF0?= =?utf-8?B?MitxSldiSit1ZE91TnRFck9zU2JjaFZrSHl3OExLUWdDS2phTyticGlYRVpF?= =?utf-8?B?b3Zqd2p6QzFLVE85alRaUFpGMHNjUEdTVXBJYm1ZS1FWWENiZ1NMTUcweVNX?= =?utf-8?B?Rmxianc5OWZGZWFGSkRESERkQnYzRlc1aml0VmRacFZ4MVh5SitDWmNrYm5j?= =?utf-8?B?VEhnN1VDUGlJU3VVaHdKaVluWEpTaWNCM0IwYlNXZmQ2eHhDOHprRmtSa0ov?= =?utf-8?B?R1NIUVNRcnNXY1pXWDNoZ2l5M3M2QkI4aDdoSHBEd0VLZmpnMEs0NEQ5dUZS?= =?utf-8?B?Vlk3c21SWTdYd2ZnNXpQcEFLZGkxWGQ0aStIZ1VDaWxkNFY5THNQNjYwYk03?= =?utf-8?B?M0ROcXJVS1BvcURwdGxoYzNZKzNiaVV5bk9GNWNCM3ZUMHpwVVkyejZybHpG?= =?utf-8?B?cEJpQ1lhQ2N2ekZKU2E1WWxSc0J2RVBiNmRBNFhoRkM4bmlGbGhCNGFaRE9n?= =?utf-8?B?eU1yNlFzdndiTkJHam9GeWJscE1mMzVFUEs4SWlwM0ZGNlk1VGQvTkdkV3NM?= =?utf-8?B?eUdBaUhFR2tVODV0ZGFLOWxtR25CNjJiTXBqclZKYnhvVVhhazRMQXN5UjNY?= =?utf-8?B?ZnpzVGZHRVJYYzhwakRRaFZJT2k3UzFjMVViUjFBQk9KaUVWZGlWZzFNcjlT?= =?utf-8?B?UkVCb21YTXJYVTdxVUhMRXdsNXdpZ0U3eVppRXlobVBRdXd1c0VsaUc3anZS?= =?utf-8?B?aFZieEZHNXVOODVoTGF2b3phNC9XUFFHaU1WOXQ4TTdVbWFRZllWajRWNGJ2?= =?utf-8?B?emhjZ0gyckVZMlZuZHJ0NFZGZVMvSUdxeklKNVRmWjNlRWNsV3lJTVVITG1p?= =?utf-8?B?ODBLMFFoY1JjdmpMUlJSSlJsb01SMHd0Zysva3FKNU5UVDBZUEpKSnd6R0Q0?= =?utf-8?B?WmxXUVNRRGtwRlZQZXprVG11cFJraVVCVmpYUjNoVzVRV29TcjJPWERrc215?= =?utf-8?B?Ri9qNHplWFc0QUk0dzZpNUlJeExTYTdscmpwZ0E5d05sNkU0dXFNOWdJYjI2?= =?utf-8?B?TFlwZE1EQ2ZMc1JoWk1QZlYyOG1FcFVDeE1nSVd1dnZWUFNHZGNTZVpxdEZS?= =?utf-8?B?QVJsckRpdUlYRHJZRjYvRDlhbE9xVXk2clptb3JaU0tXSzVNK1l4NlBydWhJ?= =?utf-8?B?aDc2N054cElWNTdGeUVTSDI0YXZLblhBNjJabm9BQndEVUwxWEZ1ZGdIYm1C?= =?utf-8?B?aDNvNm10bmd2MGRUdVdMWE1KOUt3dUNKN093WjlDb2wrUktVNFFKWTNOUVBo?= =?utf-8?B?SHgxelliMHJNUDZqcEhJOU9vTmlVdklMYUFqQXJ2QVFCdkk2OGFXbWQ3UGJz?= =?utf-8?B?NEozajhGRGxkUG1jbnVPK3RBWEg0UExKVXA3UEJ6cm56aksvVXhNT01BOU1k?= =?utf-8?B?N1Y5bXdNK3laNnlhSXJxNzlXVzlKTkNoOGhuek1EZm5YR2Zac1I5cmcvWjJ3?= =?utf-8?B?NGZyWEN5aUVnOW44MVJ0Z0dBeWtpbXAwL2JaUExGMUp0WU0vdllQY2cvT3ZX?= =?utf-8?B?Nk1HQzExQnRveXBWOCtIajhFVHk1YThzM1pVUE8rczk1QzFLTzR4cWdGQ01K?= =?utf-8?Q?WIDxO9j625lDlmTU0o=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: kddi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TY2PR01MB3562.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 072e7e5f-5fca-4dbc-43ee-08d94c032d2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 04:51:17.5615 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 040b5c43-0c27-49b3-b8e6-cdec886abcee
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 73eTynbAzvE5/Z5czPWPtJMHCxN3CydEuVr2DyNFQ6x6oOTtpddfwhtCjOWX7m5tNcdKZuRxGV79WCTkzmKkdg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6671
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/WZKp2PHrPqH5J5_km8Mz8P2pSVU>
Subject: Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2021 05:01:42 -0000

Hi Adrian and All,

As we touched on "[Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt" thread, we believe a feasibility check functionality is required as one of IETF network slice operations, although PCE is described as one of mechanisms in "5.2.  Expressing Connectivity Intents". It's almost same as VN compute in actn-vn-yang. 

The feasibility check and reservation capabilities are required to avoid complicated rollback operation in instantiating/modifying an e2e(end-to-end) slice instance. Based on that, GSMA NGVT requested ETSI ZSM and NFV to add those steps in their specification, and they added in ZSM003 6.2.2.2, 6.3.2.2 and NFV IFA013 7.3.3. Although TEAS WG received the related liaison before, but the requirement is unclear.
https://www.ietf.org/proceedings/108/slides/slides-108-teas-administrivia-wg-status-02.pdf
Title: LS from GSMA NEST for mapping with slices of different domains via Cross-domain OAM coordination

We believe the exposure of those capabilities on IETF network slice would be beneficial for the consumers. The original requirement coming from 3GPP, TS 28.531 5.1.6, 5.1.21, is to secure multiple slice subnet instantiations forming an e2e slice without any failure and rollback operation as possible. Where a slice instance, e2e slice, is stitched/composed of multiple slice instances, which 3GPP calls as slice subnet, when an NSC of a slice subnet domain successfully instantiates the instance, but the other NSC of the different slice subnet domain may fail to instantiate the instance. At that time, all the slice subnet instances in multiple domains may have to be deleted. Also, the series of instantiation/deletion operations across multiple domains lets our customers wait long time for the result ending up failure.

The set of feasibility check and reservation is coming from ETSI ZSM discussion. If multiple consumers of an NSC exist and request multiple feasibility checks independent in a short period. The former feasibility check result may not be assured. So, the NSC once succeeds the feasibility check, then subsequently just reserves the resource without the instantiation.

All the best,
Kenichi



-----Original Message-----
From: Teas <teas-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, May 26, 2021 6:58 PM
To: adrian@olddog.co.uk; teas@ietf.org
Subject: Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt

Hi Adrian, 

Thank you for this updated version. 

Please find below two comments about Sections 3 and 4, fwiw. 

(1) It seems there is an internal inconsistency as we say in 3.1:

   An IETF Network Slice is a logical network topology connecting a
   number of endpoints using a set of shared or dedicated network
   resources that are used to satisfy specific Service Level Objectives
   (SLOs).

while we have in 4.1:
   An IETF Network Slice service is defined in terms of quantifiable
   characteristics known as Service Level Objectives (SLOs) and
   unquantifiable characteristics known as Service Level Expectations
   (SLEs).  SLOs are expressed in terms Service Level Indicators (SLIs),
   and together with the SLEs form the contractual agreement between
   service customer and service provider known as a Service Level
   Agreement (SLA).

I think this can be easily solved by removing the SLO/SLE taxonomy. 

Things would be much simpler if we just focus on service requirements without making an assumption how such requirement is expressed and whether it is quantified/quantitative/qualitative/measurable/etc. Whether/how a specific service requirement is covered by service assurance/fulfillment can be part of the slice service definition itself. 

Also, some of the items that are tagged as SLEs are questionable. I'm thinking about the encryption, for example. This can be verified at the provided-facing interfaces or at SF (if such resources are part of the slices). 

We are adding extra complexity for the modelling part as service requirements will need to be classified based as SLO or SLEs. If that classification won't drive the modelling, that's a reason to remove it. 

An "expectation" may not be easily assessed using current techniques (and thus be tagged as SLE), but this does not prevent that innovative means would be defined in the future (which means that it is an SLO, not an SLE anymore). For example, proof of transit mechanisms can be used to assess the nodes that were crossed and may fed any non-via constraint in the SLE/SLO. However, PoT have some implications on the underlay nodes.  More optimized means would be proposed in the future. 
 
What is really important for the customer to assess that the delivered slice service is aligned with the requested slice service. A specific "SLO" may be honored, but the overall delivered slice service isn't. 

(2) It seems that some clean-up is in needed in 4.1.1:

==
   SLOs define a set of network attributes and characteristics that
   describe an IETF Network Slice.  SLOs do not describe how the IETF
   Network Slices are implemented or realized in the underlying network
   layers.  Instead, they are defined in terms of dimensions of
   operation (time, capacity, etc.), availability, and other attributes.
   An IETF Network Slice can have one or more SLOs associated with it.
   The SLOs are combined in an SLA.  
==

vs. 

==
   SLOs define a set of measurable network attributes and
   characteristics that describe an IETF Network Slice service.  SLOs do
   not describe how the IETF network slices are implemented or realized
   in the underlying network layers.  Instead, they are defined in terms
   of dimensions of operation (time, capacity, etc.), availability, and
   other attributes.  An IETF Network Slice service can have one or more
   SLOs associated with it.  The SLOs are combined with Service Level
   Expectations in an SLA.
==

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:teas-bounces@ietf.org] De la part de Adrian Farrel 
> Envoyé : dimanche 23 mai 2021 23:25 À : teas@ietf.org Objet : [Teas] 
> New revision: draft-ietf-teas-ietf-network-slices-
> 03.txt
> 
> Hi WG,
> 
> This is a housekeeping revision.
> 
> - Picked up some editorial comments from Kenichi and Xiaobing.
> 
> - Moved the definition of 'customer' up to section 2.1 as requested by
>   several people
> 
> - Added a definition of 'provider' to section 2.1 per Oscar
> 
> - Fix (i.e., remove) use of "Network Slice User"
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of internet- 
> drafts@ietf.org
> Sent: 23 May 2021 22:03
> To: i-d-announce@ietf.org
> Cc: teas@ietf.org
> Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-
> 03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Traffic Engineering Architecture and 
> Signaling WG of the IETF.
> 
>         Title           : Framework for IETF Network Slices
>         Authors         : Adrian Farrel
>                           Eric Gray
>                           John Drake
>                           Reza Rokui
>                           Shunsuke Homma
>                           Kiran Makhijani
>                           Luis M. Contreras
>                           Jeff Tantsura
> 	Filename        : draft-ietf-teas-ietf-network-slices-03.txt
> 	Pages           : 32
> 	Date            : 2021-05-23
> 
> Abstract:
>    This document describes network slicing in the context of networks
>    built from IETF technologies.  It defines the term "IETF Network
>    Slice" and establishes the general principles of network slicing in
>    the IETF context.
> 
>    The document discusses the general framework for requesting and
>    operating IETF Network Slices, the characteristics of an IETF 
> Network
>    Slice, the necessary system components and interfaces, and how
>    abstract requests can be mapped to more specific technologies.
> The
>    document also discusses related considerations with monitoring and
>    security.
> 
>    This document also provides definitions of related terms to enable
>    consistent usage in other IETF documents that describe or use 
> aspects
>    of IETF Network Slices.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-
> slices-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-
> slices-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas