Re: [Apn] APN vs. Network Slicing

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 03 August 2021 19:46 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 789EE3A307C for <apn@ietfa.amsl.com>; Tue, 3 Aug 2021 12:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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, 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=ZV2i0Bu1; dkim=pass (1024-bit key) header.d=juniper.net header.b=iyE8R/E+
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 8RnV8gUeA67l for <apn@ietfa.amsl.com>; Tue, 3 Aug 2021 12:46:28 -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 F17153A1593 for <apn@ietf.org>; Tue, 3 Aug 2021 12:46:27 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 173JTtrM015246; Tue, 3 Aug 2021 12:46:20 -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=NTBj3REkvX3VA8wdAJygwmD/kMmfQ6T4XTD8IgVh9/g=; b=ZV2i0Bu1gqZUvH59ibvkzTUmSWpZCFm67fCLyW91hE28xuNixvtzGnoSlvdvuawokOw9 qeLYzkbuBcZBFpF8YGubkALRn6IUb8iHcS4cUe3QblOArIeWsdrOvlj7nvEdcCVMhQPO MaoT2PJQfUYkPMbyKXKTmEss+mvgwAree91qWpCad+lmsESqcN3ObZLU3g4ZDv3IJSly NmjXqfNJ3f9uKOdpYqiCmNMtXFCnpcMpJE5NrxIWjjhwgVqWlgpSyhB0YLgU9CwaRp6x 4/NsQNHpLqJrkHk0/EqyaIBJ9lO13o7giNzqA6AWmO6lZY+jCpSZDy7aBIIfoLB0Bar1 Ww==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0b-00273201.pphosted.com with ESMTP id 3a6t7ghur7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Aug 2021 12:46:19 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HqXQiS9QGtUZnBXe2tdXVaoNZ+zYkkndyyI+/vb72WcuTD5vJEUbibudfw9VbZCOc7g1xXDANyTq8pCGwxa4KupGn9SMfQw/QX2OqpUqUTpZ5uwQPM+7tWdLwhDJ+LjMpf5sXlw7WGlU/LBLQ2BCZ80PkoaGp8KRNUtq6rGXisapgCtwabVMXBYMi6HW37CA/al4qr17ivnDwkO7Y2NYz4Laj97kDGmHhyUbt5zxtdtXwTAhxWL10+WMOakqtViMPCkGbjyarTwk1b8IRjBxa+3kOWrcFGf/N6vRy/XQMKW/HFy/qoEQdOv8WrjAuqLx/UQde/m6pTpgTLIu+jM54Q==
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=NTBj3REkvX3VA8wdAJygwmD/kMmfQ6T4XTD8IgVh9/g=; b=MIhISIKy5wIYOSfRdlEobwz5EjBDzUufKI7B4c+o3GRhRkIVeulJHDFFtx5/QKxKpRcO8n10o+y+Il1v/ti9OFAgek6Ougl6eroCVow3mF2VMAIPByQbYSCMe74l4qwbhzykrgfVaO2tVcNtiwRe6VkEliFooCPV7OOApezcWlCkWJtLbpU75EwNj8ZNUVHaz4umYpvuHq0FJvYUcBDvjta7SYYhVTKuCBJqSGCU5yw3OrCx4v1TIfitULZ/daazx1RltLGYgCe6E7Jfc03N/RQl1h+NK5yqKAgF/CQfOELQHxw9tKg5I1iJE6lRMigq+a92rq/l2dRnp3E+nKjcYA==
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=NTBj3REkvX3VA8wdAJygwmD/kMmfQ6T4XTD8IgVh9/g=; b=iyE8R/E+g4DCRLtcIrzxNlLIiCky+pTZ1eFaQXclFsrBETHzzQpLkE0xjZK+uW612jbDkxvNWzQo3QFH5OlK5BJrVjh70h/dfrGfTlonNW3xPsrgnnRg/xZsrMpFOoXRqUb8zbh940LSRQ8nkcou+SLLkihuY6WJAN1DnWHpVnM=
Received: from BYAPR05MB5654.namprd05.prod.outlook.com (2603:10b6:a03:18::17) by BY3PR05MB7954.namprd05.prod.outlook.com (2603:10b6:a03:363::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.12; Tue, 3 Aug 2021 19:46:16 +0000
Received: from BYAPR05MB5654.namprd05.prod.outlook.com ([fe80::2dc1:a70:5ee3:732a]) by BYAPR05MB5654.namprd05.prod.outlook.com ([fe80::2dc1:a70:5ee3:732a%5]) with mapi id 15.20.4373.021; Tue, 3 Aug 2021 19:46:16 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Pengshuping (Peng Shuping)'" <pengshuping@huawei.com>, "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: AdeFhlHdOXqXK2QrR7WWz8wtWTj6JwABQvUQAFMLx9AADl6DgABgIbhw
Date: Tue, 03 Aug 2021 19:46:16 +0000
Message-ID: <BYAPR05MB5654494094019089406C8802D4F09@BYAPR05MB5654.namprd05.prod.outlook.com>
References: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com> <670325ac29f94e7d87374425f5ec4793@huawei.com> <BL0PR05MB56526F66F011E66BD3B9FE5ED4EE9@BL0PR05MB5652.namprd05.prod.outlook.com> <10e001d78711$07e30030$17a90090$@olddog.co.uk>
In-Reply-To: <10e001d78711$07e30030$17a90090$@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=17c32340-7372-4d06-9df1-8df29e0eff6b; 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-08-03T18:01:16Z; 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: 8c63e8af-43a3-4f17-e60f-08d956b75b76
x-ms-traffictypediagnostic: BY3PR05MB7954:
x-microsoft-antispam-prvs: <BY3PR05MB7954A979817E9E2056AEE80BD4F09@BY3PR05MB7954.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: MU6hVstzR7Gm5Enlc2FH5Kuv+mOoIj/dSIWNxUtGVTwNUqiGR2Y1V04NPoQetoJBCf9l9BY0zzltCDVW86O8ZjQse60TOL3yWPvXh5b8sb6r8mwRYPK6tHfUajhzJ8oe3szN7cPi0ho9JxP2LaTdZADQHy1PLkhtGN9ESx5nknzW4PuECxP6oB+ofMX3rORGbIqHtjus4FwUJA/383+6Br6VCgNVx4yjKnw+ln3FNB8CsYIAgpap0zqmLijKqLH6vdctMogA6XyJriySMxKu9+q9L9+ru0XuKwCwgFvO38HNlnKh7CqHA9qrlW6pqYw9lvcJkztmv8MXCvQ2yNJQ2wLSCTj3I4237aXAx8XSGvYQR95oA0nYJPhF+G6i4XV7hXILWhIvttShWP+ozWQykjOAVN6untNweQXFiUCiQsBoafShTIE6yQCrgz4nN5m1BBN5iWZGGs0Wf1J9XLPdBV7zk3NNst9B1cUq2chqYUK0sy3kJLxnoYGDt699qA7xFQXsjmGqF2mv7q/MHxhaRN+ANcWelopvWU1cCLEWGfwGbiR708BbzlX6STYw1hSdYzTemmr4r0rLNFl84sOGttRNv/H324aSczvPLDqbZHfvac4Bdr9BSEpJ4E2+rU5h4t56eaW8RIk1j/PubCEcUGbzSlJ85hERK7OLQnZTnqdNMMHp/GrkWbi+dxygTju2ZnsP92B66rnx9zTXwXtXSXXOJhYKUJ46HFJZUaGIbEOXWCgIBvDS9YO+/KAc1Cjr3fnNL2F/jbJNzH7wQiihTF971R93ReRM/MVuTlKRHrLbOUJaV2NppXUXZwuOxfEb5XV/Oj+PPkiW4BGEJQplQglgnlQKMv3ESBFjuCk2FVs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB5654.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(346002)(136003)(376002)(5660300002)(166002)(122000001)(52536014)(966005)(316002)(7696005)(9326002)(55016002)(478600001)(66946007)(38070700005)(66476007)(66556008)(76116006)(38100700002)(64756008)(66446008)(30864003)(186003)(86362001)(26005)(8676002)(9686003)(110136005)(71200400001)(8936002)(6506007)(53546011)(83380400001)(33656002)(4326008)(2906002)(21314003)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: t/270xdkO4WaPWG7utEtCU5ESsCNT5AiQfs2daVncLjdErzuH5Nf11GeEoiveARJgOP8LRg1lZIU8puzXkTwXrum2B6NZ1ZHGcBznhtA17Ehpaa4nfXEuf+FU/KuX/KLFxGyVAjfqNTFikRgkRdAgD3RDLK3aTM5Q1LTnBszD7YXqpOixdWDora2EXeh/L/fX1pUq7UB58g1lwji3xwx0+QcN5MAjAii3iil7ZixyjMgph4Fn5apMFX4hIWd2JwtHHgvJD6iGVDefLQS2L1bxhaJGCBeZ+nwJsfX1dVt53zB79B07RegqRzKMl+dg9o+rpTvWOkBAqoDOftKyUz9OQgqnsBaLFrKBvBSk+dwfmIH2DUIMXh4vMRfxiA/JaZeWIXXDXU2zAPavehqI3ykPKyroEXbvyKHaaa6SS4sQBcEaFmj465Cw3A9gaEWt691P3IlOXCmXYXU++M2NL9dAOBc1NgzYPy1CMkJbY4RBYuROGC71tCCxxAvtOv8IEyQzhdGTXjCqfGoTvxHnJhrMmRcnwXAAajI0QCbDtU4hEU5FTZ5ojTdcOWXdWvPQ0b42tLFieJNw5l1r1PMIXkxUKc38QnzPDv0yVwuoeH8hz9Lf2VFjBWcTvjfOBmU2ENqO9FUyabz59RIhEXZb7j4P+ahZyyJ4FTQvqGj8bZ9RooKVVTkh+bQaSt8tGKD0hQmeQwMN8saadiExqmOrmZU0AGFYhWxEohe0BbngMKWhpqqQrX1NsRFuWdQRUCcf9c2LI9V7sGsUkYUEipOj7xMbQlo+pSSTdE0jWfH5kDQnv5BWbX+v8+7tkQpHQTQCSGo5IlaUrM8pq9UjDp73XD/+CtXkp6KyovfeLrbiEb1Gzh0Diy2pUAP/GeBZHWqQq8HA8lX0H3oHd6PR+jpluG4WO8Px1o+p+LUN2KlrzhAzqGFl17imUoIaSW5ry35fLMnOXIKAz9GUR2mSvWEPWX1VG0qteTYANHwOYMt3z3xTv3P5bmwEXQ7DvqwkLAzda7p4837AcnyLx2zy4bst3uqUQLLTQ8R6n/oozZdjTiC1ifOItf4ulj3ZOdl9Gw1hmfQiAFZyNZcU67dCNtCcdbFFRywFLhKgj/z6XzVFGEyOq8uXmuJYRdUcpE46jYguwV7G3WgpxBwTBaRa10jpfSvjo9yY59U0N4KmN1Gim+1RGtXA7vweCRla/0pUrm5soOGLJyOZcm7YGvrJDqQER53neMgRJOteHWByIdKWpXvaz9VaW0zWYMmfRQLrYuhy7PviLqCLumMStYwl7BrKypwSh/8olCYQlfZkV6VJpTvxVx3o1zfnfpl4MR8D0YhEfzE
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB5654494094019089406C8802D4F09BYAPR05MB5654namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB5654.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c63e8af-43a3-4f17-e60f-08d956b75b76
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 19:46:16.1929 (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: tOpP7QlGVzO6eSmT+j2cMHjm0l1cHPSwnH6bBMkDPYX165XBJUQqraDoauxg0xLtnerWsC0IvJBjmZmlj5fXlw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR05MB7954
X-Proofpoint-ORIG-GUID: Yup78NlUeHpEx2ItxCcnqw8VkvhaR-um
X-Proofpoint-GUID: Yup78NlUeHpEx2ItxCcnqw8VkvhaR-um
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-03_05:2021-08-03, 2021-08-03 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 adultscore=0 clxscore=1015 impostorscore=0 phishscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108030124
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/-FWaKbEFOliEnzVULiAt5OFAuUo>
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: Tue, 03 Aug 2021 19:46:34 -0000

Hi Adrian,

Please see zzh> below.

From: Adrian Farrel <adrian@olddog.co.uk>
Sent: Sunday, August 1, 2021 4:09 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; 'Pengshuping (Peng Shuping)' <pengshuping@huawei.com>; james.n.guichard@futurewei.com
Cc: apn@ietf.org
Subject: RE: [Apn] APN vs. Network Slicing

[External Email. Be cautious of content]

Pardon me for jumping in.

Here is what I think I have observed that shows similarity and difference between network slicing and APN.

In network slicing, network resources are partitioned to “guarantee” a specific level of service. Customer traffic that is to receive that service from the network is classified onto that network slice. Quite how the network distinguishes that the traffic belongs to the slice is dependent on the network data plane, but almost certainly requires the traffic to be marked in a way that identifies it with the slice. For example, in an MPLS-TE network, the traffic might be placed onto an LSP that belongs to the slice so that transit nodes will associate the incoming {interface, label} with the slice and its reserved resources. In this sense, classification happens at the edge of the network, and there is a clear separation of behaviors in the network based on the “slice identifier.”

In APN, customer traffic is also classified at the edge of the network, and is marked with an APN attribute that indicates the behavior that is desired within the network. I don’t believe that marking the traffic with an APN attribute is a guarantee of a service level (in my understanding of the APN docs), but it is a request that network nodes behave according to certain policies. And different nodes could be configured to behave differently: node A might be configured to treat APN attributes 1 and 3 the same, but to treat 2 differently, while node B might treat 2 and 3 the same, but 1 differently.

Zzh> https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-04#section-4 says:

   2.  Application-aware information and network service provisioning
       matching providing fine-granularity network service provisioning
       (traffic operations) and SLA guarantee based on the APN attribute
       carried in APN packets.  According to the APN attribute,
       appropriate network services are selected, provisioned, and
       provided to the demanding applications to satisfy their service
       requirements.
Zzh> I read SLA guarantee and service requirement satisfaction in the above text 😊                                                              .
Zzh> To achieve SLA guarantee we need two things: a) traffic marking 2) resource provisioning. Network slicing provides both of them, and slice aggregate concept in draft-bestbar brings that to sub-slice level (flows or flow aggregates).

