[Teas] Proposed text on "IETF Network Slicing Service"

Adrian Farrel <adrian@olddog.co.uk> Mon, 09 August 2021 14:38 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 EB5F13A15B4; Mon, 9 Aug 2021 07:38:24 -0700 (PDT)
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, 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 osjGLRRy3F3D; Mon, 9 Aug 2021 07:38:22 -0700 (PDT)
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 7BBD33A15B1; Mon, 9 Aug 2021 07:38:17 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com []) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 179EcEnj025396; Mon, 9 Aug 2021 15:38:14 +0100
Received: from vs2.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 12FDC46048; Mon, 9 Aug 2021 15:38:14 +0100 (BST)
Received: from vs2.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 067B54604C; Mon, 9 Aug 2021 15:38:14 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown []) by vs2.iomartmail.com (Postfix) with ESMTPS; Mon, 9 Aug 2021 15:38:13 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 179EcCo6001351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Aug 2021 15:38:13 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>
Cc: <draft-ietf-teas-ietf-network-slices@ietf.org>
Date: Mon, 9 Aug 2021 15:38:11 +0100
Organization: Old Dog Consulting
Message-ID: <00a701d78d2c$2ec15aa0$8c440fe0$@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: AdeNK+kXpbVR8XVVTaGPp5l7BRHeQg==
Content-Language: en-gb
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--10.261-10.0-31-10
X-imss-scan-details: No--10.261-10.0-31-10
X-TMASE-Result: 10--10.261500-10.000000
X-TMASE-MatchedRID: c3fCgkcbsMEaf3p8Lo2lejjNGpWCIvfT+PgcXG6KFc7Lkl8e9W70i4IU G7/tZy4daFzkvRLFRVtd/cyqXfP9Lie/9tnqvgnhJIFzyOQ+SbilAfiiC1VA/R5PtKytkw6ucxZ +avxQRTy2qy5PfNsfOmrW5li/Sp8nRFXsL2iM5nXl0qJwf9h/pwHgke2JqaQsXZgp9Jjp/MxRq+ EclQ5UgkJLmUv1xsAUrykTkAyt9XjbioGCngitBOAEAm6C6aBgMsovp/h9OdHxfBgx0TfiLbCdX EEl+OKbXKNCnaiSTQzgg+PddKZuaxp6rGfLEa9icndZTV1f+nw7g2sl0tC6gbXl40gTGJ5pXCwi fyox9vm5+UgmMi+gzyX/8XBW4q8+cIN0FPDfX8h08zy97KsgJkvE+2pLwGbnMacxaAmSlGhzGzw EsI12KLcTsm3NvDOfFHOQutlZTPk3H58FR5tDSPGSfx66m+aMfS0Ip2eEHnzZbJ4w2XXjFrDszp 3K5gqDjoczmuoPCq0KC6Rpt+2Mo2ncPdIEAXRQavjEiNyRr+IazkXdan/2XhOYhamSXfaZ
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/tdVxkrxL8MCrXQF-0rWsGbcTy1M>
Subject: [Teas] Proposed text on "IETF Network Slicing Service"
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: Mon, 09 Aug 2021 14:38:25 -0000


Back in February and April, John Drake led some discussions about the
definition of a Network Slice Service.

I think that that email thread reached a kind of stability on the list, and
it is (as mentioned in San Francisco) time to bring that into

We already have mention of "IETF Network Slice Service" in Section 2.1, but
we don't have a definition. I propose to add a new Section 3.2 based on
John's text as follows. This places it after the definition of "IETF Network
Slice" in 3.1, but before the discussion of "IETF Network Slice System
Characteristics" in Section 4.

I think there may be some debate still open about the use of "SLO" in this
text. John originally had "SLO" but I believe that is wrong because each
sending CE would have multiple SLOs and SLEs associated. I was tempted to
use "SLA" instead, but that term would apply to the whole service. So I
settled for the (cumbersome) "set of SLOs and SLEs".

Note that this text is closely related to the discussion of endpoints. That
is currently found in Section 4.2, but was also the subject of discussion on
the list and will surface as a separate set of proposed changes in an email
to follow.

Any suggestion or discussion is highly welcome.



3.2. IETF Network Slice Service

   A service provider instantiates an IETF network slice service for a
   customer.  The IETF network slice service is specified in terms of a
   set of the customer's endpoints (CEs), a set of connectivity matrices
   (point-to-point (P2P), point-to-multipoint (P2MP), multipoint-to-
   point (MP2P), or multipoint- to-multipoint (MP2MP)) between subsets
   of these CEs, and a set of SLOs and SLEs for each CE sending to each
   connectivity matrix.  I.e., in a given IETF Network Slice Service
   there may be multiple connectivity matrices of the same or different
   type, each connectivity matrix may be between a different subset of
   CEs, and for a given connectivity matrix each sending CE has its own
   set of SLOs and SLEs, and the SLOs and SLEs in each set may be
   different.  It is also the case that a given sending CE may be part
   of multiple connectivity matrices within a single IETF network slice
   service, and the CE may have different SLOs and SLEs for each
   connectivity matrix to which it is sending.  Note that a given
   sending CE's SLOs and SLEs for a given connectivity matrix apply
   between it and each of the receiving CEs for that connectivity

   This approach results in the following possible connectivity

   o  For an MP2MP connectivity matrix with N CEs, each of the N sending
      CEs has its own set of SLOs and SLEs and they may all be

   o  For a P2MP connectivity matrix, there is only one sending CE, and
      there is only one set of SLOs and SLEs.

   o  For an MP2P connectivity matrix with N CEs, there is one receiving
      CE and (N - 1) sending CEs.  Each sending CE has its own set of
      SLOs and SLEs and they may all be different.

   o  For a P2P unidirectional connectivity matrix, there is only one
      sending CE and there is only one set of SLOs and SLEs.

   o  For a P2P bidirectional connectivity matrix, there are two sending
      CEs, there are two sets of SLOs and SLEs which may be different.

   If an IETF network slice service customer wants to have hub and spoke
   connectivity between N CEs in order to control how traffic is
   distributed between its CEs, it requests a set of N - 1 P2P
   unidirectional connectivity matrices, each between a sending CE spoke
   and the hub CE, and a P2MP connectivity matrix between the sending CE
   hub and the spoke CEs.

   It should be noted that per Section 9 of [RFC4364] an IETF network
   slice service customer may actually provide IETF network slice
   services to other customers.  In this case, the underlying IETF
   network slice service provider may be owned and operated by the same
   or a different provider network.

   Section 4.2 provides a description of endpoints in the context of
   IETF network slicing.  For a given IETF network slice service, the
   IETF network slice customer and provider agree, on a per-CE basis
   which end of the attachment circuit provides the service demarcation
   point.  This determines whether the attachment circuit is included in
   the set of SLOs and SLEs for the subject CE.