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

Greg Mirsky <gregimirsky@gmail.com> Mon, 27 April 2020 21:23 UTC

Return-Path: <gregimirsky@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 5E0C73A0B2A for <teas@ietfa.amsl.com>; Mon, 27 Apr 2020 14:23:06 -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 u068XF4_jP-D for <teas@ietfa.amsl.com>; Mon, 27 Apr 2020 14:23:04 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 D6AF93A0B23 for <teas@ietf.org>; Mon, 27 Apr 2020 14:23:03 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id a21so19218285ljb.9 for <teas@ietf.org>; Mon, 27 Apr 2020 14:23:03 -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=yE9cqMkdR2ZcjRuOyAJMYJth6ozZ/78X6SYDXbCe5a8=; b=eMEZg17nL0+7I7iweyrPn7qK/p8rt9kUWLkprQvYplqF7RerhYy6ocXbIZpFzkDPdB /enaD4tUFwaFQKIz5+NFAaUnhuPbYNunkBcgv+5xmjKVfQ8l3j5nzs7IqKkACwCEnY/g Sy++nLU/NVid30QrzEOxd172++roZRcAqMfgrlmhbUjZx7pb8h/ME8klzdTAHXrr/sod 1sb2i0E0ro79bxp7PwN7KypAqCW8bBaXuNEDgzK/AbUwqrb+cFNrCLCKp6kfGc6nkUJR zjnmQic6JIuZY4Srih6Bb7lWQkSwUrfHcBEOPEViGXEljXkxspsdkjAX3+1Yec52wZx8 zLaw==
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=yE9cqMkdR2ZcjRuOyAJMYJth6ozZ/78X6SYDXbCe5a8=; b=Wdchm5cEZnIBy9Usr2yLcyNLzBklzZeQ7yRzHxfnNQ6ltUw8k5MIW/QOoxd+adkcqR tgO+MyYoVuGBMLjZqxq0EJs8WvjWoGZC62QlTuy7nv2Kyd3vEy8KCqVNMMM4oIrCZMkl rfC8z3qGHRv5i/f0e83m9lU3Auzub+mX3qRnECstpnFj1+ue/oi9+YFfilwAwP9GtYMc 2PzjdaOl2vtcxf08wAMU6ca18wZ98C9974nIEj1UraZY2nBK5/RjYIIRAxRPDiq//Axn orgKKjEohH0q1Hc3eVeLOf07nxX7XK5SVLfVnXRuTmO0dJlDxoxZFFdRoK1QyeD0gkbY +hiQ==
X-Gm-Message-State: AGi0PuYnfeYmoUatay8FgORtcTTBo6d2vdqCpEQLV/ULR7wZ5dmJCD/Q Ar9BatSAYmhvCZxxjJp5yXA6R4Id5WsIX/MSJJk=
X-Google-Smtp-Source: APiQypLD9PnsZa+PG50p8tMeUo4KNYp+SqpP/olPn8iM56f66zmlzanoLmDDgTcrHJw77FdDu9P6dePdvl3UBb8u9f8=
X-Received: by 2002:a2e:8645:: with SMTP id i5mr14875008ljj.56.1588022582084; Mon, 27 Apr 2020 14:23:02 -0700 (PDT)
MIME-Version: 1.0
References: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com> <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com> <a94fe17dae2244b0af6a9303e68f1e0e@huawei.com> <b54e1be6-cfd2-0bf7-1601-f6764253dfa3@joelhalpern.com>
In-Reply-To: <b54e1be6-cfd2-0bf7-1601-f6764253dfa3@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 27 Apr 2020 14:22:50 -0700
Message-ID: <CA+RyBmWaBN=WP3A4qwCOvm5Vax2ookYYas1-L5yQFiGmRH2OBA@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e687fe05a44c5158"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XSIuGhZhw_XTF-I4cTsaTeoRmRs>
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: Mon, 27 Apr 2020 21:23:07 -0000

