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

Adrian Farrel <adrian@olddog.co.uk> Fri, 25 March 2022 21:21 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 C94843A0E17 for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 14:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, URIBL_BLOCKED=0.001] 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 T8IBlwz43q2x for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 14:21:50 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 4BA523A0DBC for <teas@ietf.org>; Fri, 25 Mar 2022 14:21:48 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 22PLLjtf011850; Fri, 25 Mar 2022 21:21:45 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E8BC94604B; Fri, 25 Mar 2022 21:21:44 +0000 (GMT)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C96EE4604A; Fri, 25 Mar 2022 21:21:44 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Fri, 25 Mar 2022 21:21:44 +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 22PLLexp022319 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Mar 2022 21:21:42 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Krzysztof Szarkowicz' <kszarkowicz@gmail.com>
Cc: teas@ietf.org
References: <042601d84029$1de567c0$59b03740$@olddog.co.uk> <c4e7e5c0-81a2-7f62-c81a-8f672eccd6db@joelhalpern.com> <DB9PR06MB7915CE12BC9DE1E9F62309E29E1A9@DB9PR06MB7915.eurprd06.prod.outlook.com> <CAO8-O7pm7aznKmt--2Dfgtf=ZZ=o2xtjjRoLLOVMLpG6KP8_pw@mail.gmail.com> <9191AF9E-6FA7-43AF-B4DC-55F0B046BDAB@gmail.com>
In-Reply-To: <9191AF9E-6FA7-43AF-B4DC-55F0B046BDAB@gmail.com>
Date: Fri, 25 Mar 2022 21:21:41 -0000
Organization: Old Dog Consulting
Message-ID: <04e801d8408e$52fa51e0$f8eef5a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E9_01D8408E.52FBB170"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGMjY5VTWOMcsZjjA1SIhZULhkGXwH58ZlBAfGS5rABsFweYQKD6ricrScA36A=
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-26794.003
X-TM-AS-Result: No--35.686-10.0-31-10
X-imss-scan-details: No--35.686-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26794.003
X-TMASE-Result: 10--35.685800-10.000000
X-TMASE-MatchedRID: hFbMlnd2lLPTiKBY2Cp18MFKu3c5/ibm36lQXQeyPFFvk3JiXDj4dVc/ CedjlcvktZDLKHqpwOTZjFS7CzHn3T+iwfujAMkE6NmVjMtuA1+VOwZbcOalS05G9dUWO16XQmw 1cPfvj6lJTLfhtwUcm03NN5PJtwSRhFaopvPuWQ0/GrdA3dUAXhIRh9wkXSlFpWOBfK9L1z+dB8 R9Oxb02/s/SHqll+53H02q2zSwoZJXZr7E3iPCCfJW6Mbl18qzMGAKZueP0mau2GmdldmiUMiCh 8yBqE+tCPqJoWYmpskaMKZ6Kdx++jz7CR6gqRKeY3q3LBCbBAyuYt4ytygzqLb45+VjZiMpr7XG VRMWmGAJkHQ4Dua9f1BqtcOwjvXHkzWsfJLmgJen9EJj6muJHvi9hrAKwILa70GLyvzOg0wkK/7 5aoBPvOtMphi/TN0Y6ueHB2yZginuWdG1/goUDOpObv5mX+kV0e7jfBjhB8dSHjB5Y+o5ZJxi3Y 4kqpOA35ZjGsBF6jLTIvxsPLepwEmBDb28pkt7FEqfmzoXvEsK3Ma88LL+bgT2OEnoCt48NxVS3 Rxgrm7xhuT2TM8RaO9FZUbZUmFAwjcqw3hE1+SzMJ0yoJG7DmzvIi8LanAawbuK0Zbt5tgSDCgG oCJiFNYVOWTdWqtobC4QMmU3GMOSk+lLxMnfFEgdsc9PDi3SZ06bPxu5Vxz9ovU6rKSvKr3CaqQ E3sNvdvAflyNG9pc5XxTGE2ATEvAm4S+8rVHd4vICKih8njdWvtA7KyEjvyiisLSFmwm29VwD5x +5UHORREhAtdMCNTX8BRE0mc5J+CZ36eSLJV0M8jMXjBF+sBRFJJyf5BJeWQy9YC5qGvzmKuxMX tACKPu9poc8/gtLU6baA36eiawgbhiVsIMQK2u5XqFPzjIT8jF0kHc8YvQ=
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/jRs-mfV9kc5OHLwGORdVTMOVbuw>
Subject: Re: [Teas] [E] Re: 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 21:21:58 -0000

Hi Krzysztof,

 

I think you might have something here, but it is confused by a side point.

 

“might be entire network is single partition” is not a contradiction with “partitioning the network resources.” True, it is at the extreme end of the spectrum, but one is a special case of many.

 

Now, the BIG question for network slicing is whether the network resources are partitioned at all. If they are counted in any way (including in a central controller) in order to ensure that the traffic can meet the SLOs, then the resources *are* partitioned. It is only if the service delivery is best effort, allowing for congestion and drops, that we can say that the resources are not partitioned.

 

Or, in another view, if traffic for a particular service is steered onto particular links in order to meet SLOs (for example, latency), then the resources have been partitioned.

 

So, while I agree that partitioning is strongly tied to realization, I wonder whether it is possible to have a network slice (note “slice”, not “slice service”) without it.

 

My concern is that we end up with a definition of network slice that is so far removed from realization that it becomes “a slice is what an operator does to their network to deliver a slice service” which, I think, doesn’t tell us what a slice is.

 

Cheers,

Adrian

 

From: Krzysztof Szarkowicz <kszarkowicz@gmail.com> 
Sent: 25 March 2022 17:57
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: teas@ietf.org
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

Hi,

 

I have only one comment, regarding below:

 

  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).

 

‘Achieved by partitioning network resources’ is some specific relation option, which might (or might not) be used in particular realization (depending how the slice is realized, might be entire network is single partition). Hence, it should rather be omitted here, as it should be agnostic to to the actual realization. Thus, I would change it to:

 

  the "IETF Network
  Slice" which is the realization of the service in the provider's 
  network achieved by
  applying certain tools and techniques within the network (see
  Section 3.1).









Regards,

Krzysztof









On 2022 -Mar-25, at 12:48, Jalil, Luay <luay.jalil=40verizon.com@dmarc.ietf.org <mailto:luay.jalil=40verizon.com@dmarc.ietf.org> > wrote:

 

+1


 

Regards,

Luay

 

 

On Fri, Mar 25, 2022 at 10:49 AM LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com <mailto:luismiguel.contrerasmurillo@telefonica.com> > wrote:

Hi all,

Agree, the proposed change is ok.

Best regards

Luis

-----Mensaje original-----
De: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > En nombre de Joel M. Halpern
Enviado el: viernes, 25 de marzo de 2022 10:30
Para: teas@ietf.org <mailto:teas@ietf.org> 
Asunto: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

Works for me.
Yours,
Joel

On 3/25/2022 5:17 AM, Adrian Farrel wrote:
> 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
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org <mailto:Teas@ietf.org> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=> &d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= 

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=> &d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= 

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=> &d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= 

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas