Re: [Teas] New term for the underlay construct used for slice realization
John E Drake <jdrake@juniper.net> Mon, 16 August 2021 16:41 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 21DCB3A1014 for <teas@ietfa.amsl.com>; Mon, 16 Aug 2021 09:41:51 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=OYm/6uSN; dkim=pass (1024-bit key) header.d=juniper.net header.b=k5f3uEds
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 c9Z5xJMeMcCj for <teas@ietfa.amsl.com>; Mon, 16 Aug 2021 09:41:44 -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 6A3763A1016 for <teas@ietf.org>; Mon, 16 Aug 2021 09:41:44 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17GGfZSP023161; Mon, 16 Aug 2021 09:41:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=p6DKEFLB44k0pQoixBpVY+xd06qVv5SZO2ej+vtZpqo=; b=OYm/6uSNn4hHw9cjoA2goKfyCW/U+/lmdOCYQ6lNCOXyljs24KIjJ/P8CclWbiCw7Al4 L7t/kEkBh1EiraHcd9lFXpnYZuV/7mIpaCR6KhxVatGBKz0OY0yr3Nq2KevIu/bdjuae 6Qi3rjBN7qWQ2ygx0dNa0OrCbpq8ngzy3aJyelQizR6ZqlCSLoCvqQNzFr+OUcopJM3b 19b/tEmghx5aMwvYOn/l6IvO3g82Atifk/rugWgM5ksouNRMgC9ZfYjAaBYeLOnWXDOu IW2+paenQq9JkmS4Lco1AaPO9g6jsjyqqJxx3KPm1udLptNd3IwEqfVTPC8tPu+tesmt 7Q==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by mx0b-00273201.pphosted.com with ESMTP id 3aftq884pt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Aug 2021 09:41:34 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e+MT5VPoaUOKEQMIKZn283mdOsqyxqSam5AeB9EAAngudqJ5R55eF4+J6WUQxyIxptHX6ESeEBQh5FYJGy3EFAywY6iIA0R/UVO+MAI0kHFMNzbugDMDczew9FmrGiUpg0VFonw7KFF9rHt1z8p1G1TZcSIsYroErCOSLJiQV0sXNtqE+mYRdMREis3hl41VHne86SgBSgIFINRQAfgkCCVxgkC0y7K7d2GHKlUjvn6WwvorOrtpXTuWDin7W4wxHhKhWBVwlfUfe15RA1VTf2c9ty1Bt8dIHjaKuJGx5z/8HaBwsb/pJthEaanQraiSy1mhn9iaolTJP6KZSvJA3g==
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=p6DKEFLB44k0pQoixBpVY+xd06qVv5SZO2ej+vtZpqo=; b=gLvK8bCandly8RhGLy6Gz2pBhKaInXU7JRb5vUY1/ySDoKwWusz9o1GexaUgd08gW8j+oTP81xpJggEO+pfrf+gcio6BXSUMktGCsgjYQGt2aHbCrDddDQFp8k4cXxJSLJXmIs++syi6I14nsaGTDJVH+ZWJbcK5LFIbHqKnmcAlIEUVpwwFGOSpyhxgywEfKC8VZT4rAdDGn3ak7nJVVDfymX+Ska0zBSNNqyMHmcJnB6KVU8NQLdXfLflWwO0hAnIgyh5dazzz+QHp8fgY75WzMdkOHMzfwzb0ESQxaJsa+3XH7r0Xg0CrySaQnAwfFKdjpNgH+Xe2vVWzTpGAxQ==
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=p6DKEFLB44k0pQoixBpVY+xd06qVv5SZO2ej+vtZpqo=; b=k5f3uEds0V13VZUAZ6nn4ovLm/HniRmxW2zddjOAKMCVzdLo00RHOlN8zjxjYK9hodr9MI3eKSJTSGGaSIYO+cK8puuo2qupWfB+sSi5lyEDSdudbHsNUyNn0u4JXKssHh41I2EUWqLUkER9pa3wWLKozNedj2beTP6tBpmp6rc=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BY3PR05MB7891.namprd05.prod.outlook.com (2603:10b6:a03:36d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.12; Mon, 16 Aug 2021 16:41:32 +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.4436.018; Mon, 16 Aug 2021 16:41:32 +0000
From: John E Drake <jdrake@juniper.net>
To: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
CC: "kiran.ietf@gmail.com" <kiran.ietf@gmail.com>, "jie.dong@huawei.com" <jie.dong@huawei.com>, "lizhenbin@huawei.com" <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Re:[Teas] New term for the underlay construct used for slice realization
Thread-Index: AQHXjuhoX+ern3a3JkanLeEeaUvsAKtu1lOAgAeGPdA=
Date: Mon, 16 Aug 2021 16:41:32 +0000
Message-ID: <BY3PR05MB8081C89E3FF0154E624EC654C7FD9@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, 00e401d78ee8$5ea55790$1bf006b0$@olddog.co.uk <202108120544338838854@zte.com.cn>
In-Reply-To: <202108120544338838854@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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-16T16:41:31Z; 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=3a9a5016-47ee-4527-b305-9d43acf81593; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: ztetx.com; dkim=none (message not signed) header.d=none;ztetx.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f038bd0c-01d0-49fe-e7f8-08d960d4b43c
x-ms-traffictypediagnostic: BY3PR05MB7891:
x-microsoft-antispam-prvs: <BY3PR05MB7891054A5858E7F6A5612459C7FD9@BY3PR05MB7891.namprd05.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: mZBfZp5tYVFhxBKMfFPpsdECqztyvCCU0vn5lsyB+Kz6drWfKJ83B68h9d398m2o1q4BFgFTlc+wOptNNeaXrcCj9QCmuQFyLhFI9wSMpjHkT6bhQ960TX8z/mhavcNVqV3FCA/oMHdyO9m9Fwy+3ArlTNTiRHlKfmsh6ekGh8elBEiYC4Pxlo0lk3WbfsaAMjaDbtg/yrCn4EkhiS/hIJnZsXc4o8FWxmy1Hm6OtXNOthEPvCAWWO9l0tdsGykxsIvjFWWr6Xp5f6ZmFnKV3tzHf3Za7x2CvfpxEKOM1uDRe9XqGH+9m3zZ3wss2gPxM10TxBGZaJRxIjbeCKkor19Pxq12tjamO8GtlkLL8EwOBZOwGddFIoepY2bhm0hVce5jS4T9JFSmVN98Em98fZGaij2GCCHcsWc2m05ZviWGpfx+i+XmPeqPkQiDdvksjj4i5/Uw0Q4xfusQB5RlLdRlJfAehlaf6Uo8EV1xT3OlhabNibVFOLe92nE+nHj8sZ8ydsllMIJDFxLFwvAKJHsG0jUt5qzfXHOrhpoRGEAXSLFymXnaqrKSw8N8BQytha1P5OrDlD0CNIvMn6iMM0lSlHPU7J+wpemmHQD53cctLU+fujc+OLBIjfOC2vor1itXZrPD2HDpk/beAYpiqjCazCxcx/HW9j2fDqLH2o+vNjtvf61GyPuH7fE4GY/kx2V89MzcPJpeaBZfdW9UAjpeZYeQj6whAlFKs3DzEXfn3YpSekU6Vf+J+hI4n/gcYwi7BF8POTtNSILY5k+CUIo6Fp/g2laXwY6JgFFYHoIgnWVnN1Zv5Te6aNoRFs5ero1skOZVRlfvoQI3P9lg1g==
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)(396003)(39860400002)(136003)(346002)(366004)(376002)(2906002)(86362001)(8936002)(8676002)(966005)(478600001)(316002)(5660300002)(186003)(55016002)(9686003)(52536014)(7696005)(4326008)(6506007)(66446008)(66556008)(66476007)(54906003)(66946007)(64756008)(122000001)(30864003)(53546011)(76116006)(166002)(38070700005)(83380400001)(99936003)(66576008)(110136005)(71200400001)(38100700002)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Ffmm/L77vbk+f3SReCWX4eOXNymrPZicKc4tvViM74BkIiocqkwvu8YxV1LdX4IH5bXZZF5JKScTxvsmNcZPBYAle/btTpfJrOP+6Q0pUk/nlujs4EvzFCk0fVuEedbWSNp6hpVFklZv254weR9Lq992v8Ot5cbzH8lSDuSg7d85dIIRmgeg7q7wvW7ALbOWt4Jei3NxLgAga99hIBJRjtGo2kINNfUa0SZCxuLqQ4xi4Z9chfJyxFhWDZeHB4+LHA5sH4edaHYQCcwZotkvEkGJ/fjpvd97Pyra1YPZnpWZQVQrp/O1bNI4gh9MD71pHsU6jmu0eR21mOaNvZlouA1VbM3YVFOeLxb4GXIGrkk3dbzFQbmDCdDm9I9pJfe61TgTxhtCjXaBWJooriaAiC4uyIMpaOPCuB8UyzOXW5uDQrg6+h/6tP25T4U5xFx3mN5SzxnpPL+o6Tk4/WC19r8eqxbNhg98S4L965aR1P4JwLtVZ/UUGyNKq7sdWBBMfQ+gSG06luTevWyvwmSq+Kq1HTPRHCaXk99+fsaCUGedLwRcPSwcMD+A0UZRmFEFbNpSEVGWhdpvGEuDhFecz97ysvsTJE/f15j5dvFYrt7kejg9GGbLe+cFxPLce5GLYQ+8jVifJj3TPLjUT5tL1foKemwFTdDDaugPQwmSLJ7t2duxzyTpFVw2d0Z9NUBtBNquyu9QRINhk6OHm6UEXU6KDIKhlGuYLF953SNxacKi7uykEZaTEnP1HLyOT9akJLQi1uZPURYPiUgMYarmM39QbPFAjwvspFhJUZUul185w4wec7esg+gDF6PC/AAizlTd12ypUKFJZ/fpnYX+Ufn69/Dhr5IVIMoDJKbP79EcwV7f79rxorOtLbV71UWaWgzE1jogkhwSdw0z173DmnR1Z+TbO5bzorR1dFp+Jsna/y8byHKTG55EWN7tZqqTDlgNE8+ZO3GOMkMldH1xeqkWnv72yic2dQt5yM7BYBGGql/VowwyCDLnASIHjxrE/KpvKpb4a6hruH+aj6aN9lHYsHdMrODEDmRbMwdqbNxUEqkI2NO6XQwpS11efvxM2h2rwdmIN7wWTQ/Odlf+tSTq8OqcImOHnUmyISeqnALXS+cZq+FvK198XZY7UJxR7VMahLtiEKLyoNngmDlhDeHo0I4paJ+9Z6ltkMixFMrgSc1tkKjjne58R5zYnqtiAiyuL981fXxZkGbs5PWHZBOQ8w8WlpZTn8n4o/WWrxjg5QjwqV7fgXYjgrWjAca+5osUeBaBTaKjrZf9Qofe7sShn3oRGa4YmZ6R18DJi9Ep5Z1Dq1Xo7E3tGzZWwRbctc8uhMnhifP+dJY8nWlBmDr0NmMmlTX7RXccdfZSdFX7K2Xf2A2Ce0LNslQn6hPe
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_BY3PR05MB8081C89E3FF0154E624EC654C7FD9BY3PR05MB8081namp_"; type="multipart/alternative"
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: f038bd0c-01d0-49fe-e7f8-08d960d4b43c
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2021 16:41:32.1047 (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: E7oyBuM+3Q3C+YnZt33qW3jWE4OsFLLJxNnKNcKfe+RdCSO5avemn2cFiXb7OeeSW1OppZfKS5BlsWqmIfKX/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR05MB7891
X-Proofpoint-GUID: Cp-VYEdXfgS6bbkR1DkVzEQ9zS7rl9xf
X-Proofpoint-ORIG-GUID: Cp-VYEdXfgS6bbkR1DkVzEQ9zS7rl9xf
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-16_06:2021-08-16, 2021-08-16 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 clxscore=1011 malwarescore=0 priorityscore=1501 impostorscore=0 spamscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108160105
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ReGQKzMy9oDvbdgt-xRnBfv1Yi0>
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: Mon, 16 Aug 2021 16:41:51 -0000
Greg, In our definition of resource partition we were planning to stipulate that resource partitions are work conserving (https://en.wikipedia.org/wiki/Work-conserving_scheduler). Yours Irrespectively, John Juniper Business Use Only From: gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com> Sent: Wednesday, August 11, 2021 5:45 PM To: adrian@olddog.co.uk Cc: kiran.ietf@gmail.com; John E Drake <jdrake@juniper.net>; jie.dong@huawei.com; lizhenbin@huawei.com; teas@ietf.org Subject: Re:[Teas] New term for the underlay construct used for slice realization [External Email. Be cautious of content] Hi Adrian, I think you've done a brilliant analysis making it all so clear. I fully agree with it and also had a minor discomfort with "partition". I like "group" or "grouping", but will be merry with any other. Regards, Greg Mirsky Sr. Standardization Expert 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division [cid:image001.gif@01D7929C.09011BA0] [cid:image002.gif@01D7929C.09011BA0] E: gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com> www.zte.com.cn<https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!NEt6yMaO-gk!T3onPdUlXAGP4OCEvOR2Tpm_062N_bbqWOGGQCmyaZ4nbi7snLs1KESA1sA4He4$> Original Mail Sender: AdrianFarrel To: 'Kiran Makhijani';'John E Drake';'Dongjie (Jimmy)';'Lizhenbin';teas@ietf.org; Date: 2021/08/11 12:38 Subject: Re: [Teas] New term for the underlay construct used for slice realization I wonder whether we can pick this apart and put it back together in a way that makes sense. The customer's view of all this is an "IETF network slice service". I think (hope) we are all agreed on this. The customer may ask (in shorthand) for a "network slice", but: - they are talking about IETF technology, so they asking for an "IETF network slice" - they actually want behavioural characteristics and have no right to tell the operator how to manage the network, so they are asking for an "IETF network slice service." The operator has a bigger set of things to worry about. 1. At the top of the operator's view is the "IETF network slice service" as requested by the customer. We have this defined already, so nothing more to say. 2. The operator maps the request for a slice service into the "IETF network slice" which is the expression of the service in terms of network connectivity in the context of the operator's network. The relationship here is like the relationship between the L3SM and L3NM. 3. At the bottom of their view is an underlying network. The technology of this network depends, of course, on the operator's offering, but this is the network technology being sliced. It may be an IP network, and MPLS network, an OTN, or whatever. I would call this the "Underlay Network." This network may, in turn, be built upon an underlay network of the same or a different technology, and it may be facilitated through network slicing - but this need not concern us here. 4. That leaves the glue in the middle: the bit that enables the scaling and maps the network slice to the network. And I think it is this bit that is causing the most debate about terminology. There are some points to consider: a. The term "network resources" applies to the bandwidth, queues, buffers, etc. available on the links and nodes in the network. That may be extended to refer to whole links and nodes. b. The number of IETF network slice services is potentially large and the operator needs a mechanism to scale the mapping of services to network resources. c. The IETF network slices may be grouped for identical treatment to achieve scaling, where the grouping collects IETF network slices with similar SLAs. d. It may be that different traffic flows within a single IETF network slice have different characteristics. In this case, it may be beneficial to group together some of the traffic flows from different slices. e. The grouped slices/flows are enabled in the network using network resources assigned for that purpose. The assignment may be anything from a fully-fledged virtual network (such as in ACTN or VPN+), through network reserved resources (such as in MPLS-TE), and centrally accounted resources (such as SDN or possible SR), to statistically shared resources. There seems to be various points for and against 4d. But, it would appear that this is an implementation or deployment issue that doesn't change what the protocols need to do. So we should probably allow it architecturally, or at least, not disallow it. Of course, as Kiran points out, 4c/d/e may be a pass-through. That is, it is not necessary to implement such groupings either because there are only a few slices (which has been the view of some operators) or because the network systems can handle the number of slices. And it is in the nature of architectures of this sort that all functions can be nulled out without loss of generality, and we have to recall that the internals of provisioning systems may appear as functional blocks in our architectures, but we don't compel implementations to adhere to that type of architecture. So I don't think we have to worry on that account. And that brings the question of how we name the resources that are gathered in 4e. I can't decide whether it is helpful to spend time saying why I don't like each of the proposed terms. I certainly have things I don't like about (for example) "slice aggregate" (because of 4d, which means it is really a "slice sub-flow aggregate"), and I am not a fan of "VTN" (because of "transport" and maybe it is not really a network). But maybe it is better for me to say what I think we should call things? I think we have... - IETF network slice service (customer view) - IETF network slice (operator view) - Resource partition (delivery mechanism) - Underlay network (network used to support the slice) Why "resource partition"? Well it is a collection of "nodes, links, and network resources that are marked within the network for use by a set of network slice traffic flows". It is possible that the word "partition" is too strong because it may imply to some people that resources in a partition cannot be shared, but I don't feel that. Softer words than "partition" would be "group", "bundle", "pool", and I could live with any of them. Best, Adrian -----Original Message----- From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Kiran Makhijani Sent: 11 August 2021 16:00 To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>; 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> Subject: Re: [Teas] New term for the underlay construct used for slice realization 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. 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? (a) if so, then we are acknowledging the presence of another layer of abstraction (for realization). It could be underlay/overlay or aggregate/??. 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. Use of underlay/overlay are confusing. (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. 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/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> >> > 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/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> >> > 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/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas> >> > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls- >> ROxL4C2 >> > _xNDCrPaNQ$ > >_______________________________________________ >Teas mailing list >Teas@ietf.org<mailto:Teas@ietf.org> >https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas
- [Teas] New term for the underlay construct used f… Lizhenbin
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… gregory.mirsky
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Kiran Makhijani
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… gregory.mirsky
- Re: [Teas] New term for the underlay construct us… Gyan Mishra
- Re: [Teas] New term for the underlay construct us… Kiran M
- Re: [Teas] New term for the underlay construct us… Gyan Mishra
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Luis M. Contreras
- Re: [Teas] New term for the underlay construct us… Tarek Saad
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Kiran M
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… Igor Bryskin
- Re: [Teas] New term for the underlay construct us… peng.shaofu
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Lizhenbin
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… 龚立艳
- Re: [Teas] New term for the underlay construct us… Lizhenbin
- Re: [Teas] New term for the underlay construct us… Tarek Saad
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram