Re: [Apn] APN vs. Network Slicing

Adrian Farrel <adrian@olddog.co.uk> Sun, 01 August 2021 20:09 UTC

Return-Path: <adrian@olddog.co.uk>
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 D2A4F3A0C92 for <apn@ietfa.amsl.com>; Sun, 1 Aug 2021 13:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 aYxcz39iezlT for <apn@ietfa.amsl.com>; Sun, 1 Aug 2021 13:09:03 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 AC2333A0C94 for <apn@ietf.org>; Sun, 1 Aug 2021 13:09:02 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 171K8i0w005800; Sun, 1 Aug 2021 21:08:45 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 87E6D46048; Sun, 1 Aug 2021 21:08:44 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 716104604C; Sun, 1 Aug 2021 21:08:44 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Sun, 1 Aug 2021 21:08:44 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.101.57]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 171K8hRU006308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Aug 2021 21:08:43 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Jeffrey (Zhaohui) Zhang'" <zzhang=40juniper.net@dmarc.ietf.org>, "'Pengshuping (Peng Shuping)'" <pengshuping@huawei.com>, james.n.guichard@futurewei.com
Cc: apn@ietf.org
References: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com> <670325ac29f94e7d87374425f5ec4793@huawei.com> <BL0PR05MB56526F66F011E66BD3B9FE5ED4EE9@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB56526F66F011E66BD3B9FE5ED4EE9@BL0PR05MB5652.namprd05.prod.outlook.com>
Date: Sun, 01 Aug 2021 21:08:43 +0100
Organization: Old Dog Consulting
Message-ID: <10e001d78711$07e30030$17a90090$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_10E1_01D78719.69A9D930"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFjpbQvXVADVsvLi9Fypqo7nD7ZPgFPn+x9AhvWazKsK3cIIA==
Content-Language: en-gb
X-Originating-IP: 84.93.101.57
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26320.002
X-TM-AS-Result: No--8.504-10.0-31-10
X-imss-scan-details: No--8.504-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26320.002
X-TMASE-Result: 10--8.503700-10.000000
X-TMASE-MatchedRID: vZFhdP8fGRcQo9nihO6svt0NLp60dt7bzZMDCRmqUwI4Rix2x/ljVbE3 hzfuhkzMyeUl7aCTy8g/gf7afIrQU1EtMRGFGDWD/3dN/c325os+nprjbuUrtdjNYZs+MYJRgcv vvRSOOOLMMXZKHHYKta76eT5zuvGqTe9gr7g3DKtXEO5lajzejsQ3qkC9R1pr5A0BSZfHoFCeuw QMMC+SOk+crEA4+nhZRjNrjV0arFIpgo47E3HBRVlHIFvwdkgr4MRWJy08ovpmrktqocg8VIX1R isRZVH+bsFLINmYCfGPpeH2TUh47schTIzmFDXymOtJGe98ZG4/cNHzL7EUZEBwE2OmutyKc7uq 4k7WFKMQOcMSo0926mNDqjXOO0YeyEDFMuE6HqjGh3hpryhDH2N2X39+HAiSKdS81iZ0/jCEv01 fZOqaQKSkvFW9WG2dROqr1drjnLnCq8vfMsbWbLcRsezeFEsoUXySyMsW1XF9QcxfBAGaqJ2qrR zrhHWqt8cKn575yh5igV5T7Tqql34mWBKQ5hAdraMEPNgzj5euIjsupqfiy+fJixReoUHwTPsVR SNcbWPqCtbLr8G6vrXl40gTGJ5p4p0EFMf/XJqo4v1zAQI7MZSttLtHP+zp24qBgp4IrQSIf3m0 sUfx56Gnvnr+szpSB1qmZ2kKOczE8aAlfqGmjpW59SNPcP18NFVUJkUpWvYvAsoAOvsjMszSKGx 9g8xh0r/qCu/cY52PiMW+3YzkgsijF4UeOUZT2MNLxUfsSh+47CL7SG1gkVQeeXZETLPM/sUSFa CjTLzdKRNjzo2IOIblMMKBhOiUP4Xilzdnazzi8zVgXoAltk8mtlbJ8LaHP9xmfnR7MeqLZAVph LW/bcdRT5TQAJnAPonY05FnifomPlhhHsKUAOxN7mPWk5ukK9z3lF4ugb1QqagrLPg8llmp5+Jk hknOxhTWgK+QKwmgV1JVAhLsswdC3g+Rq18+
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/jK-6-kiyHD8G994bmImKUid-mk8>
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: Sun, 01 Aug 2021 20:09:07 -0000

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.



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.



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.



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.



Best,

Adrian



From: Apn <apn-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 01 August 2021 14:19
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>;
james.n.guichard@futurewei.com
Cc: 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>
Sent: Friday, July 30, 2021 5:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>;
james.n.guichard@futurewei.com
Cc: 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf
-teas-ietf-network-slices__;!!NEt6yMaO-gk!RZR3mujfa7CCp7jmAHOTCi_ZXcyrnydLZ7
RvaRrrlVukirIaMTJXMMadmHNKhBhW$>
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



Juniper Business Use Only