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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 24 April 2020 00:56 UTC

Return-Path: <jmh@joelhalpern.com>
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 44A9C3A0C30 for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 17:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HAS6Lha-VDcf for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 17:56:42 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net []) (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 D40CE3A0C28 for <teas@ietf.org>; Thu, 23 Apr 2020 17:56:23 -0700 (PDT)
Received: from localhost (localhost []) by maila2.tigertech.net (Postfix) with ESMTP id 497bMq4qDvz6GFCs for <teas@ietf.org>; Thu, 23 Apr 2020 17:56:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587689783; bh=WNjsZwrdk5ZuVhAxwMbjq41YDgocouRMLVoxkpfSduI=; h=To:From:Subject:Date:From; b=bBM6MJP65JMHbq27zs6vu4gid364lDcwcfXsioorfx2ZxVFI9a3EjmnAWmgxquADi 9cTStMlbpbIfI9nvhVjzY4idwmAtB1CiARrqKczI1qoC7EAJ8Ga03McMlmm4NEqGgk PoTG7YrJxa2CGzIf5Y1fc6ALKCoa4qlxrp7zH8FE=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [] (209-255-163-147.ip.mcleodusa.net []) (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 497bMq1mnBz6GD8W for <teas@ietf.org>; Thu, 23 Apr 2020 17:56:22 -0700 (PDT)
To: "teas@ietf.org" <teas@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com>
Date: Thu, 23 Apr 2020 20:56: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
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/JtKxs7lPeWLoORHciET14OOFwlg>
Subject: [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: Fri, 24 Apr 2020 00:56:46 -0000

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.

Joel M. Halpern