Re: [Teas] Network Slicing design team definitions - isolation and resolution

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 26 April 2020 16:38 UTC

Return-Path: <jmh@joelhalpern.com>
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 65E073A0B28 for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 09:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 lXJXgqWN4vDi for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 09:38:42 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 11FAB3A0882 for <teas@ietf.org>; Sun, 26 Apr 2020 09:38:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 499DB96q8Fz6G7rL; Sun, 26 Apr 2020 09:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587919121; bh=HpEt1MlplED5hkIAIYk64Ia3V2O7Wew/skKDvIyUTNU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=geN0I/mXiJVENRNgSztV+hyh4whulpBaVQGIeL7G9ImchtDGyfD4cw92L6yzrEdQa FnXW3zhqWgDoEqGs1BzwX+JNvLe/PwvWbxeE/LpF+RuOTXECoP9ifwEBJ6/NMMdoiv OFugCjSReGeSlB+el5tX0CV4qQBBL/SYaSoJN58Q=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 499DB91L3gz6GDxm; Sun, 26 Apr 2020 09:38:41 -0700 (PDT)
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, "Luis M. Contreras" <contreras.ietf@gmail.com>
Cc: "teas@ietf.org" <teas@ietf.org>
References: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com> <CAE4dcx=1_DT8dn_+B1X+6S-iHsoPsd6TyAJsnEj2iLznjtfAPw@mail.gmail.com> <43dfbb0d-c887-8d07-9200-97f226458b30@joelhalpern.com> <VI1PR0601MB2157472F4ADF5232F16A0A359EAE0@VI1PR0601MB2157.eurprd06.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <8e61c5d2-8072-3496-fd14-701bbc99cad1@joelhalpern.com>
Date: Sun, 26 Apr 2020 12:38:40 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <VI1PR0601MB2157472F4ADF5232F16A0A359EAE0@VI1PR0601MB2157.eurprd06.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/BO7eLFfFYVikQ_SaU9CO74IfDXw>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
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: Sun, 26 Apr 2020 16:38:45 -0000

Those are very reasonable points.  That is not what the document 
currently says.

Yours,
Joel

On 4/26/2020 12:29 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:
> Hi Joel,
> 
> please, see in-line.
> 
> -----Mensaje original-----
> De: Joel M. Halpern <jmh@joelhalpern.com>
> Enviado el: domingo, 26 de abril de 2020 18:11
> Para: Luis M. Contreras <contreras.ietf@gmail.com>
> CC: teas@ietf.org; LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
> Asunto: Re: [Teas] Network Slicing design team definitions - isolation and resolution
> 
> I am sorry, I am not understanding your point.  A mission critical service will have very tight delay, delay variation, and loss parameters.  (Some have high bandwidth requirements, some do not.) If those are met, the mission critical service works.  if they are not met, then it is not.
> [Luis>>] Certainly yes. The point is that the customer (e.g., public safety services like police or so) could require to have guarantees that this happen in whatever circumstance, including exceptional ones such as current COVID-19 issue (with large increments of traffic in general because confinement) or a terrorist attack (where massive people communications could create congestion). Through different degrees of isolation (according to the customer requests) this could be guaranteed even in those situations.
> 
> Whether those are met using diffserv EF, detnet, flex-ethernet, or dedicated fiber and routers is not relevant to the customer.  the operator's technology specific tools then meet those requirements.
> [Luis>>] Correct. This has to do with the realization of the slice, and different options could be used as long as a given technology allows to accomplish the requested service.
> 
> Yours,
> Joel
> 
> On 4/26/2020 7:26 AM, Luis M. Contreras wrote:
>> Hi Joel,
>>
>> one observation respect to: " But isolation of flows in the network is
>> not an external observable, not something a customer can even ask
>> about."
>>
>> It is expected that consumers of slices in the transport, as 5G
>> services, will request isolation. Think for instance on mission
>> critical services (public safety, eHealth, services, etc). In fact
>> isolation is one of the characteristics that can be included in the
>> actual specification of the slice as stipulated in the slice templates
>> considered by 3GPP (and generally defined by the Generic Slice
>> Template structure considered by GSMA).
>>
>> Thus isolation should be considered as potential requirement to be
>> satisfied also in the transport part, as potentially requested by
>> slice customers (as in the case referred above).
>>
>> Acknowledging the fact that the text can be improved, I think it is
>> convenient to keep section 4.1.1.
>>
>> Best regards
>>
>> Luis
>>
>>
>> El vie., 24 abr. 2020 a las 2:56, Joel M. Halpern
>> (<jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>>) escribió:
>>
>>      I have serious problems with these aspects of the document.
>>
>>      Let's start with the first discussion of isolation.  This occurs in the
>>      description of the security objective.  I have no problem with
>>      including
>>      observable security properties in objectives.  telling the customer
>>      "your traffic will be encrypted across this slice" seems a useful thing
>>      to say.  We could even discuss how the security properties of the
>>      encryption should be described, although we need to be careful about
>>      how
>>      we do so.  But isolation of flows in the network is not an external
>>      observable, not something a customer can even ask about.
>>      Fundamentally,
>>      isolation is a way for an operator to meet a set of agreements around a
>>      set of objectives.  And this document says repeatedly that it is not
>>      about how, only what.
>>
>>      This gets worse when we get to the section on resolution of guarantees.
>>      The text begins by talking about hard vs soft guarantees.  And then
>>      explains that it means the difference between effects from interfering
>>      traffic and effects from hardware (or, presumably, software) failures.
>>      Except that from the perspective of the user of the slice, that is
>>      irrelevant.  If I have been given a commitment that I can send 95
>>      gigabits per second 95% of the month, and I discover that I was unable
>>      to do so for more than 5% of the time, I as a customer will expect to
>>      invoke whatever remedy my contract gives me.  If the contract had tried
>>      to draw a distinction bassd on cause, I would have said "no, I am
>>      paying
>>      for the service.  If you can't give it to me, I'll get it somewhere
>>      else."  The customer wants the commitment met,not excuses about which
>>      cause occurred.
>>
>>      The resolution then wanders over into the issue of tolerance.  As the
>>      section correctly observes, things break.  Agreements are generally
>>      written to allow a certain amount of that.  The classic 5-9s was
>>      exactly
>>      for this purpose.  It told you how well the service would be delivered.
>>      IP operators can and do make promises with commitments and frequencies.
>>      But it is not expressed as a tolerance the way this describes it in my
>>      experience.  Rather, it is expressed by having several objectives and
>>      differing levels of commitment for them.  As a purely fictitional
>>      example to try to be clear, one might have a series of loss comitments:
>>           No more than 10% loss - 99.999% of the time
>>           No more than 1% loss - 99.99% of the time
>>           ...
>>      That does not match the description of "Resolution of guarantee" in
>>      this
>>      definition document.
>>
>>      And then we get section 4.1.1 which is a discussion of isolation.
>>      It is
>>      a discussion which assumes the previous two elements are correct.   My
>>      recommendation is, rather than debating whether it is correct, is to
>>      simply remove all of 4.1.1.  If some folks involved wanted it, which is
>>      what is said on the call, then those folks need to speak up and explain
>>      what value it adds.  Currently, it misleads and confuses the reader.
>>
>>      As a final note, I suspect that the usage of SLO and SLA in this
>>      document does not match industry usage.  Some effort to address the
>>      mismatch might help us avoid further disconnects such as the above.
>>
>>      Yours,
>>      Joel M. Halpern
>>
>>      _______________________________________________
>>      Teas mailing list
>>      Teas@ietf.org <mailto:Teas@ietf.org>
>>      https://www.ietf.org/mailman/listinfo/teas
>>
>>
>>
>> --
>> ___________________________________________
>> Luis M. Contreras
>> contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com>
>> luismiguel.contrerasmurillo@telefonica.com
>> <mailto:luismiguel.contrerasmurillo@telefonica.com>
>> Global CTIO unit / Telefonica
> 
> ________________________________
> 
> 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 privileged and confidential 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
>