[Teas] Slicing Framework Open issue #1 : Service != Realization

Adrian Farrel <adrian@olddog.co.uk> Fri, 25 March 2022 09:17 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11E13A115F for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 02:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 tVwTHkxy5tpl for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 02:17:18 -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 4A49E3A115D for <teas@ietf.org>; Fri, 25 Mar 2022 02:17:17 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 22P9HFcw005430 for <teas@ietf.org>; Fri, 25 Mar 2022 09:17:15 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1DD464604E for <teas@ietf.org>; Fri, 25 Mar 2022 09:17:15 +0000 (GMT)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 121054604C for <teas@ietf.org>; Fri, 25 Mar 2022 09:17:15 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS for <teas@ietf.org>; Fri, 25 Mar 2022 09:17:15 +0000 (GMT)
Received: from LAPTOPK7AS653V ([148.252.128.109]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 22P9HDZM031012 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <teas@ietf.org>; Fri, 25 Mar 2022 09:17:14 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: teas@ietf.org
Date: Fri, 25 Mar 2022 09:17:13 -0000
Organization: Old Dog Consulting
Message-ID: <042601d84029$1de567c0$59b03740$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdhAJerwmP8JgaoPSZm5TdQgGwLtRQ==
Content-Language: en-gb
X-Originating-IP: 148.252.128.109
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26792.007
X-TM-AS-Result: No--11.996-10.0-31-10
X-imss-scan-details: No--11.996-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26792.007
X-TMASE-Result: 10--11.995700-10.000000
X-TMASE-MatchedRID: vWLMKRYJCzfBSrt3Of4m5jjNGpWCIvfTStGAgmKqWuXfKapXkCLRBbLj eg9NVTVHywMD+nV5RTibXQjWRJW3BMTN6iYzdTAmGqSG/c50XgNJhFbLz9U+omKfg4NxoyGwL5G UqlMnxV7j+Uz8P13WE31ScCGCekICsULgoWXJHpdwKlYjOzXY1aIazKtJxIUHxcmlumBXuhE5Qk a/B296oo26FAtqVTcf2/XQirw1AlYU31ZVVsVkQW03YawHJvPCE3Ba/Z0GuaQ3FVLdHGCubrTLc NrcH2Gr4vM1YF6AJbZcLc3sLtjOt9CpCFLDTHZU3QfwsVk0UbtuRXh7bFKB7nDTM6u3JAd7a2QM HPZf2bJbPytLNhe6XhKanVFxRuzHlExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/WheO1iVcLcw8uzD5JNi4mRDgbhA>
Subject: [Teas] Slicing Framework Open issue #1 : Service != Realization
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: Fri, 25 Mar 2022 09:17:21 -0000

Hi,

First in a series of emails to resolve the open issues mentioned during the
TEAS meeting.

We have, for the longest time, suffered from a blurring between the service
provided to the customer, and how that service is engineered in the network.
This leads us to talk about VPNs in a way where sometimes a VPN is what the
customer gets and sometimes it is what the operator engineers. A good
example is the term "MPLS VPN" as though the customer cares whether the VPN
is provided using MPLS technology.

We have, to some extent, clarifies this with recent YANG "Customer Service
Models" that describe the service offered to the customer, but do not
constrain the provider's choice of implementation technology or options.

As the discussion of IETF Network Slices continues, I have repeatedly seen
some blurring between the topics of the "IETF Network Slice Service" and the
"IETF Network Slice." It seems to me that this mixing of concepts will
continue as future readers pick up the document.

Although I have tried to use the two terms clearly and distinctly, the
document is missing a clear statement to disambiguate the two.

Section 3 provides the definitions of the two terms at some length using
subsections. The clarification would get lost if it was placed at the bottom
of the section after the subsections, so I propose to include some text near
the top of section as follows.

OLD
   IETF Network Slices are created to meet specific requirements,
   typically expressed as bandwidth, latency, latency variation, and
   other desired or required characteristics.  Creation of an IETF
   Network Slice is initiated by a management system or other
   application used to specify network-related conditions for particular
   traffic flows in response to an actual or logical IETF Network Slice
   service request.

   Once created, these slices can be monitored, modified, deleted, and
   otherwise managed.

   Applications and components will be able to use these IETF Network
   Slices to move packets between the specified end-points of the
   service in accordance with specified characteristics.
NEW
   IETF Network Slices are created to meet specific requirements,
   typically expressed as bandwidth, latency, latency variation, and
   other desired or required characteristics.  Creation of an IETF
   Network Slice is initiated by a management system or other
   application used to specify network-related conditions for particular
   traffic flows in response to an actual or logical IETF Network Slice
   service request.

   Once created, these slices can be monitored, modified, deleted, and
   otherwise managed.

   Applications and components will be able to use these IETF Network
   Slices to move packets between the specified end-points of the
   service in accordance with specified characteristics.

   A clear distinction should be made between the "IETF Network
   Slice service" which is the function delivered to the customer
   (see Section 3.2) and which is agnostic to the technologies and
   Mechanisms used by the service provider, and the "IETF Network
   Slice" which is the realization of the service in the provider's 
   network achieved by partitioning network resources and by
   applying certain tools and techniques within the network (see
   Section 3.1).
END

Any objections?

Thanks,
Adrian