[Teas] My unasked question about the draft-bestbar-teas-ns-packet and draft-bestbar-teas-yang-slice-policy

Adrian Farrel <adrian@olddog.co.uk> Thu, 11 March 2021 15:37 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F27A53A1137 for <teas@ietfa.amsl.com>; Thu, 11 Mar 2021 07:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yIvkyXZ0Id-i for <teas@ietfa.amsl.com>; Thu, 11 Mar 2021 07:37:04 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com []) (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 0D3173A1133 for <teas@ietf.org>; Thu, 11 Mar 2021 07:37:03 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com []) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12BFb1Sc030010 for <teas@ietf.org>; Thu, 11 Mar 2021 15:37:01 GMT
Received: from vs2.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id DF23322044 for <teas@ietf.org>; Thu, 11 Mar 2021 15:37:00 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown []) by vs2.iomartmail.com (Postfix) with ESMTPS id C9A8322042 for <teas@ietf.org>; Thu, 11 Mar 2021 15:37:00 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12BFax66028761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <teas@ietf.org>; Thu, 11 Mar 2021 15:37:00 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'TEAS WG'" <teas@ietf.org>
Date: Thu, 11 Mar 2021 15:36:58 -0000
Organization: Old Dog Consulting
Message-ID: <0ca501d7168c$606e8fd0$214baf70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdcVB58HWubjcGxhTsWqndnrRGar8g==
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--8.938-10.0-31-10
X-imss-scan-details: No--8.938-10.0-31-10
X-TMASE-Result: 10--8.938300-10.000000
X-TMASE-MatchedRID: 3ZJLvrbYyxUOwAmmWH5kBI61Z+HJnvsOUFxKv+2AmMi/md2adk3dROdW 6N3LV/tmfnG27O5PVDQTKXmbVigk9HChPHB61wQjBeUpwRyLLvpjUuryRZbokfwNtclzTGDIJvo TrW/eYFwhbNuegu05G1+JRdGEiDpqR/w2dHgjPqg8TeSGZW8c7lJAsn89ih945lhx0mBJyPH7a1 KnOWPxPOUUL3uDxBQ4K5fooU31KgvF2WYblKxSjI9Ha73XaFhEfYrr1p9yfCo/gf7afIrQU3IwE CVgOaniZm6Xkatf2b56IYowwHv4FJ9vFrcDXJOnOM7ns3UgBY0iyyRgkoGSpLEtLGRAe3PGO0ec CT8g0u34rCGN8vNhVpelUWAik43b4bZMiAdKSnfo5fsYXP0fUEHYlxxUTd1+GP0M/F8V3KiK/oD w/+m2+RCbUssOfrQXA5xjj4z4y50yMDewe9lsFfIq3+8DQd0oQZpQRfyCdHyqWABsnbuBdTe5+T JUtSXt++qMujDziQ0Jszn4XXyiSbfptZTbFVSK5v/KP8n9hBzOoAXTAVKONee9s1hdw41BOXB2c qV0mCJANPw79fYF9401gvO0ZYZ2E1ZZbRf/HMxKzOvae5Q0rJLDsNMGuK9EmyiLZetSf8mNwWY+ KmOUGwzKt8/2P4LV33fj+sMArfMaMUyeC0staJKu380IjvUb/MQ8HQqT1pMg71aHxtxDUuSPVHC nFIutF6R+SbPRHR0tsAlT54TyKg==
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/teas/dyWgcunt7HglmMpSsoNH6vTud50>
Subject: [Teas] My unasked question about the draft-bestbar-teas-ns-packet and draft-bestbar-teas-yang-slice-policy
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 15:37:07 -0000


Thanks to Tarek for the presentation.

It is something special about network slicing that makes us all struggle with terminology. I wonder why that it.

Having gone through the slides and your drafts, I think one of the problems with the terminology is that one term "network slice policy" is trying to achieve too much. (I think John Drake would mutter about floor wax and desert topping 😊)

AFAIC, the policy serves at least the following purposes:

1. Provide a set of mapping rules that allow an edge router to determine to which slice aggregate a packet should be assigned. 

2. Provide a mechanism to map an aggregate onto a set of network resources 

3. Provide a set of network configuration instructions that program the network elements to provide the topology and resources to support the slice aggregate.

At the same time, the term "slice aggregate" is starting to serve multiple purposes:

A. It is the collection of packets (i.e., aggregate flow) created by applying the policy to the packets.

B. It is an identifier of the policy that was applied to the packets and can be used in the network when examining a packet.

C. draft-bestbar-teas-yang-slice-policy describes "realizing an aggregate" rather than mapping an aggregate to a topology

I think that 1, 2, and 3 are needed, but I think they are different things. 

a. Yes, we need to describe what traffic is mapped to a slice. And it is fine to call
   the collection of traffic a slice aggregate. This corresponds to the "traffic
   matching criteria" concept in draft-wd-teas-ietf-network-slice-nbi-yang. But it
   is worth noting that in some applications, all traffic from an input (e.g., a port,
   or an AC, or through an NS-AP) will map to the aggregate using the most trivial
   of policies. I think other contexts refer to this process as "packet classification"
   (sometimes "packet filtering") and the collection is quite often known as an
   "aggregate flow".

b. Yes, we need to say "once you have sifted the packets to make a slice aggregate,
   what do you do with the packets?" In an MPLS-TE world (just mentioning this
   to give context, not to say you have to use MPLS-TE) this would be the LSPs to
   use (i.e., the labels to impose and the outbound interface). In an SR world it
   would be the SID stacks to impose.

c. Yes, we need to configure the network to reserve resources and set up paths.
    In fact, we need to build a network slice topology. But since several network
    slices may share resources (not least, in order to get a reasonable amount of
    scaling) we want to build a topology over which one or more slices can be
    carried. However, I think this process is explicitly not part of the steps for a.
    and b. It is a separate thing: and once you look at it like this, you find it is
    "configuration of VTN" using the terminology from the VPN+ documents.

As probably clear from my a., b., c. text, I think that A is a helpful use of the term "slice aggregate". It usefully mirrors terms like "traffic aggregate".

But I don't see value to having the slice aggregate known within the network (B). What seems to be needed is an identifier of the resources and paths to which a packet should be applied. This is a slice identifier, but for scalability purposes what we really want is an identifier of the resources to use - that’s an aggregate of aggregates (!) and is the concept that draft-ief-teas-enhanced-vpn calls a VTN.

Finally, in his presentation, I am sure that Tarek talked about mapping an aggregate to a topology. But draft-bestbar-teas-yang-slice-policy is pretty clear that it is describing "realizing an aggregate" (C). I think that what is needed is step back a bit and sort out the functional steps. That will give us access to the terminology, and then we can settle into the real technical work. (I use the term "VTN" below to mean "the resources and topology assigned to support one or more network slice").

Consumer wants a slice
Consumer specifies slice characteristics to operator
Consumer specifies what traffic will be carried on the slice (the policy or matching criteria that defines the aggregate)
Consumer may add further descriptions of traffic (policy to aggregate is n:1)
Other consumer end points may define traffic to be carried on the same slice (aggregate to slice is n:1)
Operator looks for how to support the slice
Operator builds or nominates existing VTN to carry slice
Operator may host multiple slices on one VTN (slice to VTN is n:1)
Within the operator's network the devices need to know which resources to apply to a packet (VTN-ID)

Note that this leaves us with THREE concepts of aggregation:

i. Traffic is aggregated into a slice aggregate (as per flow aggregation)
ii. Slices are aggregated onto topologies (as per service aggregation)
iii. Resources are aggregated into topologies (as per abstraction)