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

"Joel M. Halpern" <> Sun, 26 April 2020 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67CE43A0A63 for <>; Sun, 26 Apr 2020 09:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x5kNDBluThAe for <>; Sun, 26 Apr 2020 09:11:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2E223A0A62 for <>; Sun, 26 Apr 2020 09:11:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 499CZg3Pwvz6GDxm; Sun, 26 Apr 2020 09:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1587917483; bh=iaCW6Rvrk/fPsai85a0VjC9mmQD3M4/QNZEGE59TOZk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=o0Pfu3U71+KukQlihnvYHDzdPSLUP20XEX8yNEVbPGbpGUuoXXtUPoks0xeiZmDuT NzdAKJksGEZNHhgPQW7v2auVFzz1L8Fd19ix/bJAyBcSgo3AyrxN0eXW/qDUa4l+5/ bTgWPebKhanBjXqrvaXrBfV4YOgsWBAdjpnb5cs0=
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 499CZf6Ns7z6GDHv; Sun, 26 Apr 2020 09:11:22 -0700 (PDT)
To: "Luis M. Contreras" <>
References: <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sun, 26 Apr 2020 12:11:22 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Apr 2020 16:11:26 -0000

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.

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.


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 (< 
> <>>) 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
> <>
> -- 
> ___________________________________________
> Luis M. Contreras
> <>
> <>
> Global CTIO unit / Telefonica