Re: [Apn] APN vs. Network Slicing

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Sat, 31 July 2021 01:24 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF463A1C9E for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 18:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=qINPcxQp; dkim=pass (1024-bit key) header.d=juniper.net header.b=ELkSVqYE
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 CePiG25lbeWr for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 18:24:45 -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 B5E2D3A1C99 for <apn@ietf.org>; Fri, 30 Jul 2021 18:24:45 -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 16V1EoCL002894; Fri, 30 Jul 2021 18:24:43 -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=TRpjoBR2vKcxmtx4LpnvdT7xE4LaJ5MxE0YmhCsOOQ0=; b=qINPcxQpeXUwN9WE62Ik6Y8m9aclTnUKZrSjNNakfL3Ld2t5EQ6yIL3kvllXfMu8JW8k 80puel+K3nIR/TMo3tBw68YpbFEqZUL1EHxtSmS4AzoUadILK4bG8qR9gxW+0CZEh78P y7MgdA0bvf+InkUHOFd94oOs4hvNhqi/RW2uWibJPva1Oc8117qNJN+cbRnPgNFMO4YF ETDY/LxYBAzCBHL2a1IirS7qwh2rpMK3Y46sq51WzciaGHlG4Fb9TyW3jiqQVckKFUuj ivnGobwDQ4CblNtEPMYJfcbemHN9By+ENYfNWtUNJD9VB73MUDv8e6wig04V5dAeN+Or OQ==
Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2042.outbound.protection.outlook.com [104.47.74.42]) by mx0a-00273201.pphosted.com with ESMTP id 3a4efrha1j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jul 2021 18:24:42 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JgzxjfpChTlFYrrmCk5EsL6s07qPKfDTlamf3od94Qd+Db5HpZcLULipmKc97gxoBx21+BZTaLIC7JUX6TZ2/XNZyuQWdSweVZ6aV81kEc/g5TLhicT4aWAuP3oJgHtSznxQ5P7mYYBMaVPlUSHDFKXR7sNpU85olQiNaXQRYa+pfoxh4kvhvNMiphiNhW0LKZ+vMZXKWvMNgAza4wMoLouD3qJyXQzbjI1OCwPJqgZ2Q/g/JKiQFvTTpiOZMZk+rS9HMHR6FCOg0hCy5mREy5ughkjj82CEYL4KRhiBKEbhafl5Z5RZujEAI05hrFE8k4450vDdJf95nh6prN/GNQ==
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=TRpjoBR2vKcxmtx4LpnvdT7xE4LaJ5MxE0YmhCsOOQ0=; b=L/j+NNqK8MCtD8BwO6XQgFzbt+q4DhVFCIm+Yg6fSPRlgi3VuOPdZGopuM+pQqwxzKx/I8ccXWan335UoS2EIW3tBMeKzHKmA1Z36hNH3XBM0EFxZwkp5+gorOFAFyMq/HzNtzsbafKoSoiObskzjSXGoTz5NyUTt7F/7xP5v/3dbbXHDCO46FECIh0xrU0gj9xuW71QixMQcY1VpmmaGXteYis3bSM/Hp96RycbIeL6hwFDpwUd3pHYC05l0ZN30ddXovV1m9hM5PI51gNlh8Beo7Mcp3wDRHZvZna1XAo21X7TAXu8iVTHN/uKzCKljW+muM0Jcktm1F8rqD0QNA==
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=TRpjoBR2vKcxmtx4LpnvdT7xE4LaJ5MxE0YmhCsOOQ0=; b=ELkSVqYEAPYPmpwx7Wu0hPkDnkjuKmqJAUdxMiHCK9kSxQ4svcJXDFX1KpodHXT5y0PAQDZdAYIP2VC0H3VIcKZnLLbupATw/FBHuGS41i/NO4tTCrm7BM5+zH0cMAfH3kR5WJLF42PTKlRuWu4Dom8ul+CLJUalQq7ed0/Wibg=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by BL0PR05MB5313.namprd05.prod.outlook.com (2603:10b6:208:66::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.8; Sat, 31 Jul 2021 01:24:38 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::79a9:298b:4d86:e04a]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::79a9:298b:4d86:e04a%6]) with mapi id 15.20.4373.022; Sat, 31 Jul 2021 01:24:38 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "james.n.guichard@futurewei.com" <james.n.guichard@futurewei.com>
CC: "apn@ietf.org" <apn@ietf.org>
Thread-Topic: [Apn] APN vs. Network Slicing
Thread-Index: AdeFhlHdOXqXK2QrR7WWz8wtWTj6JwABwCKAAAZdMfA=
Date: Sat, 31 Jul 2021 01:24:38 +0000
Message-ID: <BL0PR05MB5652E330EE8AC3927454870FD4ED9@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com> <0ff501d7858d$53a42bf0$faec83d0$@olddog.co.uk>
In-Reply-To: <0ff501d7858d$53a42bf0$faec83d0$@olddog.co.uk>
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_ActionId=fccd63c7-16d4-4095-8ad4-0caf75437101; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; 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_SetDate=2021-07-31T00:55:39Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9eb3e09e-9d7b-4874-c567-08d953c1f6cf
x-ms-traffictypediagnostic: BL0PR05MB5313:
x-microsoft-antispam-prvs: <BL0PR05MB53131EFDCA55DE9FBEABFA30D4ED9@BL0PR05MB5313.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: atAyV+l1ZBR+gN2pDxN2rJdS8/j/EUC08T0z43thGOpksIKwHvlQkb8uy6GFMGDw/s1HMDmDIok/2QoQ6KY8SiX2uxBO8zvUfLlej0XV843X68ekVIXrk8tv7hiTTbKTCj+8Gziwf0kzyg2gR1Y5lwyeka0hULi00Te60KazK5e+lv3vFZ/yce/YX2SJSB0+tY8CQIlSmQanQ+cuUKJYSield7NIxgOW05LZxGLYhuIgknurZeRScZb1E3apqpQRKLMEuXsPn3wB2k5dSkCKwqYoOgezsNDZ50N2L14/9+yNZghDRBLZSIa/vlkz0tYRpXrObeUtndHtZkSPpa9/ZM/u+CKzSLfdI+qjj314fpAFDunMq22HsS6bU8gV6D+9JbqYYVHDhb+Q2qHuf8eqqLM+kxWwTfbvQQ3YOBhYq7hzsSPUHfbhMEcCHQ6Ip0q4rrEOUrA2toBvt6TFUwIktPLh+r8AmV5A26bYKrSMil3Z1bsBYf3PkNM7mhWNVUauDmLbj7HF1wkzltvl4xOMmPcUhC9d5qufDi3KYAulhVsw4f+7Y1GfupDdWz2mWBtfLlEZCBeEd4O9P2x+B63fs7G1WQO5TOsZ54KI20LRFuWN/KJ8qsdmQX/KRjVZ4USd8BPK4aCE2QItFkM4tAXKHxppLFcw0+4J7pKDaseE1WSL1FY+Zh4aw8OC7Pc57l7wfQL0F8SdnFEs9HJuEMXaVazhANFYilvCu7QQr/jOl6y3zHQFJY1nEu6axh5av2Z69szgt3n08DwGcKvypKWvN9HsyN78MMlZxR33ml56wc7eIo0t04/xjFlh+/TCO9IJ
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(52536014)(5660300002)(86362001)(8936002)(110136005)(66446008)(38070700005)(33656002)(26005)(9686003)(316002)(478600001)(64756008)(186003)(55016002)(76116006)(38100700002)(9326002)(6506007)(53546011)(2906002)(71200400001)(166002)(4326008)(7696005)(66556008)(966005)(8676002)(66946007)(122000001)(66476007)(21314003)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?M0FXUDVGU2sydW15d1R2NHhxWUt3bnZBdDJLYUl4blFwams5dEt1SlBX?= =?iso-2022-jp?B?eXI4aEY0L3FjenhWWUFJcHFsQ1Q0Rk9oU0ZRMGc1UW1lS0FxT1ViM0wv?= =?iso-2022-jp?B?R1h4SUVob2dXYlhNdHQyVHlPRm12RWdRNnJ4ZmdpY0lRdC9HUlRXQ1dL?= =?iso-2022-jp?B?ZWJnMkJIbDZHOGlUKzR2UjJPN2pha3VETFZ4Sm85MFBGcnoyYVBRWGc0?= =?iso-2022-jp?B?SlA5Z2ZVbnJnSU1EQW1uMTdFRjNNc2Y2dTU5M05RN09yQ3hwb0hHenMr?= =?iso-2022-jp?B?dkxuV2tSYWxKUFFzNlZPYW5IOUVtWmNUcVk2UTlsekhEd212NWJwM2pM?= =?iso-2022-jp?B?dWdhSGlzTE4rdk5qZmY2ZU5MNTBUTU1xNWppUDFhbHk4bE9iVHdHbXZG?= =?iso-2022-jp?B?dDNnMGlWSkRKSjRjdmtlMTgyUmN6bDg4M3o1Z1FHUG5HeUhiaXNJWnQ3?= =?iso-2022-jp?B?UGxhT3NiUC9wNktsRUh6SUtYa004cmZjTm9PMFFqckZDaFlPajZUOWFU?= =?iso-2022-jp?B?WHZjU3RoZTk5Mmp4cEUzRFZwbU90ZDQrdENFUlZhZUc4MmZFd1I3RUdS?= =?iso-2022-jp?B?VnFoVC8zRE5sWGJoVDJVc0Rib2ZtNzYxZzA5UHZZdlpWbTliNE00NG5h?= =?iso-2022-jp?B?ZHZKWGZLSTAzdlpQUjNrTlorakUvMW5sUEovdVVaWE9QMVloWFlnNWxD?= =?iso-2022-jp?B?UXlxc0xreStjaHU1clhKamJyOGNZRVdUL0M3bDBWbWJyZ0lWK2MwSmxP?= =?iso-2022-jp?B?UkR4ekx0UUI5N2Jhc1oyRGRzMEkzSnhkVmFWYkJwK3NadCtRNjhUQk5F?= =?iso-2022-jp?B?cTZDK1BuamI0ZC9CbFA2VnNtamlLSDkxa096OVZYa2IvcXg2elo4Smxh?= =?iso-2022-jp?B?ZmQ2SjlwaVJzeWNteDViUkNkVUVMclBwb295MkU2cXFFZzY5NE9xakJR?= =?iso-2022-jp?B?VmVuc2N1eG8yNHF4NW1uTmFxSWk5ZmxoeHZzL0c0cUN5ZVdLSm8wMDNw?= =?iso-2022-jp?B?UnBZTUtqc1FhUWxKV1ptUVFxOGNleGljYnJmRWEvY00xbUhvbHNBc21r?= =?iso-2022-jp?B?S3cvWEdiMEorNVhtbmE5ZlNvQnlRelZBcHpHRm1tTlpYYWt0eFgxQzdN?= =?iso-2022-jp?B?QUIrU1lSd2RGWkRnNXNMazFQRzJxNlp5UW00WkxSUVBFalBzbDFPdHdR?= =?iso-2022-jp?B?S2NUZTlGZlFEWkdTS1AxMmF5RDRrcDZBSUxLSENBZEVJTmRITnc3U2RO?= =?iso-2022-jp?B?RnlJVWdPYU4vZTVrcTNzVjExdW1reEZPczEyN3Era2VzQy9uYzFGYjVQ?= =?iso-2022-jp?B?RjJoU1dsVU1vMEFWWmo1alorVkRNWDhWODZyMFhVWE5TMTFCRFA2Q0tp?= =?iso-2022-jp?B?Z011ak9NL09JWjl3VnZieVg5V1RhWHIzSmRKU1FOUitHcFI2SkNObG11?= =?iso-2022-jp?B?ekFXWjlOK0VlTGx0VmcyVTVRUGFCRTViNkFjVENNMlJRNVNKZWtTTlFS?= =?iso-2022-jp?B?SmxFNlloeDdWZ0RNQ0FTWm51R3RjVXlLV0ZYeFVxTDVPN290NlZDVERW?= =?iso-2022-jp?B?eThlMFNtRGVVQ0ZLalM4d3I2b1I1aGVmOGxyY3I3RnZ5aWk5MmwreFJm?= =?iso-2022-jp?B?U3V1WTlDVjFsdGQzUldBMzRxNndRS09WVEQvcHh2eFdtdzB3ckowbXJF?= =?iso-2022-jp?B?U21Ec0RkTVZyOXQvYTFvRUJFTTBVMFdXYVlkUk52V0FnSWZPRWRFZEh6?= =?iso-2022-jp?B?UnFGRzBrWExmWmREYU8zcXc2cnc1WEVhMlVzamZwR0tkM1ZsU3Jxb3R3?= =?iso-2022-jp?B?WWxvYjdDYmtwbnR1a1JsZDJZWXI1Kzg0UTRsV0ZINUdpdmJ2bWJCQVdW?= =?iso-2022-jp?B?bCtwYWdZWWVLclBremFXc2tienV0V0dZM21oV0M3c0xqT0NmNkxGdUZi?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5652E330EE8AC3927454870FD4ED9BL0PR05MB5652namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9eb3e09e-9d7b-4874-c567-08d953c1f6cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2021 01:24:38.1632 (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: D1WATAAsLHG8k3+xGouXiXEGSvZAhWK1lWWwSMyv3b4oP1kpjet/PDwhFcdDatD0AaVe/HuRM3oX4Wd3jB55eg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5313
X-Proofpoint-GUID: qrqfK0iiJwVPtW8oPGfs-9JEYKSjl1aD
X-Proofpoint-ORIG-GUID: qrqfK0iiJwVPtW8oPGfs-9JEYKSjl1aD
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-30_11:2021-07-30, 2021-07-30 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 malwarescore=0 suspectscore=0 adultscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107310003
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/ysQwdTrZiojFU4uDijS_jRxIh3Y>
Subject: Re: [Apn] APN vs. Network Slicing
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jul 2021 01:24:51 -0000

Hi Adrian,


Indeed you/some or maybe all just see a single level of indentation. In that case, the 1st and last bullet are supposed to be first level bullets and others are second level bullets that explain the first bullet (that IETF slicing covers the APN problem domain and solutions).

Also, the second last bullet(about “slice aggregate”)is also indeed my opinion (like the 1st and last) not quotes. Others are quotes from the IETF network slicing framework draft. Thank you for quoting them out correctly.

Please see more zzh> below.

From: Adrian Farrel <adrian@olddog.co.uk>
Sent: Friday, July 30, 2021 5:53 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; james.n.guichard@futurewei.com
Cc: apn@ietf.org
Subject: RE: [Apn] APN vs. Network Slicing

[External Email. Be cautious of content]

Hi Jeffrey,

The formatting in your email may be a bit garbled, and I want to make sure people understand the distinction between your opinions/assertions and what is documented in draft-ietf-teas-ietf-network-slices. (Let me declare an interest: I am currently the editor of that document.)

The material that is quoted from the TEAS draft (which is still a work in progress) is

  *   An IETF Network Slice provides the required connectivity between different entities in RAN and CN segments of an end-to-end network slice, with a specific performance commitment.
  *   It is intended that IETF Network Slices can be created to meet specific requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required characteristics.
  *   An IETF Network Slice combines the connectivity resource requirements and associated network behaviors such as bandwidth, latency, jitter, and network functions with other resource behaviors such as compute and storage availability.
  *   Term "Slice" refers to a set of characteristics and behaviors that separate one type of user-traffic from another.  IETF Network Slice assumes that an underlying network is capable of ... fulfilling all or some of SLOs to all of the traffic in the slice or to specific flows
  *   Many approaches are currently being worked on to support IETF Network Slices in IP and MPLS networks with or without the use of Segment Routing.  Most of these approaches utilize a way of marking packets so that network nodes can apply specific routing and forwarding behaviors to packets that belong to different IETF Network Slices. Different mechanisms for marking packets have been proposed (including using MPLS labels and Segment Routing segment IDs)
  *   The realization can be achieved in a form of either physical or logical connectivity using VPNs, virtual networks (VNs), or a variety of tunneling technologies such as Segment Routing, MPLS, etc.
The other points in your email are your opinions (and very glad you expressed them).

I don’t think that what you quoted is particularly opposed to APN, but it is notable (perhaps) that there are currently several proposals to achieve similar things. If they are really trying to do the same thing then inventing multiple approaches does not seem wise. If there is a good overlap between approaches, it may be wise to make sure we select an approach that is inclusive, unless we decide that specialism has a significant benefit.

Zzh> I am not against the APN problem domain. I do think it is in the scope of the slicing work (plus the “slice aggregate” concept in draft-bestbar that provides finer granularity below slices) and further discussion/work should be done in that framework instead of a new WG. Slicing is the solution for APN problem domain, not a use case for APN.


These questions extend to how “markers” are applied to different forwarding planes, and to what information is carried in a the markers.

Zzh> I do think markers should be simple opaque numbers w/o any structure defined. Besides that it simplifies the forwarding plane, it is also "future” proof. Imagine that a structure is defined for the APN ID to be a <app, user> tuple and hardware is built to parse the app/user fields. Then a new requirement comes up and now we need to add something else to the mix - we’d need to respin the hardware. But with a simple opaque number w/o any structure, it can be mapped to any combination and no new hardware is needed.

Zzh> If that is agreed on, then MPLS label does the job already for MPLS data plane; just like how the VXLAN VNI is the equivalent of an VPN label and SRv6 address’ func part can be the equivalent of a VPN label, those bits can also be used as opaque markers in APN or slicing.
Zzh> Instead of defining a new standalone opaque marker and put it as a new field in MPLS/V6/NOV3 headers, an MPLS label can be put into the VNI field, or become part of an IPv6 address, or even put into some kind of extension header. I don’t think that conflict with the goal of having a *generic* marker.

Zzh> Thanks!
Zzh> Jeffrey

Cheers,
Adrian

From: Apn <apn-bounces@ietf.org<mailto:apn-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 30 July 2021 22:28
To: james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>
Cc: apn@ietf.org<mailto:apn@ietf.org>
Subject: [Apn] APN vs. Network Slicing

Hi Jim,

To follow up on your comments about APN vs. Slicing, here are some points that I did not have time to exchange during the BoF.

- While slicing does involve setting aside/up resources, that is the means to meet specific requirements for traffic delivery.
- Traffic delivered in network slices are identified by some identifiers so that network nodes knows how to forward them to meet the requirements. Combined with "slice aggregate" concept introduced in draft-bestbar-xxx drafts, fine granularity can be achieved down to flow level (vs. slice level).

In short, the goal of APN and slicing are the same (or slicing covers even more). Additionally, it is not that slicing is a use case of APN. It's the other way around - slicing does what APN want to do.

I could not get my one-page slide shared to better illustrate my point that APN problem domain/solution are already covered by IETF slicing, but let me post the text from that slide here. The sub-bullets are text quoted from the network slicing framework https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices__;!!NEt6yMaO-gk!Tn0O_z_GumjnV0ysybB5jRF3-4MsafOLj8DW2cu5soF9C9dMSRUbgu78AEW1eNqe$>。


  *   Ongoing IETF Network Slicing work already addresses the problem domain and solution

  *   An IETF Network Slice provides the required connectivity between different entities in RAN and CN segments of an end-to-end network slice, with a specific performance commitment.
  *   It is intended that IETF Network Slices can be created to meet specific requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required characteristics.
  *   An IETF Network Slice combines the connectivity resource requirements and associated network behaviors such as bandwidth, latency, jitter, and network functions with other resource behaviors such as compute and storage availability.
  *   Term "Slice" refers to a set of characteristics and behaviors that separate one type of user-traffic from another.  IETF Network Slice assumes that an underlying network is capable of ... fulfilling all or some of SLOs to all of the traffic in the slice or to specific flows
  *   Many approaches are currently being worked on to support IETF Network Slices in IP and MPLS networks with or without the use of Segment Routing.  Most of these approaches utilize a way of marking packets so that network nodes can apply specific routing and forwarding behaviors to packets that belong to different IETF Network Slices. Different mechanisms for marking packets have been proposed (including using MPLS labels and Segment Rouing segment IDs)
  *   The realization can be achieved in a form of either physical or logical connectivity using VPNs, virtual networks (VNs), or a variety of tunneling technologies such as Segment Routing, MPLS, etc.
  *   Slice Aggregate concept (similar to DiffServ Behavior Aggregate) in draft-bestbar is about identifying some or all traffic in a slice using opaque numbers and providing corresponding forwarding treatment

  *   Forwarding/steering should be based on opaque numbers not structured APN IDs

Thanks.
Jeffrey


Juniper Business Use Only


Juniper Business Use Only