Dear Joel,
thank you for bringing the matter of "isolation" to the discussion. I
agree, that it is not practical to expect physical isolation in modern
networks. In my view, a transport slice that requires isolation is as a
transport connection that expects to receive data only from the specific
domain and not from any other domain. In other words, I view isolation as
the absence of mis-connectivity (in transport network interpretation which
differentiates between path continuity check and connectivity
verification). If my interpretation is acceptable, then isolation can be
monitored using connectivity verification OAM mechanism(s).
I much appreciate your thoughts, opinion on the proposed interpretation of
isolation on transport slice.

Regards,
Greg

On Sun, Apr 26, 2020 at 8:57 AM Joel Halpern Direct <
jmh.direct@joelhalpern.com> wrote:

> Trimmed, in line.
> Joel
>
> On 4/26/2020 11:08 AM, Dongjie (Jimmy) wrote:
> > Hi Joel,
> >
> > Please see some replies inline:
> >
> >> -----Original Message-----
> >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> >> Sent: Sunday, April 26, 2020 10:52 AM
> >> To: Zhenghaomian <zhenghaomian@huawei.com>om>; teas@ietf.org
> >> Subject: Re: [Teas] Network Slicing design team definitions - isolation
> and
> >> resolution
> >>
> ...
> >> More importantly, it is not something the customer has any way to
> verify.
> >> There is no test a customer can run that will verify this.
> >> Making unverifiable promises is rarely a useful thing to do.
> >
> > Totally agree that tools for verification is important. As mentioned in
> Haomian's mail, isolation can be verified with suitable tools which can be
> used to collect the information at the necessary places with a suitable
> interval. And it is important that customers can be provided with such
> tools to monitor the performance and be informed of SLA violation.
>
> As far as I can tell, the observable that you describe is latency
> variation (or maybe loss).  Fine, describe the SLO in terms of latency
> variation  (or loss).  Given that there are always imperfections in the
> system, the customer may think that the issue is isolation.  But what he
> can observe, and as far as I can tell what he cares about, is delay
> variation, loss, or other factors that affect his traffic.
>
> To use a different example, I have learned from the advocates to hate
> bufferbloat.  But even their tests measure delay, delay variation, etc.
> They then infer the presence of large buffers.  But in fact, if the
> large buffers are present but never used, we would all be happy.  So the
> SLO on this would be in terms of latency, latency variation, loss, etc.
> Not bufferbloat.`
>
> Yours,
> Joel
>
> >
> > Best regards,
> > Jie
> >
> >>
> >> Yours,
> >> Joel
> >>
> >> PS: Note that I understand that operators get asked for odd things mby
> >> customers.  But if we are going to define standards to support it, we
> need to
> >> understand the actual need.
> >>
> >> On 4/25/2020 10:44 PM, Zhenghaomian wrote:
> >>> Not sure if I understand your question correctly.
> >>> Well, it's reasonable for people to request hard isolation because 'I
> don't want
> >> my data to be transported together with other people's data'.
> >>> For delivery this can be achieved by separating physical
> devices/connections,
> >> which are visible to users. For example dedicated boxes and fibers will
> guarantee
> >> the user's data is not mixed with others...
> >>>
> >>> Best wishes,
> >>> Haomian
> >>>
> >>> -----邮件原件-----
> >>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>> 发送时间: 2020年4月26日 10:34
> >>> 收件人: Zhenghaomian <zhenghaomian@huawei.com>om>; teas@ietf.org
> >>> 主题: Re: [Teas] Network Slicing design team definitions - isolation and
> >>> resolution
> >>>
> >>> (trimmed)
> >>> What is the user perceivable effect that the user is asking for when
> you say "if
> >> the user requests isolation"?
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 4/25/2020 10:31 PM, Zhenghaomian wrote:
> >>>> Hi, Kiran, Joel,
> >>>>
> >>> ...
> >>>> 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 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
>