Zzh> I don’t think network slicing (plus the slice aggregate in draft-bestbar) excludes that “different nodes could be configured to behave differently”. Once the traffic is marked properly, how a node treats the traffic is up to the corresponding forwarding state on that node and network slicing certainly does not preclude certain nodes from having additional forwarding behavior.
Zzh> I also assume that the key purpose of APN is not to apply different behavior on different nodes. It is orthogonal – W/ or w/o APN or slicing, different nodes can apply different behavior.
Zzh> Per APN problem statement draft:

       According to the APN attribute,

       appropriate network services are selected, provisioned, and

       provided to the demanding applications to satisfy their service

       requirements.
Zzh> To me that matches the slicing well:

   Term "Slice" refers to a set of characteristics and behaviours that

   separate one type of user-traffic from another.


At the same time, the proposal seems to be that the APN attribute *can* be treated like an opaque number (making it look like a slice identifier), but it is constructed by setting subfields (yet to be defined) so that transit nodes may determine common actions on a set of APN attributes that all have the same setting of one of the subfields.

Zzh> Defining subfields and forwarding based on subfields makes forwarding more complicated, and makes it harder to introduce changes. What if a new subfield is needed after ASIC has already been spun?
Zzh> In the early days of BIER design, it was insisted that the forwarding only uses an opaque number as the forwarding table ID to determine which BIER forwarding table to use, instead of parsing the ID as a <subdomain-id, bit-string-length, setid> tuple. That proved to be an excellent design choice.

