Re: [Apn] APN vs. Network Slicing

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Fri, 30 July 2021 21:48 UTC

Return-Path: <pengshuping@huawei.com>
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 8ED023A1230 for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 14:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 ZvE1Pp0OU5As for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 14:48:15 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B8C3A1239 for <apn@ietf.org>; Fri, 30 Jul 2021 14:48:14 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gc0xP3ZcSz6B9wS for <apn@ietf.org>; Sat, 31 Jul 2021 05:32:57 +0800 (CST)
Received: from dggeml708-chm.china.huawei.com (10.3.17.138) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 30 Jul 2021 23:48:10 +0200
Received: from dggeml757-chm.china.huawei.com (10.1.199.137) by dggeml708-chm.china.huawei.com (10.3.17.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 31 Jul 2021 05:48:07 +0800
Received: from dggeml757-chm.china.huawei.com ([10.1.199.137]) by dggeml757-chm.china.huawei.com ([10.1.199.137]) with mapi id 15.01.2176.012; Sat, 31 Jul 2021 05:48:07 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, "james.n.guichard@futurewei.com" <james.n.guichard@futurewei.com>
CC: "apn@ietf.org" <apn@ietf.org>
Thread-Topic: APN vs. Network Slicing
Thread-Index: AdeFhlHdOXqXK2QrR7WWz8wtWTj6JwABQvUQ
Date: Fri, 30 Jul 2021 21:48:07 +0000
Message-ID: <670325ac29f94e7d87374425f5ec4793@huawei.com>
References: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.178.104]
Content-Type: multipart/alternative; boundary="_000_670325ac29f94e7d87374425f5ec4793huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/A3HPeQMnchdsBTILp9_1mjVgUlo>
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: Fri, 30 Jul 2021 21:48:20 -0000

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
Cc: 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。

・        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