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

"Luis M. Contreras" <contreras.ietf@gmail.com> Sun, 26 April 2020 12:18 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 4407D3A142D for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 05:18:58 -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 RQ87DZeMt74n for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 05:18:54 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 67DA43A142B for <teas@ietf.org>; Sun, 26 Apr 2020 05:18:54 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id i68so11952252qtb.5 for <teas@ietf.org>; Sun, 26 Apr 2020 05:18:54 -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=o9jISquibzCCKGlE6eGKUHoiGZpaqFrxjbumiKnR+f8=; b=QBvIO8LQ0sghoKDkcQUaiQ950MXwJEpW9FVlDKRoBz3d82zmGCGWyXfrlJz1GyYhl2 6JRYRRclvya9Nga374RZXO7R6pnS13M8FVU0SAs6s3xVt0NdpjPNExRpDVbNDzYv1yUT tNnlPuGVlH7VhwOCuUioYMj+DrjBnHHZdWfRzWJTRlpKsl5hYTiKjzSGRl0Tb0YpkKiq 3C84TMYxsDK5UQj4lSKJIqMcd/YMUSPr+paN9UEgxF3N1AwPCxnbyG4iOnYiMN+OLEiU NYKiQhsGtOEJIyLh5m2WVWXZrumxteuBJe4wutaU2+ET1mlT4yH0i1q6O+hsvefljEtz wmHQ==
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=o9jISquibzCCKGlE6eGKUHoiGZpaqFrxjbumiKnR+f8=; b=LyNlXm0anCy1bXWwSTfcYeHQA909A4fg8LcluCuu3mejHLE1ViRQqE3lFLChadu7a2 RsPim9KUsSsAUiXszEHDslU38vGtxqB0gExpWvzx5lJYRhzaycPwRVDaZrS28VFMvo0s 9o9W62jXy2E505JwhiUHKMftRkP3SEi3dUgJQQJNCnTfhQUpIVQwcIRpFhybXhspOKKf i5GGvaqNLrbtNXIiDNnQzXAo7seAjyV4VxSMgpPaVwG+muwsmm/WLTJA3cUTd6sH8oLf N0hsNH6x8WUR77BLm3ij3cmB/70siLXdxsVatigbiAp1ied3tffXDb8Bxd4d+0Ix2H9E vxSQ==
X-Gm-Message-State: AGi0PubUJdBaccgEScqtajCkr8QVRRsAQWHZuMRCfZFOnNaB304gdGQy o3fda/lX5vu9ndJpHxv13nFJ8zYysG/phGTH0Ds=
X-Google-Smtp-Source: APiQypKSj2eaZOF3+8vlelWmU/+99hqNOAftMZ1/2g+49irM2ytG4OagzScvuEi5683rGLurKD+WR+QnLXjDUhXAyBc=
X-Received: by 2002:ac8:2224:: with SMTP id o33mr11927279qto.45.1587903533304; Sun, 26 Apr 2020 05:18:53 -0700 (PDT)
MIME-Version: 1.0
References: <E0C26CAA2504C84093A49B2CAC3261A43F82E780@dggeml531-mbs.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43F82E780@dggeml531-mbs.china.huawei.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Sun, 26 Apr 2020 14:18:42 +0200
Message-ID: <CAE4dcxmqX+CkJpr1APiN1vwsVaOdhojTBW-CfTn8pYzaoMCksA@mail.gmail.com>
To: Zhenghaomian <zhenghaomian@huawei.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Kiran Makhijani <kiranm@futurewei.com>, "teas@ietf.org" <teas@ietf.org>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Content-Type: multipart/alternative; boundary="0000000000000a4f7605a4309ac4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/N8XTf6tlxNFr_azU0BZk77prxEo>
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 12:18:58 -0000

Hi Haomian,

The SLA is the framework where SLOs are defined for a given service between
customer and provider. The SLOs apply to different service aspects e.g.
latency, bandwidth, packet loss, etc. Behind a SLO there is a particular
penalty as well (not all the SLOs are equally critical, so different
penalties apply usually).

The operators are proactive on meeting SLOs, I mean, the operators are not
reactive waiting for a problem to occur. The networks are continuously
monitored and SLOs are tacked trying to mitigate issues impacting a
particular SLO and the SLA in general. For instance, diverting traffic from
one link to another, etc.

The SLOs are usually thresholds, in such a way that whatever is below the
threshold is fine, but exceeding that threshold is problematic for one of
the parties. For instance, if the operator guarantees a given latency,
exceeding such latency will probably produce a penalty. On the other hand,
if the customer pays for some guaranteed traffic but not for its excess, in
case of exceeding the committed traffic there are not guarantees for it,
and no penalties occur.

In this sense, I presume transport slice service will behave in the same
way. A number of service attributes will be specified by the slice
customer, becoming SLOs of the service, with some penalties associated to
them in case of not being honored. The operator will do its best to monitor
and track the commitment of those SLOs by tacking different actions in the
network ot ensure that fact.

Hope this clarifies a bit the discussion.

Best regards

Luis


El dom., 26 abr. 2020 a las 4:31, Zhenghaomian (<zhenghaomian@huawei.com>)
escribió:

> Hi, Kiran, Joel,
>
> This is really interesting discussion, I thought I understood the SLO
> clearly but now I am re-confused... Regarding SLO we may have two different
> understandings:
> 1) The service level threshold. In this case when the objective goes
> beyond certain value, the delivery is failed. For example if the user is
> asking for an availability of '>99%' and the delivery is '98%', then the
> user may reject to pay for the service. And this is very much like an SLA,
> i.e., in a 'contract'.
> 2) The service level objective function. In this case the user may demand
> the transport slice to be running under the policy 'some parameters is
> maximized/minimized'. For example, the user want the slice to be in
> 'minimal latency', then it's nothing to do whether the latency is 7ms or
> 9ms, it should be minimized.
> For both 1) and 2), of course a combination among multiple parameters
> should be allowed.
>
> The discussion so far reminds me that none of the above is accurate. When
> introducing the 'ranging', for example 'latency between 7ms and 9ms', does
> it imply that 'a 5ms-latency slice is a bad slice'? It should not be...
> The 'lifetime'/'lifecycle' statement is also confusing when you say 'A
> transport slice would ask: do not exceed 95gbps for the lifetime of the
> service'. I am curious on 'what will happen if 95gbps is exceeded', does it
> mean the slice should be cut down? When the quality of the slice is
> exceeding the expectation of user's request (or user's tolerance), what
> would be the outcome?
> IMHO, when we specify the SLO, besides how to represented we also need to
> understand what is the criteria to judge whether the SLO is achieved or
> not, and what is going to happen if the SLO is not satisfies. For SLA these
> are clear but for SLO it's not.
>
> BTW, regarding the isolation, I don't see the necessity to argue whether
> it should be in SLO or not. The isolation itself, can either be requested
> by the user of the transport slice (then from NBI of TSC) to express the
> demand of reliability, or be offered by the provider of the transport slice
> (then from the SBI of TSC) to achieve the SLO requested from the user. In
> other words, if the user requests certain level of isolation in an SLO,
> such isolation should be provided; if the user does not request certain
> level of isolation (no isolation request in SLO), then there may be some
> isolation provided to satisfy the user's request.
>
> Best wishes,
> Haomian
>
> -----邮件原件-----
> 发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Joel M. Halpern
> 发送时间: 2020年4月25日 3:55
> 收件人: Kiran Makhijani <kiranm@futurewei.com>om>; teas@ietf.org
> 主题: Re: [Teas] Network Slicing design team definitions - isolation and
> resolution
>
> Focusing first on your last comment, but retaining the rest for context.
>
> As I understand a Transport slice, it is all about giving a well-defined
> traffic behavior to the set of traffic the user injects into the slice.
>
> This has many dimensions in order for it to be deliverable.  It has to
> include the limits on what the user is allowed to inject.  It has to
> include how reliably / often / ... the given level will be met.
> In common usage, the SLOs are the numbers used to fill these things in.
> Coupled with reliability / assurance levels, customer limits, and other
> things, to construct an SLA.  An SLO of 95 gigabits does not mean anything
> without the concomitant knowledge of how often it will be met.
> This gets even messier with things like availability, as you have to
> actually define what it means for the service to be available.  (E.g. an IP
> service that drops half the packets at random is probably not actually
> available.)
>
> Saying 95 gigabits for 9500 flows (not sure that is even a meaningful
> parameter for packet service delivery) without a reliability is
> meaningless.  It can not be 100%.  Even the existing text notes that things
> break.  If it is 50%, it is not much of a commitment.  Which is why you tie
> the objectives to the other parameeters.  And thus need SLAs even if there
> is no money changing hands.
>
> Your text on ranges also left me confused.
> The typical case where one wants a delay range one actually wants a
> guarantee of a minimum delay, and a separate bound on delay variation.
> I do not know of a case where the customer asked the provider to slow down
> his traffic.  Nor do I know of a case where a customer said "do not give me
> more than the stated bandwidth."  the customer may want to control what
> rate he sends, but that is separate.
>
> Hence, I am left very confused by your answers.
>
> Yours,
> Joel
>
> PS: It is very well known, and frankly sensible, that operators when
> making these promises look at the cost of meeting the agreement, the
> operational complexity of delivering it often enough, and the price of
> failure.  And then choose different techniques to deliver the service based
> on those trade-offs.  Which, in practice, suggests that the orchestration
> likely needs visiblity to the other parameters such as how often it can
> fail.  (For example, you use FRR if you need to recover faster.  Based on
> your analysis of likely failures, non-FRR recovery times, ....)  We leave
> these kinds of things to the operators, as discussion of the business
> parameters themselves are clearly out of scope for the IETF.  But we have
> to recognize in our definitions that they are an intrinsic part of the task.
>
> On 4/24/2020 3:40 PM, Kiran Makhijani wrote:
> > Hi Joel,
> > Please see inline.
> >
> > -----Original Message-----
> > From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> > Sent: Thursday, April 23, 2020 5:56 PM
> > To: teas@ietf.org
> > Subject: [Teas] Network Slicing design team definitions - isolation
> > and resolution
> >
> > 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.
> > [KM] There's a particular challenge with this document. Our first goal
> is to define transport-network slices in an independent, standalone manner,
> at the same reuse or build on existing/progressing IETF work. It gets
> off-balanced easily.
> > But yours's is a fair justification. Isolation can be removed from
> security. I wanted this explanation so that when we develop next level of
> details we have some idea on what should be considered.
> >
> > 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.
> > [KM] I do not see a transport slice as a "contract". The typical
> transport slice expresses the knowledge of how much of an SLO and what
> failures your service can endure. for the user of the transport slice (Who
> is offering a service) ability to describe this is not irrelevant. When
> network provider receives request, they know what kind of effort they
> should make to keep service running. (e.g. packet loss for AR/VR should be
> way lower than 4K media service).
> >
> > 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.
> > [KM] This may have been misunderstood. The text is "certain tolerance
> level of that objective", alternately can be read as 'range' for example:
> bounded latency (delivery time not to exceed 9 ms, or between 7-9ms, delay
> variation is in 0.5 to 1ms range and so on).
> >
> > 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.
> > [KM] I have always seen SLA at the business level but transport slice is
> something that can still be described in a tangible resource-requests.
> Therefore, 95gbps per month is not a description of a transport slice. A
> transport slice would ask: do not exceed 95gbps for max 9500 flows where
> each flow gets 1gbps from pt 'a' to 'b' or 'c' to 'd' for the lifetime of
> the service.
> > -Kiran
> >
> > Yours,
> > Joel M. Halpern
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futur
> > ewei.com%7C3a14db2095eb4646145808d7e7ea6c9f%7C0fee8ff2a3b240189c753a1d
> > 5591fedc%7C1%7C0%7C637232866346233496&amp;sdata=cFEYu%2BcEy3YEHTjFK7tq
> > maVZghv%2F4VLFDaoX07OZRXg%3D&amp;reserved=0
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> 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