Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Thu, 15 July 2021 01:56 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 C9E333A157C for <teas@ietfa.amsl.com>; Wed, 14 Jul 2021 18:56:54 -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 JDKzNximx6XG for <teas@ietfa.amsl.com>; Wed, 14 Jul 2021 18:56:48 -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 B88143A157B for <teas@ietf.org>; Wed, 14 Jul 2021 18:56:48 -0700 (PDT)
Received: from kddi.com ([127.0.0.1]) by LTMC3103.kddi.com (mc MTA5 1.4) with ESMTP id 521071510564370500.25056 for <teas@ietf.org> ; Thu, 15 Jul 2021 10:56:43 +0900
Received: from kddi.com ([10.206.2.120]) by LTMC3103.kddi.com (mc MTA4 1.4) with ESMTP id 421071510564279000.25028 for <teas@ietf.org> ; Thu, 15 Jul 2021 10:56:42 +0900
Received: from kddi.com ([127.0.0.1]) by LTKC3124.kddi.com (mc MTA19 1.4) with ESMTP id j21071510564178900.03732 for <teas@ietf.org> ; Thu, 15 Jul 2021 10:56:41 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA16 1.4) with SMTP id g21071510564078200.03642 for <teas@ietf.org> ; Thu, 15 Jul 2021 10:56:37 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA11 1.4) with SMTP id b21071510563978100.03567 ; Thu, 15 Jul 2021 10:56:37 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA8 1.4) with SMTP id 821071510563878000.03478 ; Thu, 15 Jul 2021 10:56:37 +0900
Received: from LTKC3133.kddi.com ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA6 1.4) with ESMTP id 621071510563775800.03392 ; Thu, 15 Jul 2021 10:56:37 +0900
Received: from LTKC3133.kddi.com (localhost.localdomain [127.0.0.1]) by LTKC3133.kddi.com with ESMTP id 16F1ubok019724; Thu, 15 Jul 2021 10:56:37 +0900
Received: from LTKC3133.kddi.com.mid_2261114 (localhost.localdomain [127.0.0.1]) by LTKC3133.kddi.com with ESMTP id 16F1kbQG014620; Thu, 15 Jul 2021 10:46:37 +0900
X-SA-MID: 2261114
Received: from LTKC3146.kddi.com ([10.206.20.232]) by LTKC3122.kddi.com (mc MTA 1.4) with ESMTP id 121071510463675900.03903 ; Thu, 15 Jul 2021 10:46:36 +0900
Received: from LTKC3146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id A23C013C0069; Thu, 15 Jul 2021 10:46:36 +0900 (JST)
Received: from kddi.com (LTMC3102 [10.206.2.46]) by LTKC3146.kddi.com (Postfix) with ESMTP id 98B0213C007C; Thu, 15 Jul 2021 10:46:36 +0900 (JST)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com ([104.47.93.56/tls]) by LTMC3102.kddi.com (mc MTA 1.4) with ESMTP id 121071510463646400.30483 ; Thu, 15 Jul 2021 10:46:36 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k8RjJx4EbPi0NOfRoukUkl6lwZa6Es8aGzXAT6BIHAp+9hF+p9Oix8wpOG/Jxj285H+KfDiMftcyoJX1hp1DLVrNF1klXuwLsP+hWTbuCRBhLP1AjPoLE3HDU9RkeQgKQMbeyIDHNcs9Pp7ZLZu3lAY3a68SqcHFua9PXIF6fHtjFYm7m2tiZ4RtUGcOU3V2dqbnTIqnuVbvg2fGIzaQhJrNZAsTSPmFgPiVf9XW/BheG60eLdWP9D7J2k/t64JJNViA9qudIU8VLhlkoSOSkJ1Ct3uZ0aDcXzc6hp1vUpW22pwUnK2u3biWiu/DAzEMmExeSI50oJu2JdTtLbTZNg==
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=UBcPxc4X47H3veT11RjtEDS4wa/lZynlvH1NlLoSGdc=; b=QvqSGHCCTHCurecyZiol92Fg4GpghiJpZWFmwvkGH0SYIFbEc01JJfBP69bJS0ujPL4BwNuqJab18uRgoCCiE1UJU2/1PxnCFebVJvNzCWW/9/o6cRR+z8e/X3d5crssYMpao66KZLKTar3fcVFGRzgs3fscAgUVI6d8A8JlCTDILX7ne7V5NPkinG/n1F9ijYNTJdr0UYkDVEeMpGy/D3pfB42HVMeNMWULcRB6LOkmEXvmzT9UoovHd17PenU8CtDsP0uApIxfw4j5FEFMuBE+t6GBeco08ydUk9dud6grOB1WO3xfPDBrJo1vN0xVny3iSRbOkLo7mlwJgVwJfg==
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=UBcPxc4X47H3veT11RjtEDS4wa/lZynlvH1NlLoSGdc=; b=NuoFPxKIKFRzMSNn3kdNKsvLAoKM5sLQC16L+YlA713eOyKswgtixsGUg6//w/DU+SOTFHosPEUn3aRfVdEg71aIciaC4LEX04uqRJfqKZ9QBNMsI5azuKOKzfQZTnND4+XLKOD43sbAq1gXLic6LTHIm053MIF6zz1paPqlSdg=
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com (2603:1096:404:d5::14) by TY1PR01MB1562.jpnprd01.prod.outlook.com (2603:1096:403:6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Thu, 15 Jul 2021 01:46:35 +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.4308.027; Thu, 15 Jul 2021 01:46:35 +0000
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: Tarek Saad <tsaad.net@gmail.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt
Thread-Index: Add0pWXcMR4RO95mToa1bmfXm/Vx9gACuNfQAIovv1AAYoZrBAAtXXpg
Date: Thu, 15 Jul 2021 01:46:34 +0000
Message-ID: <TY2PR01MB3562D505EC92F9CC2A3B3FBF90129@TY2PR01MB3562.jpnprd01.prod.outlook.com>
References: <85c01cfa78304e359d5dd204eff7f7b6@huawei.com> <18848_1625832351_60E83B9F_18848_170_1_787AE7BB302AE849A7480A190F8B9330353BAF50@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>, <TY2PR01MB35623D2063B54E572448CF8490159@TY2PR01MB3562.jpnprd01.prod.outlook.com> <DM5PR1901MB2150C07974A523E9DCFF11E4FC139@DM5PR1901MB2150.namprd19.prod.outlook.com>
In-Reply-To: <DM5PR1901MB2150C07974A523E9DCFF11E4FC139@DM5PR1901MB2150.namprd19.prod.outlook.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=kddi.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ee872fe0-0055-4004-bfa9-08d9473260f8
x-ms-traffictypediagnostic: TY1PR01MB1562:
x-microsoft-antispam-prvs: <TY1PR01MB156251147F8F50A8CCE5660690129@TY1PR01MB1562.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: /v6Nex0U3wzpB2axgnsmq3EfL4dPnxsBK6PzzFT62DTP8wqZLINzDd9LgKCtFV8Q493Qb0tJDfm3+ijhsQbZj66DTKXeIerPcAgF3leCvx/piqYIJARpfzbVbSmECClNHBWmfMFHKjiiM4AP/7u2+BTBC6iFI7/otfLfYb9DlKgId1XyVn6RN1jPtXkJtIqNpk4CM6E+opVSMqBD04F+sEoKf/uvYcE7T/XXyJfwFiW2u5bHHHiMRae/Xh0g230Sxs3MSiA59jRNWGvdlCvWBf9n3+NF0aEqKAXlo1qNdMU7eSeZfghoFyvR0Qffv33ydLJyDDm6JQ8A7mAjngypZmT3mLX25iqDsbi7M7KDMzfabckmQEihzVtZ8GDZz+SXy7hxKTVInTszSma4eXNOtFQCGT9pd3H82Eoqi5qgvM4/gjvEU0AHeuouos2zGAvq8IpDiFz5VZMt7ybtMp444ncG4ybJoE1MKJkP9ySJV3gdRA9eTEbMZmNLTFc5CD1Qz3/J605MIK7shiX0APwy7dpGyJcGeX0H6ytDl3s/3bJV38ZtQwkWe+qbukpk/Pv4flqnOPUkHRFqyUWXT2VYGxKDnKCLcbFDt73Q3Tcn+M0O63gSjD7iMEVmOfklYoCRQrlYyYhEjvI/iS5h7Hlww0lHQY75gqqrlPhtm6uV/MPJotCH/vF15Qv0GNrWVpKQQ9oYru+zTdG9LXVjUFRgylwgeRk8etUe9vLKA+f6Ws+Qu8y0t/xRgwoZlvcE3lDTUZLDAQvowJm/mbz5ppt7KMflRwDudNwxuJbR0P28kF5JoqRSBVU/VJHSCeN1+sImtk+G3hmXqGkqWV3XiUnbVw==
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:(366004)(15650500001)(83380400001)(478600001)(5660300002)(2906002)(71200400001)(30864003)(966005)(85182001)(110136005)(66946007)(55016002)(7696005)(53546011)(52536014)(64756008)(9686003)(6506007)(86362001)(66574015)(8676002)(66556008)(26005)(66446008)(38100700002)(186003)(8936002)(76116006)(316002)(122000001)(66476007)(33656002)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TG1XQjQ1Ny9QMHRPNU5FMXc1ZmpzT3oxdE1GeFBIODlhMFVGdGRVNFN2dDNL?= =?utf-8?B?N2lZRkYwU0pRSlRvME9sUUJtamg2Z1hvNmcxYXhIV3VTU2c2TWxSdkhDcWpC?= =?utf-8?B?MkRDanlxMkl0YWR3cndQWDJCU1d1YjJ0M081eUlkcUEvQWZZUFI4NWZtRnJ3?= =?utf-8?B?dW1ST1hTaThBMzgxT2lFWXlXUnJoWkVzVjIxbTNBMzMwMi90OEkrQlpHeFho?= =?utf-8?B?K2sybEo0d1FXZjVnMEs2NVA4ZEJ0Z25qYVJjcVVIWThWYkc2ckt2dHQ0YkU4?= =?utf-8?B?WXRXY2N2ZWMvLzNHUzFMbHBRbS9aMDFtZEZIYWlKa2dmOWtNdEpQY0JUZkYw?= =?utf-8?B?M1E2MmIzaWVxVmUrYWFXeVY5eWJtblp4OXNIaGsxcFNyN21odDA3SW41ZWJo?= =?utf-8?B?NXJ4UkNkTmtJeDBaSmpMTjB5RVVTRDZOTTVVemwvS3dDZ3g2c3VvYlNNQStj?= =?utf-8?B?VStPc1NvQ0ZNckxRdmxWcVJsaDJyRWxUcC9xNlRiR3pBbkZtSURJS0M4TGJU?= =?utf-8?B?QmxoU3c0NWEzOC9LT1QwTW51a25wbVJyM2paWXlleXhhcjdTMWE5bXBMOVdv?= =?utf-8?B?ZTUxR2xSSFRYaVRyVndWQUFQMFBGMVBOSm1xQ3l4SkRYTUVGdVh0bmlkVHc3?= =?utf-8?B?LzJqMzNnZ0lyb0k5eDNVZW9WRlg2NU4vZUtUR3dlSHhERGY1SFA2UXdWcjNP?= =?utf-8?B?SjR3VndCT0lsQ3MxRjZFOU9hYWdRZXVIeFVNUGJ3ZGRFcnRCWGRKNXdsOURZ?= =?utf-8?B?NmVSVTlwS1YvQUs3NGZwaDZGTmdVY2RDMGZaNjRnTmNYMWZZTnhrNXhtKzVP?= =?utf-8?B?SmFrY1FpQkdZdks2MUJCZ21CRS9ZMWdMYUlXbFBpUmhJekZrNmw3Z1FIQ0hR?= =?utf-8?B?Qk9DdUhJM3pQdDR0RGlCdE9WQlpaVlpRa1l5aWVhK21aY0VPLzJzMWZ0Z3Fk?= =?utf-8?B?SS9NdEZNd2JnWkhxNjFtdFpReGJzNGlyN1l2andOSjFFSm80NUZzSHVYaExw?= =?utf-8?B?RkVTTzczSUl1U25CRlhQc2ZhSkRiOXVzclg3SHJ5RFNpbjhFUVB0S2ltT1dx?= =?utf-8?B?cThOc0ZsU0lIL0dERHc1L3FFdE1jaHVhWU9FcEJkdkVxc09zL2I5L0ZLNFBx?= =?utf-8?B?eUZ5V1RSY09JUC9zMUVxcWNsNDJ3RjRHNVBjYzQ0ZW5CNGc5cHc0aEYvVTQv?= =?utf-8?B?U2JYMzMzbEJjbWsxS3lqTXZncEltUnh1NFh2d09Fams0dUhPT2VTSlowS3Ra?= =?utf-8?B?dzU1aVd6Sm1SamN0MXdWK2l1WjZTaEdMUDQvcEZTQWhpcGMzUVRwOHJneVkz?= =?utf-8?B?cm1ja2RGdTNOc0F3R24zY29DOEtpMHpwUXR4dHlVeVM4ek5HYUQwejBRbVZk?= =?utf-8?B?RDNjR3ZqNGJyT3huWUo1b05aRHFuMWR2bm1KVlJZdm5QdGJUTFhqa1pDRDFx?= =?utf-8?B?ZFNQU00zbDhiVTAvejNjM2l1WG9URGYwR0tkbVRJVEJPY2J0SkNEcFJiVU13?= =?utf-8?B?N3ZveTB3ZVdhbkpaRERJakFEdTAwdnJlSy9leUNWUVpya0RJYmg2U1FGd1I5?= =?utf-8?B?REdFUkpWMzlTWGFxTFlLT1VZME1kUFhnMm00cU84MHlLWjM0RmtWdWVROUFG?= =?utf-8?B?QXp3cWYvRCtxdW1ES0hrQ2FseUlEWTAwbDJDQUkyTnRqNGQ3QWgxRERSUXVt?= =?utf-8?B?VjZUekRlNlVmRmxsZkZLc3VYdGF2VlphdHZNRXptcXR2SS9vdUFvUFUzSzV1?= =?utf-8?Q?YceRNt5yQqIj6gIasc=3D?=
x-ms-exchange-transport-forked: True
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: ee872fe0-0055-4004-bfa9-08d9473260f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2021 01:46:34.9328 (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: PszvM5+NzLQ4GHrjUngQe6EIDM7ZfhZH7pYt1WhzgXv5uE2t5jpGKom8e67hwXBTopdSjxursn2qRDOWubAXGg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1562
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6cnrPlylAxi1ReEEQ0DdPUhMRds>
Subject: Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-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: Thu, 15 Jul 2021 01:56:55 -0000

Hi Tarek,

Thanks for your comments.

See comment inline [KO], please.

Thanks,
Kenichi

-----Original Message-----
From: Tarek Saad <tsaad.net@gmail.com> 
Sent: Wednesday, July 14, 2021 1:25 PM
To: 大垣 健一 <ke-oogaki@kddi.com>om>; teas@ietf.org
Subject: ***フリーメール*** Re: New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

Hi Ogaki,

 

Thanks for the review. Some possible answers below inline, see [TS]..

 

On 7/12/21, 3:13 AM, "Teas" <teas-bounces@ietf.org> wrote:





Hi Authors and All,

We have some questions how to proceed this work.

1. How should we create a new solution where the solution is similar to an existing solution?
 As Dhruv, co-author of both drafts, should know well, the many functionalities of this nbi are same as those of actn-vn-yang. As described in B.1, we agree that actn-vn-yang is only focusing on ACTN and this nbi is technology agnostic.
However, draft-ietf-teas-ietf-network-slices definitely addresses the applicability of ACTN. So, this nbi should at least import actn-vn-yang and refer the nodes defined in actn-vn-yang?
I'm not sure how to create a new solution for such a case.



[TS]: ACTN is one toolkit that may be used realize network slices. The main network slice I-D.draft-ietf-teas-ietf-network-slices references it as an option (in section 6.2). 

“   While the ACTN framework is a generic VN framework that can be used

   for VN services beyond the IETF network slice, it also a suitable

   basis for delivering and realizing IETF network slices.


[KO] As we already wrote, we totally agree that IETF network slice is technology agnostic.
Our question is how to create the NBI/data model solution?
Before creating the IETF network slice solution, we believe the gap analysis between IETF network slice and the existing solution, e.g. ACTN, is conducted and draft-king-teas-applicability-actn-slicing is doing so for ACTN.
If the gap is small, the existing solution may be enhanced to meet IETF network slice framework. If this understanding is correct, it shouldn't become the reason which excludes the existing solution that the existing solution is not focusing on technology agnostic, but discuss each function.
“

This NBI YANG data model is not dependent of the ACTN toolkit an hence does not require import the module actn-vn-yang.



2. Solution comparison is non-sense before the completion of framework.
 Appendix. B compares this nbi with the other existing work. However, the criteria of the comparison is unclear since the framework, requirement/architecture, is not completed.
If we can say anything with no criteria, the current actn-vn-yang defines VN compute functionality and this nbi doesn't have. Although the framework draft may not explicitly require this, the other SDOs developing their own slicing technologies require/define this functionality as the feasibility check, and also expect to the other SDOs, e.g. 3GPP TS 28.531 5.1.6, 5.1.21 and NFV IFA 013 7.3.3.



[TS]: the current version of this I-D attempts to address the NBI requirements already identified in I-D.draft-ietf-teas-ietf-network-slices - although it may not currently have exhaustive coverage in this revision. Indeed, the current data model allows to map VPN traffic (identified using several options) onto the created NS connectivity as means to realize a network slice.


[KO] What does the latter part, VPN traffic mapping, means?
If it's about VN compute, that is a kind of resource check function before creating a slice. We believe PCE should be used behind.

 

Regards,

Tarek (as a co-author)


3. Others
sec. 6.3.
We cannot understand NSE examples in 6.3. As discussed on "[Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00" thread, we wonder if it seems to reach the rough consensus that the demarcation point of a slice between customer and provider is the boundary of CE-PE, i.e. AC.
If correct, why Figure 4's NSE is PE and Figure 5's NSE is CE?
Someone said NSE must be controllable from NSC in the sense of SLO/SLE. So, is this CE controllable from NSC?
3GPP TS 28.541 6.3.17 EP_Transport is referred in 6.3, but our understanding is different. EP_Transport was introduced with the discussion paper, "S5-203253 TD proposal to add transport endpoint in NRM.doc", and this paper describes Cell Site Router and Border Router as the transport network edge, i.e. PE, and, Application endpoint and logical transport interface as the RAN/CN slice subnet endpoint which means CE's interface.
In this case, NSC cannot control this CE in the context of the following description in sec. 6, for example.
 "The "ns-endpoint" is an abstract entity that represents a set of matching rules applied to an IETF network edge device"

When we refer the other SDO's document, the interworking between SDOs may fail if we don't understand correct.

sec. 6.
The usage of "ns-tag" is unclear.


All the best,
Kenichi

-----Original Message-----
From: Teas <teas-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: Friday, July 9, 2021 9:06 PM
To: Wubo (lana) <lana.wubo@huawei.com>om>; teas@ietf.org
Cc: teas-chairs@ietf.org
Subject: Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

Hi Bo, all,

Thank you for sharing this updated version. 

I'm supportive of this work, but I think we have a fundamental point to clarify: the document is currently missing data nodes that makes a slice, a slice! 

If we don't have such data nodes, the current module can be used to provision any form of connectivity. If we omit the "ns-" prefix, the module can be used for provisioning the connectivity of VoIP, multicast, etc. services. That’s actually good (as the applicability scope is wider) but we need also to think about network slice specifics.  

I have touched on some of these points in a review I shared with you back in 02/21, but unless I'm mistaken I don't think it was addressed:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-wd-teas-ietf-network-slice-nbi-yang-02-rev%20Med.doc 

Below an extract of my main comments: 

(1) A proposal to rationalize the discussion and ease progressing the spec is to clearly call that a network slice can be defined as a collection of at least three components: (1) connectivity component, (2) storage component, and (3) compute component. Having a provision for this since early stages of the model will ease grafting other components of an IETF slice easily, but also allows to avoid having a linear model.

(2) For the connectivity part, the following items are important to cover as well:
* Traffic steering and advanced services: a slice may require the invocation of service functions (firewall, for example) in a given order. These policies have to be captured in the slice request. This is also useful when the customer request that its slice should not cross some networks or not span some regions. 
* What to do for out of profile traffic: See the traffic conformance discussion in RFC7297. 
* Activation means: may need to be included in a slice definition. Think about a slice that can be implemented as a VPN service. Such service may require the activation of a given routing protocol between a CE and a PE, otherwise the service won’t be offered. 
* Invocation means: Think about a multicast service that requires IGMP/MLD and so on.
* Notification means: these are important for service assurance and fulfillment purposes.

(3) The model seems to be inspired from the opsawg vpn I-Ds (network-access structure, for example). That's great and appreciated, but I would formalize that by using I-D.ietf-opsawg-vpn-common for data nodes such as connectivity-type, endpoint-role, status-params, etc. 

(4) One last comment, I still don't get what is an "underlay IETF network".

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:teas-bounces@ietf.org] De la part de Wubo (lana) 
> Envoyé : vendredi 9 juillet 2021 12:18 À : teas@ietf.org Cc :
> teas-chairs@ietf.org Objet : Re: [Teas] New Version Notification for
> draft-wd-teas-ietf- network-slice-nbi-yang-03.txt
> 
> Dear WG and chairs,
> 
> The draft has been aligned with changes in the IETF Network Slice 
> framework WG I-D.
> 
> The Authors believe that it has been maturing with the inputs from the 
> WG, and can be evaluated as a candidate for WG adoption.
> Diff: https://www.ietf.org/rfcdiff?url2=draft-wd-teas-ietf-network-
> slice-nbi-yang-03
> 
> Best regards,
> Bo (on behalf of the co-authors)
> 
> 
> -----邮件原件-----
> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> 发送时间: 2021年7月9日 17:32
> 收件人: Wubo (lana) <lana.wubo@huawei.com>om>; Dhruv Dhody 
> <dhruv.ietf@gmail.com>om>; Liuyan Han <hanliuyan@chinamobile.com>om>; Reza 
> Rokui <reza.rokui@nokia.com>om>; Tarek Saad <tsaad@juniper.net>
> 主题: New Version Notification for draft-wd-teas-ietf-network-slice- 
> nbi-yang-03.txt
> 
> 
> A new version of I-D, draft-wd-teas-ietf-network-slice-nbi-yang-
> 03.txt
> has been successfully submitted by Bo Wu and posted to the IETF 
> repository.
> 
> Name:         draft-wd-teas-ietf-network-slice-nbi-yang
> Revision:     03
> Title:                A Yang Data Model for IETF Network Slice NBI
> Document date:        2021-07-09
> Group:                Individual Submission
> Pages:                45
> URL:            https://www.ietf.org/archive/id/draft-wd-teas-ietf-
> network-slice-nbi-yang-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-wd-teas-ietf- <https://datatracker.ietf.org/doc/draft-wd-teas-ietf-> 
> network-slice-nbi-yang/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wd-teas- <https://datatracker.ietf.org/doc/html/draft-wd-teas-> 
> ietf-network-slice-nbi-yang
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wd-teas-
> ietf-network-slice-nbi-yang-03
> 
> Abstract:
>    This document provides a YANG data model for the IETF Network Slice
>    Controller (NSC) Northbound Interface (NBI).  The model can be used
>    by a IETF Network Slice customer to request configuration, and
>    management IETF Network Slice services from the IETF NSC.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> 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
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas