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

"Luis M. Contreras" <contreras.ietf@gmail.com> Sun, 26 April 2020 11:27 UTC

Return-Path: <contreras.ietf@gmail.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 1C3D63A134E for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 04:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o7dd5AK0acnw for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 04:27:00 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137CD3A1354 for <teas@ietf.org>; Sun, 26 Apr 2020 04:26:59 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id t3so15171729qkg.1 for <teas@ietf.org>; Sun, 26 Apr 2020 04:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xoV2VtuCpzegkzKcfGK2Prnu7QeovFhtWIlOFRRzXQE=; b=ghM2jaWSDIT/XrulG33j5bZkmXibUVh3xvAioQjaqEvFsWZUvj1HqiGdgOYfYgYS5Y qMeItcxyzWQQi8yROhNqPlQWuyfKU/9bGgMbJpsBg6WzzqdeLaOU27XM/JMoWDVUaoMS df/YBZPRkQZvKjctk4vqfcQoeRd9w8BxH+thbjoPj6IcBdrRt6bMllWvIlIYgig+UItH EO9/6vVrr3HvzP4na7XtlzZueqF/jigATa1c3I5KvUABS5c66Jf8j7E7K6Nz3bToBDJB 5TWKOjQQ8o6AiwTDgT+Z7U1rbDy548///BoUUYkmH54dPAkvC/C/DZlHWZxbf5q+WMmz QpXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xoV2VtuCpzegkzKcfGK2Prnu7QeovFhtWIlOFRRzXQE=; b=g4/Im/mtNL5gZAixyNQ4d5zfgkGrPLYD1AgY5D3/PTnrhFeEjQt6fKc3hyEOEQRk/u Fy4PI1uSsF4xavUe2jHO3+JnenEn0VTD9tMyyPvmmRzM/mzqOUTnDSVPRezfX+ahKN3w w2u9I42cnv/YKv5qbVDnVGmavSa9tXrk5mwvEwVFUxnVjRwEf7ZexMZunVa1V0Wfknjt nwopEFZA5v8Dwi8OREEfKNvFzgztuklZYD2tgVmXZxoHVg8olrhtdg7vHysvOUbLrOIV flg+wlGrWOzq2MpTeDc6YfurJHPuq8ouIIDcC7g5UZ6HBGLDZzY4saa7PtYwneWY1ZT+ /ZrQ==
X-Gm-Message-State: AGi0PuZMpCZCOqEHErRg9UVlXiL8eMOatUVsQwBaXl6oPDq/aZGBXK8q +mGsu+MzC9ijnuRqHYLTM3PsD1E6xrPTyRv0pu0=
X-Google-Smtp-Source: APiQypISVXIa23/q9T6J0VjZtVs5rW83U1sIeZA6XyNSnlcZIz6EnxEW2qj95yfnXqZNJ0xEFTep8h5/tNIZzhtxNWU=
X-Received: by 2002:a37:6496:: with SMTP id y144mr18255704qkb.206.1587900418988; Sun, 26 Apr 2020 04:26:58 -0700 (PDT)
MIME-Version: 1.0
References: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com>
In-Reply-To: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Sun, 26 Apr 2020 13:26:47 +0200
Message-ID: <CAE4dcx=1_DT8dn_+B1X+6S-iHsoPsd6TyAJsnEj2iLznjtfAPw@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "teas@ietf.org" <teas@ietf.org>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Content-Type: multipart/alternative; boundary="00000000000069a13605a42fe03c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/uP54GEiMyJ6FsP6RbcfUwCbkIhQ>
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 11:27:02 -0000

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>)
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
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica