Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
John E Drake <jdrake@juniper.net> Thu, 14 April 2022 13:12 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 C7D163A193E for <teas@ietfa.amsl.com>; Thu, 14 Apr 2022 06:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=F6LOnF8r; dkim=pass (1024-bit key) header.d=juniper.net header.b=ZCUi3i4O
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 aI9eVfUaiPRb for <teas@ietfa.amsl.com>; Thu, 14 Apr 2022 06:12:01 -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 418823A1936 for <teas@ietf.org>; Thu, 14 Apr 2022 06:12:01 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 23DMD1ll013127; Thu, 14 Apr 2022 06:11:52 -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=CG+d6K2Ot++ppqP+ZBo/VrWkrHjOa4MuX00jI/kiRLo=; b=F6LOnF8rD87Cw/pkJ+07Z/H1nGoyHz0AkHCO7pwgGmb2JBaRzEk74XInWSryMGyzuP1x b5K6qllKJV11sKaLfqUVoJZJ+48bDu8TB+btBKTI2r05lAPVbGXgygNUwS/59UbcQ9/V ZO/x4wLVl6cUAFd+HQubEqO8RRP0FOiWgeaczIyZBJBJSCChwYLRQGN6oKlqBodXcbCn ZhT0KMDYOSwm/UNU8zWkvmqBL8dPuKojIqhtVlKbC2ymtUaKL+AqNzZhwauLm7hvy6nD S9p3ZnackE8vIGUqzeDx5Hy7zqKo5eLROAlSzY3AayObyfiB45d9rB1RP5Op89pSnz97 ag==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2045.outbound.protection.outlook.com [104.47.66.45]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3fe1pmabx2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Apr 2022 06:11:51 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+3E3NaUoJtkz9d8R5RLk/PaoLYNd/T/taTDogEuT70+XsqXiI9FwMYOwuWQgtcZV8kDHVNaHYNHx44MOkJyWsTIwipRJeDaAvA94u3AcAMflZaGgHgMRuuiQN0RXlfgozRpApMPQU5KADz2fOROPZJY3uwyVzqjxjG0NebkO8xigOBX4SR6SnJphLpN8RrDKfhDy92/77+sYmHTmwlPazWPv0OmBYFiE83fDqBjtSdGT7n7LidjJJoAYzZq3US1/+L59dGsYocFnceiWmtXO5wvLOup/gLuCWNPponxla4Hg8mM8yiIfqThC3bCaR0paRGAL1/qy64ZAX6Kx8IDsw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CG+d6K2Ot++ppqP+ZBo/VrWkrHjOa4MuX00jI/kiRLo=; b=IKRcnXYsB1p4TGyzCjvmxuxb5XxAOcsxHy+l3VCAzSWBMZVHPlvLO2EP01RXz7P/LTz2wQ3ERDCqFlrKEnrfp4FicT86kLnpP7iEJFBDXBTyNd9dE2dTuPVqIYJ8VKKUZzEy5su14ZyMVGN6NmVpdsbzKRCTa5wTBUc4Rm2mPiVq53vRUkNiVFI6DrZawZwwkyDl9UUZsq7OBNJIJrig8XA8r+NuUQ7D+W0/5l3qEnxuXBD5ylgbuuHIhA6BUJq2zV/PrR7C+ga7mfjCPCdNz8cGxy+nIxnknAHKpoIkArGwoPrRQLzlN+yHVWBFEWAjBbb+JNUI0V1Mgoq0uSamsw==
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=CG+d6K2Ot++ppqP+ZBo/VrWkrHjOa4MuX00jI/kiRLo=; b=ZCUi3i4Oi55CGez2vuVs5p++vXs29kh/BjniInLwLHZMybfYn62aaw+wEpTKtoIjsojBa/lTjXWmDrQsUmWDh0zgWP7qY1Xg3dEvpv5hUekaFG6zbqAKGbFGQjYG3m/SAyBBsC2cdMidUKtVWD5HenQhlDsgXEMrQkw4tnmlo4A=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BL0PR05MB5539.namprd05.prod.outlook.com (2603:10b6:208:6b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Thu, 14 Apr 2022 13:11:46 +0000
Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657%9]) with mapi id 15.20.5186.006; Thu, 14 Apr 2022 13:11:46 +0000
From: John E Drake <jdrake@juniper.net>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Krzysztof Szarkowicz <kszarkowicz@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
Thread-Index: AQHYQD5mziQ3b5ngCUWZlORwxzPXJKzQYtoAgAA5TICAA7s7gIAANVaAgAABd4CAAA3wAIAGKMYAgABROwCAAAFXAIAABTSAgBFQPACAARjAgIAAcBmAgAEls4CAAGWn0A==
Date: Thu, 14 Apr 2022 13:11:46 +0000
Message-ID: <BY3PR05MB8081530D8D3FFAD7EFE1E4A1C7EF9@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <042601d84029$1de567c0$59b03740$@olddog.co.uk> <c4e7e5c0-81a2-7f62-c81a-8f672eccd6db@joelhalpern.com> <DB9PR06MB7915CE12BC9DE1E9F62309E29E1A9@DB9PR06MB7915.eurprd06.prod.outlook.com> <CAO8-O7pm7aznKmt--2Dfgtf=ZZ=o2xtjjRoLLOVMLpG6KP8_pw@mail.gmail.com> <9191AF9E-6FA7-43AF-B4DC-55F0B046BDAB@gmail.com> <04e801d8408e$52fa51e0$f8eef5a0$@olddog.co.uk> <1532_1648448435_624153B3_1532_474_1_e88aa4968220476d85dfe52430086664@orange.com> <905EF0B2-A4A3-428F-B9D9-00408A769C80@gmail.com> <28412_1648460203_624181AB_28412_34_1_7ae1d32feccf4cea877711712dbe5c83@orange.com> <871C707C-F12A-4BC2-A936-E756358A0393@gmail.com> <EDE8C8E5-2F47-4D49-B963-3ABC5E86CEED@gmail.com> <9477_1648819251_6246FC33_9477_178_1_b482d38132d04f3498c62319af4fef11@orange.com> <49E7628B-9D75-4C78-A7DB-31333F75AD49@gmail.com> <22268_1648820656_624701B0_22268_233_7_b0097a6d1ac24255b822db335ab5bcd4@orange.com> <D398F2B8-DF48-4742-9CCC-3739F8CCA19E@gmail.com> <d31bd44a00044d0db0607a2d336cb728@huawei.com> <BY3PR05MB8081303B970FA79D0FD0D9FFC7EC9@BY3PR05MB8081.namprd05.prod.outlook.com> <3e178886232d4b59bae0d0fcd1c8b5de@huawei.com>
In-Reply-To: <3e178886232d4b59bae0d0fcd1c8b5de@huawei.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.401.20
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-04-14T13:11:44Z; 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=42b08adf-a26c-4f70-b8b1-fd6414cea9f5; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 251217c3-f911-40c9-66c0-08da1e185422
x-ms-traffictypediagnostic: BL0PR05MB5539:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: <BL0PR05MB55396FB1809645904C9E4460C7EF9@BL0PR05MB5539.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tiK5DZoHWOEg2IrzuVMyPWXcYGrjMK9Z5mQuQKlhpEKYkgWOBK1WTYsZCaJ+WXiFlGhRUNcBdK/oQUY86t/qdw20TxBYcssAgFhEfx+SIbtiQ+EH6jo9O6C4OsNi/811Pl6ZFZ1dnMO+MMh15qROri8qBP3TVvUbSuPsPN7pZq+iyBuq9PbLn4sEdoO5bsZSFuBTkJU34CX/zIiEjDITT6Bp0hswCRwfLpYhf1lpqH7KDtpYqrMpcthtDfpbgGJkc7l1X+Pb09ly7S79PT9/noHSTVy61f08v+esjdh6WrV3gs/CUZYqwdHi1JEhO9zrlQjHFbzL7YrH/C3+kUDw1bFSnm42D6c+VPHKXp85nM0uBY1tDmOJO7/39NCz6+EGTUSVEQLmyQzxKhgn2vQKSU4+vC/Rn6+5Prfa5B+YUfuLwC4qZwwi02brdlFZAp8jbBc5lXeHW2U3ZydMoCWpoWYhq6fAnKODLvZ1IXRJ9mFXRBoNygcSuBu5ZbTLym2n77TIkdSFcaYoGmgY8Z9qgVhzRIIJO+qCKFyoaxeH7IhVsTN14fFghBLEMqIn+p7+2dzFUL4Y8mv2lzbLiQ5IKaAO4gpVIC7cyBZ9G71YcXMgz7Zm4Wi6OrMh5bPQOPoPMj/isaCXqhVl+rRQaoC+s+PzKhoG+3qi3jRX5Lvf82UaNWaUQ5H2+hGtXsyFUqp5l0svOGnL3zJqFH8JyWqSvSIs6xDwbeVTkzDCAj687rI2aqy360TmqJD4QvXGjDl2
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:(13230001)(4636009)(366004)(76116006)(122000001)(508600001)(38100700002)(2906002)(66446008)(66946007)(33656002)(53546011)(6506007)(9686003)(83380400001)(38070700005)(30864003)(7696005)(64756008)(4326008)(316002)(66574015)(66476007)(66556008)(8676002)(5660300002)(186003)(26005)(52536014)(8936002)(71200400001)(55016003)(86362001)(110136005)(17413003)(491001)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: +Cv56OUjNLk8mx2TVc5u5iJlWGxjryN1M4xGXFBZ0ihpAcHrRfoTg7U8o3Ag90F8H8UF9ak38r/4DCJuwI6kdpTaezkCd6fT94kg0P6a0HiuFh9bY986bQ4KtsnLmpkGt2OiCWD3WzS9TFhEOi9QotfxJT+ktSNW7gUXR6LecpqfFTGR0hyqGSYMnzw4wtIaP0odb94LTEQ1b6yZGfOlQ+Pdm+SfE5F7s74g7ng/yrfP6PAksXU+IB/3x3xDfHTOtuXjlNOWE6TR0B40675jToYGEBlgBRTi7e5kgAxFZDn4CicD1im5FqzMqO+TZSY4QU0d4xX/1jjucJ1ls8gsgJg3ihJMkfx9fZNO6+eVjWAfhEqmaWQqoZ9lP7YNyUGxg4CK0QjpMX6Y2Cud2h6ERYgUqH0EY7ClaFF/L68YCzYcHsSJgtoqrG6Zy6CJmYbXVkA6f3VMJ6WAtoIm+qLLetsJHqc1x45cKt9ULwE2tV0gWp7CAY7UlC1ew4voPrH0K1UBJRy9exqOQ3aEWag7FNim44KVVo/yNH//v9r6wSCdtSKKQ6ono8Be+64zVXXVsncDUkhdEzdynkgqPUN5OT4eplX653TQrkB3Nfd/2NIFOrbIYLRdws0zuJ8fXpeXRwu2w3QvXHExn1s/+KHDeqgYNrA0/d10pAm5rAL7dYdRrAv27rBOJEngCxXyQOpwl2jO+ar4QhvxZv0etA9gQIqRemAFlN52ZARTtFe6+EM2C8OMicXzGazp//aoj4KdWGv79Al6pgj2Gy6KMQT2wyrtj+gAUU0kXnUd6xTPYi6MTa3IjetazHyjd1ygKA7WEESk3l7kNQIX8xGn+n7lqdsr4giD53K/6jmtSU9jIDeAT4cP41rdH+is/5T45rbLBYu6dvAf6SRFPHOG/J1ONo0kd6J+UHoE4mzYABE9vBpNN8jOhXIO8nAlSIuN7xSMc3kdihZgb/7RF7stJ0NiHTio79mInaxDK3WuJhEOebyV1oYJkMqG//2AbXLOpT/oHEAB7JErMh3ts40zkyFX9I9jUsW9CUVtdp0IGRsw4nQAt76huGAjWHc6ddBFM58IID+lYazKnYiN8uV2QA1dP+5BSq2GtYinKfgxCEFZCHEHs6OLgfy/Uv70mflLyNAp7RADGAy785jHFBVD9Ww5l6wtVSDuvqEEeJlFc6A2ETzvwoseHxhNCVpyjeyP4UtkoeGxS+K1ohCduZuNWXAuHWJNPqhDknUbZPx/fZu1HyceuvBl9Azex/Iy3k7RBCGyLgihCzt4tcRbq4X7oFGwKwgHYOMMXKajc4bs3snU9a91IjIHZxCmovlbKjKoJfqlFQH9P7kvv5w1nkQgZD/Qtnnas8lMILw6NiBOPwQ6l8iIPB5inD3GdeQxRnwMtF6CWvnCTt7Lnp5Oux9LPILVOc7WAb2xB69f6Eqzj/RA/3AubO8jqS5YyqKtWXmm16ecsw77+Mtnb4jWAI/59tc0Hpe2gq0jOPqU8gTlbanZp7eNKMmRikO5mJhsSlfx1RnwXUxxXsNqXYxUhp+GKIZTmsUWq22qOgQYKMMMs0Hk3IeK8m0WR9qZTehC16tsGz3px8l2BCr+Rr0MsVEXEoNdcqlkgaht0jQsXtZDkI8bqv283ELE3C+OYSBPYO2aOETcQoGwVEsclOIcAmtSnOZhe4sx8xrUv8ED/+eMl523eK7KZhfOUCl0EW8DxZcmrnWfjPLQda26RED+7BIw13JLRg==
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB8081530D8D3FFAD7EFE1E4A1C7EF9BY3PR05MB8081namp_"
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: 251217c3-f911-40c9-66c0-08da1e185422
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2022 13:11:46.5779 (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: U9eAkdt13EbKTfJqR4lUc6tlyeZ/kQvsH1jZO1mf2WX6ZCcBiwA8hN0XXusYOvbfuGxCg+CLXFPihSfuw7KSKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5539
X-Proofpoint-ORIG-GUID: teJT8j7NNIp_NMXARiQZsw2SWCuE6nNm
X-Proofpoint-GUID: teJT8j7NNIp_NMXARiQZsw2SWCuE6nNm
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-14_04,2022-04-14_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204140072
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/GLYE450md7zBnSuB79QCMorSLfo>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != 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: Thu, 14 Apr 2022 13:12:13 -0000
Jie, My first reaction to a) was the same as yours, put then I re-read the existing text and sets of paths are consistent with it. Yours Irrespectively, John Juniper Business Use Only From: Dongjie (Jimmy) <jie.dong@huawei.com> Sent: Thursday, April 14, 2022 3:05 AM To: John E Drake <jdrake@juniper.net>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>; adrian@olddog.co.uk; <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> Cc: teas@ietf.org Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization [External Email. Be cautious of content] Hi John, Thanks for the discussion on this point. Please see further inline with [Jie]: From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 13, 2022 9:44 PM To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization Hi, Upon re-reading Krzysztof's email, I think we should keep the existing text and supplement it with Krzysztof's text, but striking the second sentence. Comments inline below. Yours Irrespectively, John Juniper Business Use Only From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Sent: Wednesday, April 13, 2022 2:53 AM To: Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization [External Email. Be cautious of content] Hi Krzysztof, One concern is the text you proposed is the level of detail which the framework document was trying to avoid. And as for the examples you provided, I'm not sure if all of them can be called NRP. For example: a) collection of paths optimized based on certain criteria. For example low latency paths for NSP-A, and high capacity paths for NSP-B. Low latency paths and high capacity paths may be obtained by using different metric types in Flex-Algo or other path computation, while as mentioned in a previous mail, depends on the network structure and topology, the path computed based on different metric types or constraints may still be the same or contain a set of shared links. [JD] What you are describing is how the NRP specified in a), above, might be instantiated. I think a) is consistent with the existing text [Jie] My point was that the mechanism in a) may not be a good example for NRP instantiation. As it is only path computation and does not describe how the resources are managed or reserved for different NRPs. Then it is not clear how the performance of services mapped to different NRPs with shared paths or links can be guaranteed. IMO some kind of resource reservation or management is needed for different NRPs. [JD] This is an issue for the service provider [Jie] Indeed service provider needs the mechanisms which can create NRPs to meet the performance requirement of different services, even if the paths or links are shared with other services. Best regards, Jie From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Krzysztof Szarkowicz Sent: Tuesday, April 12, 2022 10:08 PM To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization John, Adrian, Med In that case, I would propose following text update. The reason is, from the current text, I cannot extract the the examples provided by Med and Adrian could be and well considered as an NSP realization. ===== Current Text ============ An NRP is simply a collection of resources identified in the underlay network. Thus, the NRP is a scoped view of a topology and may be considered as a topology in its own right. The process of determining the NRP may be made easier if the underlay network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs, but this is optional. ====== End of current text ========== ===== New Text ============ It is out of scope for this document to describe the details, how an NSP can be realized. However, at a high-level, an NRP is simply a collection of resources identified in the underlay network. Some (none exhaustive) examples of an NSP realization are: a) collection of paths optimized based on certain criteria. For example low latency paths for NSP-A, and high capacity paths for NSP-B. b) admission control - possibly with large number of QoS classes - at the transport access, coupled with limited set of transport core QoS classes (PDBs), and N:M mapping between access and core classes. c) combination of above d) more complex realization schemes, with combinations of advanced QoS at both the access and transport core, possibly coupled with Filter Topology and different path optimizations methods. ====== End of new text ========== Best regards, Krzysztof Szarkowicz On 2022 -Apr-01, at 14:43, John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote: Krzysztof, The usual answer to such a request is to ask you to provide text. Yours Irrespectively, John On 2022 -Apr-01, at 15:44, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote: Re-, Indeed. FWIW, some of this is captured in RFC7297 with a focus on legacy mechanisms: == These requirements include: reachability scope (e.g., limited scope, Internet-wide), direction, bandwidth requirements, QoS parameters (e.g., one-way delay [RFC2679], loss [RFC2680], or one-way delay variation [RFC3393]), protection, and high-availability guidelines (e.g., restoration in less than 50 ms, 100 ms, or 1 second). These requirements are then translated into IP/MPLS-related technical clauses (e.g., need for recovery means, definition of the class of service, need for control-plane protection, etc.). In a later stage, these various clauses will be addressed by the activation of adequate network features and technology-specific actions (e.g., Multiprotocol Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), by means of CPP-derived configuration information. ... The CPP template aims to capture connectivity needs and to represent and value these requirements in a standardized manner. Service- and Customer-specific IP provisioning rules may lead to a dramatic increase of the number of IP transfer classes that need to be (pre-)engineered in the network. Instantiating each CPP into a distinct class of service should therefore be avoided for the sake of performance and scalability. Therefore, application-agnostic IP provisioning practices should be recommended, since the requirements captured in the CPP can be used to identify which network class of service is to be used to meet those requirements/guarantees. From that standpoint, the CPP concept is meant to design a limited number of generic classes so that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ individual CPP documents, by capturing the connectivity requirements ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of services, applications, and Customers, can be easily mapped to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ these classes. ^^^^^^^^^^^^ == Cheers, Med De : Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>> Envoyé : vendredi 1 avril 2022 15:26 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; teas@ietf.org<mailto:teas@ietf.org> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization Med, We are on the same page here. I see this as well as predominant approach, in fact. Cheers, Krzysztof On 2022 -Apr-01, at 15:20, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Krzysztof, Admission control + use of limited set of core QoS classes (PDBs) + much more access QoS classes + map access QoS classes to core classes + no multi-topology/customized path selection is also an example network partitioning. I even expect this to be the privileged approach when legacy forwarding mechanisms should be used to fulfil slicing objectives. Cheers, Med De : Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>> Envoyé : vendredi 1 avril 2022 10:30 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk> Cc : teas@ietf.org<mailto:teas@ietf.org> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization Adrian, Med, Returning to this. I've seen many design cases with SPs, where the network is designed physically in very structured manner. Also, I've seen some analysis done by couple of SPs, that as the result of this very structured network design, after making internal analysis, they don't really see the difference between path placement done using IGP metric, and path placement done using delay metric. Hence, even introducing some flex-algos (TE meshes) with different metric optimization is questionable here (as the resulting paths are the same). To realize services with SLO commitments, these SPs today extensively use admission control at the edge (some times even relatively complex admission control schemes at the edge). But, they don't use anything specific (TE, Flex-Algo) in the transport, apart from mentioned admission control at the edge (ingress/egress policers/shapers), basic QoS on transit, network capacity planning, and timely capacity upgrades, where needed. Does this approach could be considered as well as some way of 'network resource partitioning' mentioned in the draft? Cheers, Krzysztof On 2022 -Mar-28, at 12:26, Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>> wrote: OK, If a realization example of network partition is flex-algo + admission control, then I am fine. Thanks, Krzysztof _________________________________________________________________________________________________________________________ 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] Slicing Framework Open issue #1 : Service … Adrian Farrel
- Re: [Teas] Slicing Framework Open issue #1 : Serv… Joel M. Halpern
- Re: [Teas] Slicing Framework Open issue #1 : Serv… mohamed.boucadair
- Re: [Teas] Slicing Framework Open issue #1 : Serv… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Jalil, Luay
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Kiran M
- Re: [Teas] Slicing Framework Open issue #1 : Serv… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Adrian Farrel
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Gyan Mishra
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] Slicing Framework Open issue #1 : Serv… Greg Mirsky
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Joel Halpern
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Krzysztof Szarkowicz
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Gyan Mishra
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… John E Drake
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Gyan Mishra
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Joel Halpern
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Dongjie (Jimmy)
- Re: [Teas] [E] Re: Slicing Framework Open issue #… mohamed.boucadair
- Re: [Teas] [E] Re: Slicing Framework Open issue #… Adrian Farrel