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

"Joel M. Halpern" <> Tue, 17 November 2020 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F5923A0E7A; Tue, 17 Nov 2020 02:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FPAXhzE_tCJG; Tue, 17 Nov 2020 02:28:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E174B3A0E78; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4Cb2Gb4mvhz6GD2N; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1605608919; bh=JgE3JNgR2RJnr/0ml35N661bbBDgP4QWD1QEcVSmG0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CGDOZ32GqXnN8f/eq10bOrVZsoGN0uXhmGSQrE/VDVQ6JLjIrlVmVybv59ebqSrRc ls1Vp0FYq6NvF5E96CZ+J+ayzPhJjqid/h0cKPbwx6EcIVbLLVRMcOubv5q687SZv9 ytWKVxDeYYdnTXes3EKCHvooAVdwXom+UMMZ+CDk=
X-Quarantine-ID: <pUygzxPMO_YM>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4Cb2Gb0gkGz6GCkm; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
To: Stewart Bryant <>
References: <059e01d6b6ce$0f74a830$2e5df890$> <> <13178999-9168-46fb-8455-36d4d5683a2e@Spark> <> <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 17 Nov 2020 05:28:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 10:28:42 -0000

Is this analogous to specifying a burst rate with several rates over 
several time periods (only we are talking about operator ccommitments 
rather than customer commitments)?

If so, might this be something like a multi-level delay bound 
commitment, e.g.
For a given pair of ports
99% of your traffic will get there in 10 ms, and
90% of your traffic will get there in 100 ms
(I know, sloppy example, just trying to see if I am understanding the idea.)

If that is the idea, I am missing the aspect of "from outside".  From 
the customers perspective all problems are "from outside".  Whether that 
outside is a backhoe or competing traffic.


On 11/17/2020 5:22 AM, Stewart Bryant wrote:
> They are terms from the timing world where you look at a defect in terms 
> of its probability within a window within a larger observation period.
> <,_NSN).pdf>
> ITU define MTIE in G.810, but they are looking at a different class of 
> application (frequency transfer), but I think the concept translates 
> over here.
> If you look at slide 5 “MTIE of a practical packet clock” you get the 
> idea, but I think it needs expanding and applying to other characteristics.
> Now some of the error sources will be within the slice, but we also need 
> to worry about error sources induced from outside the slice.
> Best regards
> Stewart
>> On 17 Nov 2020, at 10:05, Joel Halpern Direct 
>> < <>> wrote:
>> Stewart, I think you are raising an interesting question, but one 
>> where I got lost part way through.
>> Can you elaborate one what you mean by "something analogous to MTIE 
>> and TDEV to describe packet and network interaction".
>> Thank you,
>> Joel
>> On 11/17/2020 4:57 AM, Stewart Bryant wrote:
>>>> On 9 Nov 2020, at 23:37, Jeff Tantsura < 
>>>> <> < 
>>>> <>>> 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