Furthermore, I think that network slicing is intended to apply to all on-path links and nodes, while APN can be limited to “key” points in the network that need to apply “policy.”

Thus, APN is closed to “DiffServ on steroids” while network slicing is closer to “virtual TE networks”. But, if you wanted to stretch the definitions to their absolute limits, you *might* call APN “soft slicing”. I don’t think I would like to go that far.

Zzh> For *SLA guarantee* that APN sets out to do, I suppose we’d want to apply forwarding behavior to all on-path links and nodes, unless the purpose is not SLA guarantee but just ‘limited to “key” points in the network that need to apply “policy”’. Even in the latter case, it can be considered as a “default/best-effort slice” with certain nodes provisioned with additional forwarding state to apply different “policy” based on the traffic identifier, which can be down to sub-slice (flow or flow aggregate) level as specified in the draft-bestbar documents.

However, I would observe that the APN attribute (if it existed) could be used as a slice identifier, while a slice identifier probably can’t do all the things that APN sets out to do.

Zzh> The slice aggregate identifier (in draft-bestbar, which is built on top of network slicing) can do anything that APN sets out to do in my opinion 😊
Zzh> Thanks.
Zzh> Jeffrey

Best,
Adrian

From: Apn <apn-bounces@ietf.org<mailto:apn-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 01 August 2021 14:19
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com<mailto:pengshuping@huawei.com>>; james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>
Cc: apn@ietf.org<mailto:apn@ietf.org>
Subject: Re: [Apn] APN vs. Network Slicing

Hi Shuping,

Can you confirm if the purpose of APN is to mark traffic and achieve traffic/service differentiation at fine granularity levels?

Jeffrey

From: Pengshuping (Peng Shuping) <pengshuping@huawei.com<mailto:pengshuping@huawei.com>>
Sent: Friday, July 30, 2021 5:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>
Cc: apn@ietf.org<mailto:apn@ietf.org>
Subject: RE: APN vs. Network Slicing

[External Email. Be cautious of content]

Sorry to Jim that I jumped in.

Hi Jeffrey,

You have been explaining about what network slicing can do or does. But that is really up to the network slicing people to figure out. There have been several years for people to clarify the concept and consolidate the various terminologies even now. Here we only talk about APN.

APN and network slicing are two things. They don’t have to have any relationships, and they do not conflict each other.

The only connection is that APN provides a way to steer some traffic into a particular network slicing based on an operator’s control and its customer’s consent.

Thank you!

Best regards,
Shuping



From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Saturday, July 31, 2021 5:28 AM
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!RZR3mujfa7CCp7jmAHOTCi_ZXcyrnydLZ7RvaRrrlVukirIaMTJXMMadmHNKhBhW$>。

·        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


Juniper Business Use Only