Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

Stewart Bryant <stewart.bryant@gmail.com> Tue, 17 November 2020 09:57 UTC

Return-Path: <stewart.bryant@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 0B9FA3A0DE0; Tue, 17 Nov 2020 01:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 74cn6MAXM89l; Tue, 17 Nov 2020 01:57:43 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 3AAA83A0DDD; Tue, 17 Nov 2020 01:57:43 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id d12so22480363wrr.13; Tue, 17 Nov 2020 01:57:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HVLPDgpCL1os5p+peQDq82s08R034slDM33OSMV3zYc=; b=f5uhopBH8R/izOec2XJ9N3vhDKqzIDDMcj6xyy9ocHKQQL9JwBB/8JTAb7LufNfUJx XKulRfC2bcDYmyFXgOWeiq0PkjREL8qgVloSUBzHvcdqufmJ8N4tubqDN2w+07wHeHpH F1DxdCvnNYivnmC1p+CtVDwZ+6zOvVh/U05UiKzMhxwzUdwVz4ukY6yAlQ2PhOMYUkqN JotXi9P9DnfXH/38YXz7IbaDFAJ5rLJWM0tvCpHaTBMOHAuvSahhryeRupRVoPqmaSAF oGHLg+1bp6n5xd/2vJSuIJJY25oDmHkXSZ/P7f0+fT6zKIOndm/MYy3iQYKXev9AnyHI vK3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HVLPDgpCL1os5p+peQDq82s08R034slDM33OSMV3zYc=; b=Tk+Y2ZHM5cAHPqO8j1d5jjiNxCUJ1NUtjPsaxEKakpAstZ6LHktpGKCoGqHG2V03es O//UGrBBMgEL05rcK1PiN4hOBmx0i4pfHlLprr/vSI/uXKK7bnkTn5zNTJUw1N0BasdU E3wKIdpVW9XjtMEo1oG1OvpxtlmAj5NSGKvqdTO84cHyVh8WObDRLCy5WeFaFqkjMYHe 1o4Qt+UfNGrt9gRgFBAtK/fxOoVPevdOzQCzvf/LjYy8L3QymuDNJDDdGd+fnrSJCxo6 TyZdK0VRlDllu/+pMTmmCaYl/zTk5PBREIbQj96BYXnLLDZsZ3u3PnqGIcF/rU5fiPvO OZQw==
X-Gm-Message-State: AOAM533mlK08BwqDhX1EtOs/1fCUlEvybQvVioFlQusRutgjBZMLjvD1 RfSnUH40EIjApJVfaWOKM+c=
X-Google-Smtp-Source: ABdhPJxeE8WTYC/auuQ+KLHSCsrpgTlVxOlSWLP+0z6kN+tIIZ/1Tn7AUgPIbhrYFQe3hfzUe5AIKA==
X-Received: by 2002:a5d:5222:: with SMTP id i2mr25509611wra.247.1605607061694; Tue, 17 Nov 2020 01:57:41 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:a9c3:7842:c90b:a6e1]) by smtp.gmail.com with ESMTPSA id t7sm1620106wrp.26.2020.11.17.01.57.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 01:57:40 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <879FFB4D-3E9B-498C-BF40-B30252A8F273@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0F0173D-99C6-4BF1-AA77-796C12692BD8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 17 Nov 2020 09:57:39 +0000
In-Reply-To: <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Adrian Farrel <adrian@olddog.co.uk>, teas@ietf.org, Joel Halpern Direct <jmh.direct@joelhalpern.com>, draft-nsdt-teas-ietf-network-slice-definition@ietf.org
To: Jeff Tantsura <jefftant.ietf@gmail.com>
References: <059e01d6b6ce$0f74a830$2e5df890$@olddog.co.uk> <9e8170c6-399b-e954-2abb-5e5f425f172a@joelhalpern.com> <13178999-9168-46fb-8455-36d4d5683a2e@Spark> <62c127a5-9230-d105-04b7-4b061fdd43c1@joelhalpern.com> <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dWp1xijIP1PQvV-gbX4SNEDGR-s>
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
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, 17 Nov 2020 09:57:45 -0000


> On 9 Nov 2020, at 23:37, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> 
> I don’t think mixing performance objectives with isolation is a great idea though, 
> an SLA doesn’t change because there’s someone else sharing infrastructure with you, it is well understood that any changes within other customers should not affect you.

No, but in this class of networks the interaction between customers may be a lot more sensitive and detailed than we are used to. For example the single metrics that we normally associate with delay and jitter will likely become a mask in the same way that time and frequency transfer system find necessary to completely specify and instrument the behaviour of the subs system. We will likely need something analogous to MTIE and TDEV to describe packet and network interaction.

I therefore think it is useful to have an umbrella term for concept and the set of metrics that are of necessity more complex and critical than we are used to.

A possible alternative umbrella term is network cross talk. We understand the concept of crosstalk at the physical layer. The concept here in terms of performance is that packets do not interact at the micro level as well as the more normal macro level.

However, isolation has other feature that we need to think about under this umbrella, for example the need to only mix certain types of traffic allow (or exclude) traffic to flow over certain geographies or through nodes manufactured by certain countries. We do not have to agree with these constraints, but we need to accept that they are becoming a reality.

Now we could achieve the above by buying dedicated fibre or dedicated hardware, but that that does not support economies of scale.

I would be fine with us using a term other than isolation, but I think it is worthwhile highlighting that we are not in “ordinary” SLA territory with this, but that it is more complex and more detailed, and a top level term to group these characteristics is in my view helpful.

Best regards

Stewart