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

Greg Mirsky <gregimirsky@gmail.com> Tue, 28 April 2020 16:17 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 879FF3A089D for <teas@ietfa.amsl.com>; Tue, 28 Apr 2020 09:17:54 -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 gSKdANRkfedb for <teas@ietfa.amsl.com>; Tue, 28 Apr 2020 09:17:52 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 7096B3A089C for <teas@ietf.org>; Tue, 28 Apr 2020 09:17:51 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id g4so22138427ljl.2 for <teas@ietf.org>; Tue, 28 Apr 2020 09:17:51 -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=tKr+umBa3+sAzIiRHB3iNgJZI6Fkfo0QWdj01l6dzOI=; b=ga/dMYowMf6bJkXGfBpz86tEH4EIUOHBE+YmYVGglx7HzGCRU2YGEuzvAHcNZyj8N+ uvEkEhGVmQXM2K2jhvYTTS9+hi3mvPx/v5/j0rGdC+CyFGBWFLp/FFw5Qo78bQ9Y1lPU TmU6rdtL6yWFaOGu4YoWMurENsydwzIh8N1A5AoO6T1gTjo0FeDu4fMirB91K2BL+ijS 6yRO3eEU5OjtI4kkLoKkf+UiaeidluqtSpL0nFNT5+zSE7sO6w/WAjikR734jLhJBxMy U6giY6/+e+cIyKjKm07gOBkllToR9/T9djKJ1y35PY3+fec4HuQjVTzsHhE6XGbJ07a6 rzwA==
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=tKr+umBa3+sAzIiRHB3iNgJZI6Fkfo0QWdj01l6dzOI=; b=SD8wgCMhvEDtFWevBhlTgs5vU62VV3i8qcHBjT/VgMOsL98S3bp3kmYrsnuiy0V7xw ESSrgvK72Prs+uRcULwvQvtpJCVHBe7B2R4m+ZqZN+9G8c/MUAIm1mHgMe+3GnSPxgKQ A9JQECAvD9Sb/Uhw4ywQpLXZHITiRozxhU9wD40NzBwPfsAcFgOTa7Rdyv8rcNxt7p1p nV0ujRJ67DYOvXQTqgVFZCMBTmso6HiShv7gQ6oHVeZ2h2pIozRJMa336N0BzPAoapZn jcwDaUDfylEfHcXnHF26EyBIm460xyaSs20L59OWVdF4TlCEFC3tF2CnReLxr0DH94hc RmeQ==
X-Gm-Message-State: AGi0PuayhDpjhamHCj81NQmMbtq2Q0n41pee3e8h2RqrPcbHWmeWYXdU 5lwbtzr0J5X3gbetj/jXKaPmLQr+C0Zzk08CVtS0ZRc8
X-Google-Smtp-Source: APiQypJnet6fyB6Qp5geeKXvR9hk1v5xfouqBcelRc+K5N7mfuov0vmCyWz8HzpF+pNBJ/W/Q/hZgivZZMVu84zwyjM=
X-Received: by 2002:a2e:a37b:: with SMTP id i27mr17180842ljn.36.1588090669225; Tue, 28 Apr 2020 09:17:49 -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> <CA+RyBmWaBN=WP3A4qwCOvm5Vax2ookYYas1-L5yQFiGmRH2OBA@mail.gmail.com> <aac854e6-92e5-59ea-3dac-e95fbf424a98@joelhalpern.com>
In-Reply-To: <aac854e6-92e5-59ea-3dac-e95fbf424a98@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 28 Apr 2020 09:17:37 -0700
Message-ID: <CA+RyBmXDMaGuts4PLHhS4NWS=0Szedm34j4cbCjVNk6LR2j5Zg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035dbbd05a45c2cd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/jNJfo5MAwKr_i_lzH_u-tNBVBoU>
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: Tue, 28 Apr 2020 16:17:55 -0000

Hi Joel,
thank you for your expedient response. I agree that the current document
uses the term isolation is a rather overloaded way. One way may be to look
for other terms to differentiate between, for example, underlay resource
access and utilization.

Regards,
Greg

On Mon, Apr 27, 2020 at 2:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Greg, that definition seems to be a specific subset of VPN.
>
GIM>>

> As far as I can tell, the slice definition does include what endpoints
> the slice participants can talk to.  Presumably, with some way to say
> "the Internet".
> So Whether the slice supports communication with the Internet or not is
> definitely an observable property.  I would tend not to call it
> isolation.  Separately, the definition you propose is unrelated to the
> definition in the document,
> Which is why I suggest, for now, removing all discussion of isolation
> from the document.
>
> Yours,
> Joel
>
> On 4/27/2020 5:22 PM, Greg Mirsky wrote:
> > 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 <mailto: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
> >     <mailto:teas-bounces@ietf.org>] On Behalf Of Joel M. Halpern
> >      >> Sent: Sunday, April 26, 2020 10:52 AM
> >      >> To: Zhenghaomian <zhenghaomian@huawei.com
> >     <mailto:zhenghaomian@huawei.com>>; teas@ietf.org <mailto:
> 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
> >     <mailto:jmh@joelhalpern.com>]
> >      >>> 发送时间: 2020年4月26日 10:34
> >      >>> 收件人: Zhenghaomian <zhenghaomian@huawei.com
> >     <mailto:zhenghaomian@huawei.com>>; teas@ietf.org <mailto:
> 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 <mailto:Teas@ietf.org>
> >      >> https://www.ietf.org/mailman/listinfo/teas
> >
> >     _______________________________________________
> >     Teas mailing list
> >     Teas@ietf.org <mailto:Teas@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
>