Re: [Apn] APN vs. Network Slicing

Adrian Farrel <adrian@olddog.co.uk> Fri, 30 July 2021 21:53 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 5ADDB3A1287 for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 14:53:38 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 nPBdYkcV7ker for <apn@ietfa.amsl.com>; Fri, 30 Jul 2021 14:53:34 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 1F4833A128F for <apn@ietf.org>; Fri, 30 Jul 2021 14:53:33 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16ULrSqB024312; Fri, 30 Jul 2021 22:53:28 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C86C74604B; Fri, 30 Jul 2021 22:53:27 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A8E3C4604A; Fri, 30 Jul 2021 22:53:27 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Fri, 30 Jul 2021 22:53:27 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.101.57]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16ULrQla032454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jul 2021 22:53:27 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Jeffrey \(Zhaohui\) Zhang'" <zzhang=40juniper.net@dmarc.ietf.org>, <james.n.guichard@futurewei.com>
Cc: <apn@ietf.org>
References: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652061556F4957DFB5D8981D4EC9@BL0PR05MB5652.namprd05.prod.outlook.com>
Date: Fri, 30 Jul 2021 22:53:25 +0100
Organization: Old Dog Consulting
Message-ID: <0ff501d7858d$53a42bf0$faec83d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FF6_01D78595.B56C1660"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFjpbQvXVADVsvLi9Fypqo7nD7ZPqxDypIg
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-26316.003
X-TM-AS-Result: No--18.567-10.0-31-10
X-imss-scan-details: No--18.567-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26316.003
X-TMASE-Result: 10--18.566900-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGyoI+bK8UPQnFPUrVDm6jtQa2sDHLkQ06pFMAdzAAQJ2at u8sXoswukljRijtjJEsLbRYDr3UkxVIeiyfGop1wbMGKOuLn5FUhWkbP9T5LSFhs8uimgHNCySU Oss+30o4T7Pln7iOYrgvDMt4/Hk5hQzyRL0v+u0CRymwORsCPITPwse8u5JYm8bWOfcShWBRfXN lldkaNHgg669qonRuMdPVRvYpVFQSBvQmOMfFSRsVbb3pjW5MnjkDrBOJwwnT8kFwgcyoo4a3/Q QACgSNfZNUDHbPZ5K1qSaJp0UAgzw5NDi8X6apt0ytzHp3p+JYvKK/+8XMSRPnDbcq6W6rRfFxY B9+L7+Oo6AV0ryI0kXPMNEp1LLpLFehqCq7Lnr/Bjbyj5wYDmpoiESsm3R0saq7Dr1BRCsu0gcB 1l1Fz4X5w5L3gb9ZnFmrI9dNdepdqO5DqQHm2P4Pe0oBVRFzqJuJX9LfoIjgtferJ/d7Ab9/zGG RctSkCAlyeMbL2PK1Y+u3aG0iHZWfsPcYLgGl0DdN6n3Qne5AXAItPb+orBxiwWt7V9LHQVVtYg 9VMBF7RHhrpULhdFMPBJFzUCjAbJYz6ynVcrDCFTLRMAFrHXMnlJe2gk8vIB1qmZ2kKOczE8aAl fqGmjpW59SNPcP18hNZu2HEUUwR9sllsJI2+/MzSKGx9g8xh0r/qCu/cY52PiMW+3YzkgsijF4U eOUZT2MNLxUfsSh+47CL7SG1gkVQeeXZETLPMM71h0SMVl8LnSD2nXEbsTtZTRDrFLD886CFT76 yyBBY22uoEm245fojjTDpHKwYmhzv5Bvz7TemeAiCmPx4NwBaLWfA4qcOB0AUPEgVMzF8CIXrkW OgT/SAHAopEd76vMgBT9PMvcDJa+P+eH/IAAdPudzd6BCpeANmynbDu7QdLYtlThwtVPg==
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/EW-wXrCp3NnH73-O0t7Rec7moRk>
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:53:38 -0000

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.



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



Cheers,

Adrian



From: Apn <apn-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 30 July 2021 22:28
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>
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