Re: [Teas] New term for the underlay construct used for slice realization

John E Drake <jdrake@juniper.net> Wed, 11 August 2021 15:33 UTC

Return-Path: <jdrake@juniper.net>
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 E50203A1A66 for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 08:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level:
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=ZHmXuTuO; dkim=pass (1024-bit key) header.d=juniper.net header.b=BGjJkZ4L
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 STksygHJp7EU for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 08:33:19 -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 7EB6C3A1A60 for <teas@ietf.org>; Wed, 11 Aug 2021 08:33:19 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17BFT3jO028289; Wed, 11 Aug 2021 08:33:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=OuMShk0W+n6C9pqYKmZXLuM3kscQ6QxALlBaPIHbLpA=; b=ZHmXuTuO5myaz3iCpHFEkZiCnZZHdy/qShGEPhhn6Af15Vbr9wIw9/LKP0tIH+0pR4yA 560h5AYG4OuelClQcEVODRe44eATt6i4gYXoaY7mqkiblw92EsE9uflhBwNpZlBqMqRd L8AS3nUVeQ2SX9KuVXDu4i9WRr6abnVLas63Y41YSpe1OhEFQPKF7hPvDOe/afqg4hY9 Q20+/JUvC53LgfP7HMgZbkoVyCtf0PkZafiFpmLCQ7HxWvcA2F0bGcByTXrUD3+QWtn7 8uhsAJjgbr/2QbDMD3uIzdNonNkw90Bh5pd4tbGxSsOBbAJdxrpMVglJS4n04slBwVno JQ==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0b-00273201.pphosted.com with ESMTP id 3ac442197n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Aug 2021 08:33:09 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EhVyMald5ByV5eqPYr70iuXHG0WjFwQ2HmxA1jscVFXEGw1l7ZcQm6/8y020f+D5hi5ABnDtUsZqys/dq3IxsIvt0O0mE2tfFUiXVht1yrXZP3ca/kfRiiyqQ7pqJ+hPkCK2hDRotyeiiln/RunOOo5dofz15ZEiX4+X3w94uqPnS9oX802vWM/+VOlCTMNPuI4zj/oXdYxFChn1nzKdf/G2isZAYy0WJEnIt25ihlspGWorksxi/CqYxPJ6S7jnLstDFuINYfFW4pi1hYFPPYfBKKpN80ZLjVo0LPwdQ/1H1ACa+E/8hhqNzcejoqvU/1BkyR6yICmFgZzUslLkDQ==
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=OuMShk0W+n6C9pqYKmZXLuM3kscQ6QxALlBaPIHbLpA=; b=Gcq6gW/vnjAtMMPz8GmJPZnkLNDwmr/7vTP/p3JVBISU9nuQnQZK/cG6LVTqUP1YagDYn3bAJZe+2O6bE+02iepJW7PrCDfH6xVLe6iuvUeEwa+axEwezTGIZG1HHwRVIbG+qHCdZP144vW3zTrDHoYQu786/dHVIZoYOQDK1SLrxJKoWAUF2CjWRP/RFOVoSX3SINoCfW/h1exYggTbAy+sGAhkF4MOJ4iMmlsj9umCHps4+HVkr667y0LR9XwlmnFWvSj4oq4UFMV5tLyeC4Vvo5xCWJ0Dwi/hIxbXveP813iJTEjbrEuoSl1Vi//z7AzBOaJ15fugLnAzccpOBA==
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=OuMShk0W+n6C9pqYKmZXLuM3kscQ6QxALlBaPIHbLpA=; b=BGjJkZ4LyWI/KmnkaQHlw+3eQMif1/OJJRCIZnHwyBcfO1xRSsvh64ZfQZVtDxkuvyxz+mkMFsYcvt5QWVdwQqJvcAkBFOi8oHXSa9gPM/Xs+09yCAKLdqwrET4X41fmGa/8QB3vX3HCcA/S7HlwgK4nq6iSvN2/Zsl4G/iixsc=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BYAPR05MB5798.namprd05.prod.outlook.com (2603:10b6:a03:d0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.9; Wed, 11 Aug 2021 15:33:06 +0000
Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::c0ea:d0b2:bc21:5e4d]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::c0ea:d0b2:bc21:5e4d%9]) with mapi id 15.20.4415.015; Wed, 11 Aug 2021 15:33:06 +0000
From: John E Drake <jdrake@juniper.net>
To: Kiran Makhijani <kiran.ietf@gmail.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Lizhenbin <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Re[2]: [Teas] New term for the underlay construct used for slice realization
Thread-Index: AdeN+wpTY0PlvtVsQlC++M4sZJMfAAAHO8wwAA9dd4AAFeyW4AAFGT2AAABtCZA=
Date: Wed, 11 Aug 2021 15:33:06 +0000
Message-ID: <BY3PR05MB808141E1A225DBB9E0BFFAAAC7F89@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@by3pr05mb8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com> <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2>
In-Reply-To: <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-08-11T15:33:05Z; 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=555f3255-c1c3-48ca-8236-67bc61ecf435; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2ade4e1d-ec79-40da-abf2-08d95cdd50e7
x-ms-traffictypediagnostic: BYAPR05MB5798:
x-microsoft-antispam-prvs: <BYAPR05MB5798A315DCF58702142E54B8C7F89@BYAPR05MB5798.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: owdCOgm1nGp2+0Jxl1svxTokKiEiemBHPZRc703EIDBKonsSSZIgU+XmCNgE0spVYonVWeNGVCJk9JvOZOwFRLGllVsYy+N+cOB2kWiMvAFa494XVHADUusMUyv2BQ3G1EOjirqzHVtb8tEJlPGlDQSHnYYIAbUaHblYZg93mR+ibPJzyfZM6/K/17UocRPVxpVr/Xgg9jUMt2r02YHy9aL3eE/xoBME5KEBdZEpVY29JqhdE4COOBId7IB9bV67JiPuh3poYJWV9ScnJZSGT+8s890rVtv6WQrDGIX9cS1z+/WtIjMvMfR8ZW2Quz5esmkLhMgKKzjdjGM1bat4RjIAEhMPbeAd8Q+r4SYVDT12N6Ru2SVuC7qg9KRWZqkrEhooAbklTbOATdEa9JRYvl93AGmopB0az5pxivpNWa+J/FCxf1V8CprvFXOXaFrvZfTUwz/DoDZqnbinnR6L0vpLmSIXqAVEPmzsvSEYIcp0VyFmTGeLU3hDzNxvq4AoL3fsiaEQ9/mhY6UdcQpdW7SiT1aFJx453Fu6a0Tf58EQsFyeWsIw+qn+2dVIzIM/sn6kTif5XvcWa9R6Bk3vfSV7iT6DD6h1pZ/o8BKBmA2V1XBTLIjAQ1Fi/ArHm+KENYI2FCPe3mbKJsSmyaL53HS68IynMpI30ZIl4VTzfJUlfALEDX3MOIBMGz058WR6wQJJGf4Iq2/dpxC876q+ORmuqiJ3zgEBDF+8m+yKtPkN+k5lYa+zfJdPdFVPSHD07yD/r1r+VLH4CHa7HucG+smrfbNy5JgMc1WvDnFjC4QVx2Ab/MoCTIa2JEBkDJZW+ZKg6OZsr49VP0CkLpBkyg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(9326002)(33656002)(52536014)(8936002)(8676002)(71200400001)(166002)(966005)(83380400001)(508600001)(186003)(26005)(66946007)(66476007)(66556008)(66446008)(64756008)(316002)(53546011)(6506007)(86362001)(2906002)(9686003)(7696005)(55016002)(76116006)(110136005)(122000001)(38070700005)(38100700002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fLjjSb1uvuLLzXOnxJCEulwj42W5qESpy02bcqMPnjnmJ0HBIDNqR5kgQvQz?= =?us-ascii?Q?w3hHrr2wsMWQd49v/8O/1TQrn8vO07ilcj75fUXszg6EoxdPuWpCqWt1MFB2?= =?us-ascii?Q?jGJtibrd13xdpipqr7CD4LaWAjOSqdFm3w7SrvVSuA3lcyFzXYQhqHGsCoXZ?= =?us-ascii?Q?l0ANo02h1DY2DnPIs2f3dmv9zaH0FW/wxg5vXIqe2eLa6NWpSyNZJjLWMPFS?= =?us-ascii?Q?3L0UJW5/p4oRcYSq6DhAkJt7YkYovp13rWyY2JQ0Uw3ZskMbUZwErVw7QcIp?= =?us-ascii?Q?/rVkg1QICpKcu7PVjZgvDf1lOtPsq/Gppza5FcHcOMjcn3Etj65CfQTVOtK6?= =?us-ascii?Q?AnEiYJMPfLY5SMtp4BSRdigKwKT6H3j1JRUcEDOcmCSrm22PY+J4/SuPUO4p?= =?us-ascii?Q?uaaNI0UnYGm7AuD6oSPVSBfukW5+riaiaGMJPHcJQ3hYUPNZogzyjwcj6DSu?= =?us-ascii?Q?EnRew134/sAqjgs0iX6uvMKt8HlpREZnK3eIiZQr1lcprHoSm6rzHnDSPJ8K?= =?us-ascii?Q?s06+qSRlAl0zD7pvkpUXmTCmdjlpjVZM5nX3kfr585yXsBRdAjxnLbQZJVKq?= =?us-ascii?Q?LzoQsBXjM0SkXR+6lHQsYCSPKZZ7iPvjHqWBGuLbYfUsh6E+pjfWtRpAuIcP?= =?us-ascii?Q?2zqEuo1srkt8uPv/oP1M5uymh9UKtu2tREbXQLAvUhcMirbPGIRO78MCWwG0?= =?us-ascii?Q?isL/BPdZ5z71SSjdd9bGIgBreFmb1Q469kbF1ZU35IzQdajeOSWlOofw5akJ?= =?us-ascii?Q?eCARSDomrFqvr49D1SIAucnMSR6WOuWW99JmEnwv6PI4Eby3XWn0PKOs/p9q?= =?us-ascii?Q?s3eMihObczllaPzCOP/jwCOlRemvhtNBlokkhQfoCZXgTToNnv4nGF+Pf9iP?= =?us-ascii?Q?H5Dy9qpl/YcE4TdX+JPH+VoOENPxmzXk2TjadwLhZZaGAmZCZre+iEbUlZ50?= =?us-ascii?Q?Yvrvx2cSZjjxbgWq/wFcKnpnmL69+cbqwAMKUhe7A5kbBEdLW9xT+k/A0GDO?= =?us-ascii?Q?eJ9rwK31KlWyWl5wOOfPDovKtkrPCNZafjqM6aUKmF+sLYiBP12ejzWN7uwE?= =?us-ascii?Q?WTEg8JqqG+esYGeDSK9cc/eu569N+2JjOgPG5QGluqrZZHv+R0267VfI/jyE?= =?us-ascii?Q?joRWGdotgJFHXlHg/7zMkbYX5t1qYRzeotEP5FQv57nnqI+dD68FXuBZMFlW?= =?us-ascii?Q?4bSWpFwNHuheV+oJ2yvHOD+XEMG0zgnSbVBGUq8UR66sn7u6ueuLUjX+ePWZ?= =?us-ascii?Q?Ru/lK4HrMqgiu2NL49ygU1NmgaQ2uFCHeqWTBRRNOKW09RXuZ94PHII0LLEf?= =?us-ascii?Q?qMnDvVijUzww5nW6roDRHMLt?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB808141E1A225DBB9E0BFFAAAC7F89BY3PR05MB8081namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ade4e1d-ec79-40da-abf2-08d95cdd50e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2021 15:33:06.3856 (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: zynNgf5zYHQHYVwGZiGXnntzSBTE7McDuevh6p4Oe4Z1HKdYLSNMX4lOCYtlgDMCaH77fa/XmkFf2Lte8NtMww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5798
X-Proofpoint-GUID: H5YN9B8D9Uc2ltIN1a6GoPiJZY32qnvg
X-Proofpoint-ORIG-GUID: H5YN9B8D9Uc2ltIN1a6GoPiJZY32qnvg
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-11_05:2021-08-11, 2021-08-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108110104
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8O66E5a9-jgJ2jZivdvR4iYI56Q>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
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, 11 Aug 2021 15:33:26 -0000

Hi,



comments inline.



Yours Irrespectively,



John



> -----Original Message-----

> From: Kiran Makhijani <kiran.ietf@gmail.com>

> Sent: Wednesday, August 11, 2021 11:00 AM

> To: John E Drake <jdrake@juniper.net>et>; Dongjie (Jimmy)

> <jie.dong@huawei.com>om>; Lizhenbin <lizhenbin@huawei.com>om>; teas@ietf.org

> Subject: Re[2]: [Teas] New term for the underlay construct used for slice

> realization

>

> [External Email. Be cautious of content]

>

>

> Hi John, (and all),

>

> Two very basic clarification questions:

> 1. How do we differentiate between  the slice-segments that are resource-

> aware vs those that are not? I had assumed that since a slice has an SLO, it will

> need network resource allocations in some form.



[JD]  If you are referring to an IETF Network Slice Service, by definition it has no underlay network resource awareness.



>

> 2. Is it ok to assume that the customer view of slice is an 'IETF network slice

> service' and the 'IETF slice realization' of that service in a provider network is

> raises the question of underlay and overlay constructs. Am I right?



[JD]  We provide overlay services, including but not limited to, IETF Network Slice Services over a common underlay network.



> (a) if so, then we are acknowledging  the presence of another layer of

> abstraction (for realization). It could be underlay/overlay or aggregate/??.



[JD]  This has been integral to the IETF network slice work from its inception.



> Then

> the term 'slice aggregate' is better and my preference, it is easier to see that

> different slice-services are aggregated into a single construct  in a provider

> network.


[JD]  There is a set of IETF Network Slice Services which are mapped to a set of partitioned underlay network topologies (or whatever term on which we decide), as are other overlay network services.



> Use of underlay/overlay are confusing.



[JD] I'm sorry.  This has been  IETF and industry standard terminology for years.



> (b) for a leaner provisioning, I would also prefer to see it documented that the

> aggregate is optional and it should be possible to directly map a slice-service to

> physical or real resources in the network.

> specifically useful when a single domain is carving out slices for different

> purposes.



[JD]  As I noted to Joel,  resource partitions are an optional tool that enables enhanced DiffServ support for a multiplicity of overlay services.  I.e., it is not IETF Network Slice Service-specific.



>

> Thanks

> Kiran

>

>

> ------ Original Message ------

> From: "John E Drake" <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>

> To: "Dongjie (Jimmy)" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; "Lizhenbin"

> <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>; "teas@ietf.org<mailto:teas@ietf.org>" <teas@ietf.org<mailto:teas@ietf.org>>

> Sent: 8/11/2021 5:38:05 AM

> Subject: Re: [Teas] New term for the underlay construct used for slice realization

>

> >Jimmy,

> >

> >Snipped, comments inline.

> >

> >Yours Irrespectively,

> >

> >John

> >

> >

> >Juniper Business Use Only

> >

> >>  -----Original Message-----

> >>  From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>

> >>  Sent: Tuesday, August 10, 2021 11:03 PM

> >>  To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; Lizhenbin

> >><lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>; teas@ietf.org<mailto:teas@ietf.org>

> >>  Subject: RE: New term for the underlay construct used for slice

> >>realization

> >>

> >>  [External Email. Be cautious of content]

> >>

> >underlay construct for network slice realization bound to

> >>  > > network slice services? That is, is the underlay construct only

> >> for  > > use in network slicing, or should it be generalized for more possible

> uses?

> >>  >

> >>  > [JD] Absolutely yes

> >>

> >>  [Jie] I guess you mean "Yes" to the latter case, which is "it should

> >> be generalized  for more possible uses", is my understanding correct?

> >

> >[JD]  Yes to the latter

> >

> >>

> >>  >

> >>  > >

> >>  > > 2.      If the answer to question 1 is YES, should it reflect the following

> >>  > > characteristics?

> >>  > >

> >>  > > a.      It is about the underlay

> >>  > > b.      It is about the partitioned resources used to deliver the network

> slice

> >>  > > services

> >>  > > c.      It allows the 1:1, N:1, and 1:N mapping models between the

> network

> >>  > slice

> >>  > > services and the underlay construct. The 1:1 and N:1 mapping may

> >> be  > > straightforward. Does it also make sense to divide the

> >> elements or  > > traffic flows in a single network slice service to

> >> carry them in  > > different  > underlay constructs?

> >>  >

> >>  > [JD]  Yes to all of the above.  Please see:

> >>  >

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-

> >>  gk!TCiJHCZCwFgwpuFoujxVlZ4r9

> >>  > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$

> >>  > >

> >>  > > Lastly, here are some candidates of the "new term":

> >>  > >

> >>  > > Option 1: The network slice service is called "overlay slice",

> >> then  > > the underlay construct is called "underlay slice".

> >>  > >

> >>  > > Option 2: The network slice service is called "service slice",

> >> then  > > the underlay construct is called "resource slice".

> >>  >

> >>  > [JD]  I don't think we need another term for what we are already

> >> > calling an 'IETF Network Slice Service'.  Adrian and I are

> >> considering  > the term 'resource partition' to describe the

> >> partitioning of underlay  > network resources in support of various

> >> overlay services such as IETF Network  Slice Services.

> >>  > This is congruent with the ideas expressed in:

> >>  >

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-

> >>  gk!TCiJHCZCwFgwpuFouj

> >>  > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$

> >>  > ts-03.  What this allows one to build is an 'partitioned underlay

> >> > network topology'.

> >>

> >>  [Jie] Agree that here we are talking about the term for the underlay

> construct.

> >>  "Resource partition" captures one of its key characteristics, while

> >> IMO another  thing the term needs to reflect is that the resource

> >> partition is needed on a  subset of the links and nodes (rather than

> >> on a single node or link) in the physical  network, which together builds a

> logical network topology.

> >

> >[JD]  In my initial email, above, I was proposing 'partitioned underlay network

> topology'

> >

> >>

> >>  Best regards,

> >>  Jie

> >>

> >>  >

> >>  > >

> >>  > > Your opinion about these candidates are much appreciated. You

> >> may  > > also propose other new term if it complies with the above two

> points.

> >>  >

> >>  > [JD]  I think you have exceeded your remit.

> >>  >

> >>  > >

> >>  > >

> >>  > >

> >>  > > Best Regards,

> >>  > > Robin

> >>  > >

> >>  > > _______________________________________________

> >>  > > Teas mailing list

> >>  > > Teas@ietf.org<mailto:Teas@ietf.org>

> >>  > >

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>

> >>  > > as

> >>  > > __;!!N

> >>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-

> >>  > > O08HqD31TGJciNjuxL2A$

> >>  >

> >>  > _______________________________________________

> >>  > Teas mailing list

> >>  > Teas@ietf.org<mailto:Teas@ietf.org>

> >>  >

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>

> >> s  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-

> >>  ROxL4C2

> >>  > _xNDCrPaNQ$

> >

> >_______________________________________________

> >Teas mailing list

> >Teas@ietf.org<mailto:Teas@ietf.org>

> >https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas_>

> >_;!!NEt6yMaO-

> gk!SCERgAZ566ZJbmstSAXS9FCSjdfU15Z795qJU4cO3Z4kXx8JLdcPEdSp4VsBkqM$




Juniper Business Use Only