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

John E Drake <jdrake@juniper.net> Tue, 10 August 2021 19:45 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 317DA3A1A03 for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 12:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=LpKeQWCK; dkim=pass (1024-bit key) header.d=juniper.net header.b=gAfUZVA6
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 h6u7Ihyzn723 for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 12:45:17 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1950C3A1A01 for <teas@ietf.org>; Tue, 10 Aug 2021 12:45:16 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17AJjAYG006474; Tue, 10 Aug 2021 12:45: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 : content-transfer-encoding : mime-version; s=PPS1017; bh=E/ucSB8lQ7QGsFLZ0+p0AUxTq/Z1UDNEpjkp2wVscck=; b=LpKeQWCKPPbXTEASK6oHrUvs7+/L8csv2CuD9Ak2oMw1NFYiiZ9trW+dtkoSkGYGSVw4 vOfn/sK4OT9uH0gy1DWREzGBg2ULR9DXl7UPac3OhCCa8WVCiz8E7DZDhD+RsqJ+NVpw /gLY6tj7B5LGkDddY7pjkSSV2U5unFmAglqLuD95sgMtgWHBAcNNEbLmT0a+TXbtkKjg IDDXh9nqseCoKFIJ570X9fmfp5OzTyuyO7qwgU4aOlD8YpYGRyXTQpoYvrHqzy6QPMjK DRlDLPS/cy9WmmOYU0foCT2uwtVFhXY/j4DgmlsPNpBTMzL7kQhbTwMAgHJSQkuZ6fa7 gg==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) by mx0a-00273201.pphosted.com with ESMTP id 3abvrhrba9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Aug 2021 12:45:10 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LZHmXOfjoAz/rZJH0uzKgY6QoZQ1pKPkxgO2DIBs/H+sE2k/rXMTYZfWSRkqx214YN1vWKbFKP6IWwlwx/w3AWAJLZL6vGo8Z4w8Qi+AqoZovyqQMA7xoOH6KfnwwVJ2IDlYEeIzlWshDI8qnl7G0PE14OctSaBsTgkAnHulBdXFKHS/fBxYJBizJG4vmZhtVxwdIyIVIlwzpttIuZLbM0MGsV0Gq+N5MdJO0VfQO5puNgViN8Fi0iwrMwt3RT2TwMG22gv8H6/Z67hdqZWFQ6qunxsuvaSCUGcnAgD+36FC6UIcKNMwSSKVwAQ+Wh+areHIiWQA/WaM4vuCGXjunA==
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=E/ucSB8lQ7QGsFLZ0+p0AUxTq/Z1UDNEpjkp2wVscck=; b=gBofu4YaH5fzoNozi2naMWvNEwwuHjb1q4akHAXM5O66uJhAv6QCF1tr7J9Cc7n+GVK1QJS9tsoMrae047d8DLT3DGjBqnGe6wEjfrbrXRSsr0aIFYz/ZndkZnoyAIHw5tVI4b25/DSELEiOD2KHReub4uTVIUulHqAVpQXKnTuAgeUTXLPrUFql5W+yeJwjanFgCGOGFox01KgdsQcSMrJ7PxdnPJFZBlbgFgHA2K4+r7x8dSqcHQvjyVO1t80E7KFHQ/pMThkO8gXE4DZi4iSH6AIcFGMab88WUfczQJDuUH/s2WByF7KpFmMxeL9nfIWB5y/y6vG0gbCJuxBipw==
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=E/ucSB8lQ7QGsFLZ0+p0AUxTq/Z1UDNEpjkp2wVscck=; b=gAfUZVA6w/7g/NVmwIvjfiOaMopWSGrGGaouXIjIhM5BJzeC8e7eIR05SMiWpnnhbd7x41v/C5NRIdB/atEQdCc891einqmts9T7Z0lhHEhHszYsPxQiGo9vlNNmCcQqliiGkD6hZaAXXi/ScsTGTyFN0ZvK5BkRR8WtkCuYq1k=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BY5PR05MB6881.namprd05.prod.outlook.com (2603:10b6:a03:1ba::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.10; Tue, 10 Aug 2021 19:45:01 +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.014; Tue, 10 Aug 2021 19:45:01 +0000
From: John E Drake <jdrake@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Lizhenbin <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] New term for the underlay construct used for slice realization
Thread-Index: AdeN+wpTY0PlvtVsQlC++M4sZJMfAAAHO8wwAAEu6AAAAGKHgA==
Date: Tue, 10 Aug 2021 19:45:00 +0000
Message-ID: <BY3PR05MB8081B96225EB127F0E74CAB7C7F79@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com> <ebfdd26c-8ee5-9820-7824-273ea86b135d@joelhalpern.com>
In-Reply-To: <ebfdd26c-8ee5-9820-7824-273ea86b135d@joelhalpern.com>
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-10T19:44:58Z; 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=5cc12433-2bc1-41b7-ae3f-1f0c7d127ed2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 495933a4-70c3-4875-d2ab-08d95c37578b
x-ms-traffictypediagnostic: BY5PR05MB6881:
x-microsoft-antispam-prvs: <BY5PR05MB6881723C4827E63F0E186962C7F79@BY5PR05MB6881.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tCGOTQqeO6XWNN/hcNCS7V4/32uOq4C/UvHXIhpMsk/2uNVRJyj/BWaH+I/3xbd8LWIV9yRVwYYmbQMBWbnavHj2Da3wTqxuDSXZlcubtM2uvhSsSDUROT8MK53egC4v6i2zMIuGi1ytfm0XChHYe3NBzAzrBaAe/ZboaXLgYXGTbQTD8sKFLmeJWchIyHNDzyQvsTKQaVHzGaIDGmAyNpEdyq2p7GFMO140U8EIW5tcRGpHM/rKEp/B6pcau2jBIU1P75RkQ5dAWDK/Dcja3dkLhEtsQr7G0pRXOhamYbXS0XNSQBzp0A3I32tnwi1gyAv28xEmik36yhr2Ny0Xmz3i/5iM28T+Y+bHa9L7VYH4Df7zfd/yp32A+mz9UC4sAEY6LVXKDkezaTi3etnjQ/BD/UTsGgGvDH7yE/Z35D7sF7zY7fECQw/rM+nqFJNC6zDTebtseZFScfP3HNIt4yJOii7KEBRua01iK/KjxuWXRgiv89c45B7CpCFxmuZJfos4n69ipzVUWNd9nzSjXBrB9MSrSCjYsLuJTJQh8k+pKuVSpkhEbLixzzMSAWPGqroOeX7huB794+G2K7ta+ri5ANiGq6S618ergSWI0gBNFOvrp3eczl/oipGq+XZeH/7jfqxaRqINnNwx3Z6cM+We9LheDMu4VICvNhNHTFJF3p+bbIU5G72oca0MLCHGBhJJbsGeyfeY+7uPdnRpq7jcQCKryA6arsfX/kB5lQG3kwUhKhqpP+vPnyGsSNvXCgSL3pMg94hZbYazyvZoIW6eNuj5pd//WoPUWjQZJIiZmPVHCxmoqH84uHdYN9Y6wfv0uQBa7yC7Z1a1Q7C6BA==
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)(346002)(376002)(39860400002)(136003)(396003)(366004)(38100700002)(186003)(26005)(478600001)(7696005)(2906002)(86362001)(53546011)(122000001)(6506007)(8676002)(966005)(66446008)(66556008)(66946007)(55016002)(38070700005)(71200400001)(9686003)(8936002)(33656002)(76116006)(64756008)(66476007)(316002)(110136005)(5660300002)(83380400001)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cjRiUkZ5ZktLa3VLMHRISGF4a0dtdmN0OWVEbDduSmo1SU5LRFR2MWRlZ2hv?= =?utf-8?B?TlR4MGNIcjRYMjBpOHI5anhuY2lQRnpSUk5ES1ZrL09UMC91VlN3eEFpcndi?= =?utf-8?B?bndZeHF4NDdPNm02c2pSYnlRdUpmL3V0Tnh6TnhyaGk5TWpTVHJXT1orY3Va?= =?utf-8?B?Zi9aZTFaa0U5eDVaZVg5b1lkVkRHWkxoNVdlMGVOVGNhNjFYdkZYMlhEOUdF?= =?utf-8?B?cVUweGRKMnY3bDdwY1V4akh5L1lseGJyTUtzNjE2MHM5QWE4bHZ4d3hUWnNa?= =?utf-8?B?WEtoK2UyOWNUeExMb3FZODA3a2hyZHlQa2l5QWVKYy9IRHlJZEZ6MW5yYmpi?= =?utf-8?B?SXYxNkRRS2VqRkxINEdaOWQ4SHNlcHZZcnVGUEtSTVpBRG9DWXFSbHpwcWtm?= =?utf-8?B?d1lFRm12ZFFLenhnNVA4QnZGWUh4SCtIS3FsRkxVM3UvR3UrcUtidzFkTy9T?= =?utf-8?B?NzVxTG5NRzMyb0J1Q3UxaFhEVzZHNmFwR0ljckdNUUVBRThRWnhWbjVQMVN1?= =?utf-8?B?bDMzU2NWbGlzb1lvMGViTUJVNzJiK0pETndLMFA2QVVYeDg2UnVQUEIxRGxM?= =?utf-8?B?aTd1YWoxMVpSN29EbXRna1NrWWR2Mk93SmNNYUszUisvbzJXYVpHQjdvWjJs?= =?utf-8?B?dXE1Z24wanQ3akhGMTN0ZUQrR2dLb045WEVtWm9naThmSEIxNTF2VG1tVHFV?= =?utf-8?B?NzlDY1FDR0NzVWZFeC9CSzZGelVkclVSbnBWSnBXM1R6Ymg1Qk9ncVF6NjA0?= =?utf-8?B?SUFsc045Rkg3eE5mVk1Td2tCRjFTK09Fajl5OGh4SG9ZTzNDN1VROGcrOEhB?= =?utf-8?B?aklzMmdBcVJHUjNaRThJeVdzbkg3dUNQbHJmMEtoaUxaU1dBQU1DdzR2MGlC?= =?utf-8?B?S3o0cG9WMjBWUmpKb1dlTmNwdVJJWjJVQkZHWks2NnZTczVKcWFRZjZEdTdK?= =?utf-8?B?SXI4SktxbUdWR1lZcE5SSm91VzFiQVdwdWdtL1VlazgraDg1SThtbm5lRGhH?= =?utf-8?B?cVA4UjF1d2dKMStTZGU3a0FHcWZjZXJDazV1c0xybFdzaE1DRjUwa05BQTEw?= =?utf-8?B?L0p3VEdmSUFZTlFHYWszN3JESVlONlIyVGd6QXlmelRkSlEwbGNSNS9YdG4x?= =?utf-8?B?bm9sNndtYVpWd2xtdWhFM1hIbkVUSVZNZFFWRlBuZlBSL05BSzRtMDgxUkhZ?= =?utf-8?B?ckxwazNiY2JiWURJaW1PMXM0bDRVVXpQbUJTVkx4VG1NUEFxeHRjbW5vZlkz?= =?utf-8?B?ekhuMmd0K3NKQXpMRzlLYjh3N2ZkNUt1KzFOOEtnbnZHSDZtZ0pzb01ocXdp?= =?utf-8?B?djlmclBGNHF6ZzNLem1IVFBDaENJWXgva0lTTFpWbHBtUzRMVTQzZFN5K3Nl?= =?utf-8?B?RXhjQWduLzI3WGszMGFPYVNyc3FodlRldFh2dllaL0tCUXZoeXBicERZR3ZO?= =?utf-8?B?c0d6T0VjcE8vUloxNzNqam1QSFNQZmxNZmsxckc4RGdYTU9MN1RlaGlHeW1Q?= =?utf-8?B?bU5vMXE4S0JPNUl6Vmw1TEo1K2dEY2JGMEFYQlFtUkY2d3Z6RGJubjV2Y2lW?= =?utf-8?B?OFBCazFqSy9GSkxIaUMvcmRjNlJscS8rQVB2YXpDTXJDMmxiOWJ6MlduSGhy?= =?utf-8?B?VXZSOGMzRFRFbWxLQ1ExUmt3NUYzUlZGTVNOZGFnaFgvSW5ISXo0Z1p5Wm9h?= =?utf-8?B?ckxlVndsbzJoWkZNR1ZkTnJGWGtzZjF3ZWFydnRmbjVNcjlHRytoQ0NnYjEy?= =?utf-8?Q?R7+FsEBk5TqpsBVUwEb0beKsu2m651gWWA44PN3?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 495933a4-70c3-4875-d2ab-08d95c37578b
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 19:45:00.9541 (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: pbcwlq9u1RxFH5t0SujlZVkRjBMR4daE9wAJypMPupjNe9PZztzfRFM/3FTeQ8P3jPDrqGAk8dcdrPW5hpLzDA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR05MB6881
X-Proofpoint-ORIG-GUID: NKLeDaii1223pKTwKjb6WJQsqsk2VcNI
X-Proofpoint-GUID: NKLeDaii1223pKTwKjb6WJQsqsk2VcNI
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-10_08:2021-08-10, 2021-08-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 bulkscore=0 adultscore=0 suspectscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108100130
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/E6jo2yOvm4Fw0byLAXAULWdCRDQ>
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: Tue, 10 Aug 2021 19:45:23 -0000

Joel,

I had envisioned that a node would be configured to create a *small* number of partitions, i.e.,  a subset of buffer/queuing/scheduling resources, either for each of its links or for specific subsets of its links.  The former would be for adjacency SIDs and the latter would be for loopback SIDs, and it is done in support of enhanced DiffServ support for a multiplicity of overlay services.

I had researched terms and 'partition' is used in the sense of "divide into parts", but I would amenable another term.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Joel M. Halpern <jmh@joelhalpern.com>
> Sent: Tuesday, August 10, 2021 3:20 PM
> To: John E Drake <jdrake@juniper.net>et>; Lizhenbin <lizhenbin@huawei.com>om>;
> teas@ietf.org
> Subject: Re: [Teas] New term for the underlay construct used for slice realization
> 
> [External Email. Be cautious of content]
> 
> 
> While I mostly agree with John's descriptions below, I am a bit concerned by the
> suggestion of "partition".  While some of the use cases seem to be describable
> as partitions, not all of them are.  In general, what I have observed when
> combining statistical multiplexing with traffic engineering we rarely want true
> partitioning.
> 
> Yours,
> Joel
> 
> On 8/10/2021 3:11 PM, John E Drake wrote:
> > Hi,
> >
> > Comments inline.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -----Original Message-----
> >> From: Teas <teas-bounces@ietf.org> On Behalf Of Lizhenbin
> >> Sent: Tuesday, August 10, 2021 11:21 AM
> >> To: teas@ietf.org
> >> Subject: [Teas] New term for the underlay construct used for slice
> >> realization
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Hi Folks,
> >>
> >> On the TEAS meeting in IETF 111, it was discussed that a common "new term"
> >> will need to be proposed for the underlay construct used for slice realization.
> >>
> >> There have been several related terminologies:
> >>
> >> 1.      VTN (Virtual Transport Network)
> >>
> >> In the early days of network slicing discussion in IETF, it was
> >> suggested that the technology in IETF should be neutral and not bound to
> network slicing only.
> >> Following this approach, the term VTN is defined in the enhanced VPN
> >> draft already adopted and progressing in TEAS. It is expected that
> >> the VTNs with guaranteed resources can also be applicable to services
> >> other than network slices. The VPN+ architecture allows flexible
> >> mapping (including 1:1, N:1 and 1:N
> >> mapping) between the overlay VPN services and the underlay VTNs.
> >> Since VTN is a generic term, in the context of network slicing we may
> >> still need a specialized term.
> >
> > [JD]  I never liked this term because what it is describing is real not virtual and
> because the IETF does not build transport networks.  I.e., what it is describing is
> a subset of the underlay network topology with partitioned resources.
> >
> >>
> >> 2.      Slice Aggregate
> >>
> >> It is claimed that the scope of Slice Aggregate is tied to the scope
> >> of IETF network slices. This term implies an aggregation of one or
> >> more IETF network slices into an aggregate construct, so that only a
> >> 1:1 and N:1 mapping of network slice service to underlay construct
> >> can be achieved. However, if this is a mapping of network slice
> >> traffic streams to underlay constructs, then it may be possible to
> >> map network slice services to the underlay construct as 1:1, N:1 and
> >> 1:N, but the name may be confusing because it is not the slices that are
> aggregated.
> >
> > [JD]  This term never resonated with me because it is slice specific and
> because, as Adrian pointed out, it's actually used to describe multiple,
> incompatible ideas.
> >
> >>
> >> With this background in mind, now we can discuss how to define the new
> term.
> >> Here are some points for the WG to consider:
> >>
> >> 1.      Should the 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
> >
> >>
> >> 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/draft-
> drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNRec87D8y
> M$
> >>
> >> 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/draft-ietf-
> spring-resource-aware-segments-03__;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNReINcGLl
> Q$ .  What this allows one to build is an 'partitioned underlay network topology'.
> >
> >>
> >> 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
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
> >> s__;!!N
> >> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> >> O08HqD31TGJciNjuxL2A$
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNReQwgX
> MbU$
> >