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

Joel Halpern Direct <> Tue, 10 November 2020 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CD013A1507; Mon, 9 Nov 2020 16:01:38 -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_H3=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 ATwghcflPBor; Mon, 9 Nov 2020 16:01:36 -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 26D653A1503; Mon, 9 Nov 2020 16:01:36 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CVShJ0LWcz1nsT0; Mon, 9 Nov 2020 16:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1604966496; bh=0tLObAI5dda2jHrS2STmGd6z0xae+/XUIg2t5qwkbjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a2i7VaRVlLDOPzuEvcb8GjQA+ffTgsMTSku6wfhnz2kxzuXbOakxJjBCM93TTmMhs KZYR0bsCYgIjjvEbNoNvFC2tNG2XgUrWQ5xRKDXjBsZgs72MvudZnBNM8CC7g0sNlk J50RG85khzfkai3gUSAwfIYRJoDj1yibw5BWZDek=
X-Quarantine-ID: <B_7_JPmaKoDf>
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 4CVShH33lvz1nsSy; Mon, 9 Nov 2020 16:01:35 -0800 (PST)
To: Jeff Tantsura <>,
References: <059e01d6b6ce$0f74a830$2e5df890$> <> <13178999-9168-46fb-8455-36d4d5683a2e@Spark> <> <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
From: Joel Halpern Direct <>
Message-ID: <>
Date: Mon, 09 Nov 2020 19:01:34 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark>
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, 10 Nov 2020 00:01:38 -0000

You raised the dedicated fiber question.
If one has an end-to-end system with multiple components, there are many 
places where there simply will not be dedicated fiber.

More importantly, I see no way to meaningfully express "the customer 
wants as much dedication as possible" in the interface we are 
discussing.  Such a declaration will be dealt with in different ways by 
different people / systems / adminstrations, meaning that it gives no 
reliable behavior to the customer.

I agree that Isolation is not an SLO.   But if it is not an SLO, I do 
not know how it fits with the rest of what the definitions draft lays out.


On 11/9/2020 6:37 PM, Jeff Tantsura wrote:
> Joel,
> There’s no buying of any fibers, a slice is a service provided by a 
> provider to a consumer. A fiber between point A and point B is a valid 
> example of a slice, as much as an LSP, lambda, or any other technology.
> We are talking about defintions (terminology) applicable.
> Would the following definitions work for you?
> dedicated infra (in any way or form) - for example some vendors allow 
> you to have a dedicated NPU on router.
> disjointed infra, where backup path is isolated (non fate sharing) from 
> primary, e.g. SRLGs, common devices, etc
> 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.
> Joel - my last objective in the world would be to have you to object the 
> same draft again, please bear with us in preparing for the adoption.
> Cheers,
> Jeff
> On Nov 9, 2020, 2:47 PM -0800, Joel Halpern Direct 
> <>, wrote:
>> If your security policy requires dedicated fiber, buy dedicated fiber.
>> If you are going through shared routers, shared roadMs, etc. then
>> dedicating the fiber seems to me to completely miss the point.
>> And none of the definitions I have seen for what "Isolation" could mean
>> go to the requisite level of detail. If it means "the entire
>> infrastructure must be dedicated", then I do not think it belongs in the
>> IETF. If it means "dedicate something, please", then it is not an SLO.
>> The definitions and framework draft are explicit that they are
>> technology agnostic. So it is really hard to see how you can express
>> any meaningful and useful isolation, assuming that there is such a thing.
>> More importantly, I would want to see an actual definition of what is to
>> be described if we are to include it.
>> I am not asking that the placeholders be removed. There may be a
>> definition that is useful. But what is there isn't it. Saying that
>> there may be some as yet undefined SLO that relates to som as yet
>> undefined meaning of Isolation does not cut it for me.
>> And yes, I am getting tired of refighting the same discussion. We
>> agreed on leaving placeholders in the document. I was hoping and
>> expecting that we could get the result of that adopted. I do not like
>> having to object to the same draft again.
>> Yours,
>> Joel
>> On 11/9/2020 5:43 PM, Jeff Tantsura wrote:
>>> Joel,
>>> Thanks for your comments.
>>> I respectively disagree with you, if my security policies require use of
>>> dedicated infrastructure (fiber is a common one), it is a valid service
>>> objective.
>>> Cheers,
>>> Jeff
>>> On Nov 9, 2020, 1:45 PM -0800, Joel M. Halpern <>, 
>>> wrote:
>>>> Thank you Adrian. I mostly agree with what you say (retained below.)
>>>> The only point where I disagree is that the proposed text fro 9.1 still
>>>> keeps the notion that there may be an Isolation SLO.
>>>> As far as I can tell, Isolation is a mechanism. It is one of many
>>>> mechanisms that can be used to meet the SLOs. I have no idea what an
>>>> Isolation SLO element would be, or why a customer would ask for it.
>>>> So I would be inclined to go a step further and just get rid of 9.1.
>>>> Yours,
>>>> Joel
>>>> On 11/9/2020 2:25 PM, Adrian Farrel wrote:
>>>>> Hi,
>>>>> I'm not sure where the right place to discuss this document is. 
>>>>> Since it
>>>>> replaces the previous terminology document, and since that was
>>>>> proposed for
>>>>> adoption on the TEAS list, I think this is probably the right place 
>>>>> (feel
>>>>> free to redirect me).
>>>>> I'd like to focus this email just on Section 9 - the text on 
>>>>> isolation. I
>>>>> suspect that this is the largest remaining obstacle to WG adoption.
>>>>> Firstly, we have to recall that this is a terminology document, not a
>>>>> broader architecture. Therefore we should aim to reduce the text to 
>>>>> clear
>>>>> and simple definitions: further text belongs in some other document
>>>>> such as
>>>>> the framework draft or a focus-specific document that describes some
>>>>> facet
>>>>> in detail. So I guess I agree with the Editor's statement at the top of
>>>>> Section 9...
>>>>>> Editor's note: This content is a work in progress. The section on
>>>>>> isolation is too descriptive.
>>>>> A way to reduce this would be...
>>>>> == Section 9 ==
>>>>> OLD
>>>>> An IETF Network Slice consumer may request, that the IETF Network
>>>>> Slice delivered to them is isolated from any other network slices of
>>>>> services delivered to any other customers. It is expected that the
>>>>> changes to the other network slices of services do not have any
>>>>> negative impact on the delivery of the IETF Network Slice. In a more
>>>>> general sense, isolation can be classified in the following ways:
>>>>> Traffic Separation: Traffic of one network slice should not be
>>>>> subjected to policies and forwarding rules of other network
>>>>> slices.
>>>>> Interference Avoidance: Changes in other network slices should not
>>>>> impact to the SLOs of the network slice. Here the changes in
>>>>> other network slice may include the changes in connectivity,
>>>>> traffic volume, traffic pattern, etc.
>>>>> Service Assurance: In case service degradation is unacceptable due
>>>>> to unpredictable network situations producing service degradation
>>>>> (e.g., major congestion events, etc.), explicit reservation of
>>>>> resources in the network maybe requested for a reduces set IETF
>>>>> network slices.
>>>>> NEW
>>>>> An IETF Network Slice consumer may request, that the IETF Network
>>>>> Slice delivered to them is isolated from any other network slices of
>>>>> services delivered to any other customers. It is expected that the
>>>>> changes to the other network slices of services do not have any
>>>>> negative impact on the delivery of the IETF Network Slice.
>>>>> END
>>>>> In making this change I'd note that while these three principles are an
>>>>> important part of the discussion of isolation they are out of context
>>>>> here.
>>>>> Traffic separation is a feature of how isolation may be achieved, but
>>>>> it is
>>>>> not something that a consumer can or should specifically ask for:
>>>>> they have
>>>>> no way of measuring it and, indeed, since they don't know the 
>>>>> purpose of
>>>>> policies and forwarding rules within an operator's network they 
>>>>> shouldn't
>>>>> ask for control over them. Interference avoidance is a fine goal for a
>>>>> consumer to ask for, but you already have this captured in the 
>>>>> preceding
>>>>> paragraph. Service assurance seems to capture two things: that the
>>>>> consumer
>>>>> may wish for protection of their service in the event of network 
>>>>> failure
>>>>> (that's not really an isolation thing) and that a way to protect 
>>>>> against
>>>>> failure situations is to reserve resources (that's not necessarily an
>>>>> isolation thing, and is certainly a question of realisation).
>>>>> == Section 9.1 ==
>>>>> I think that this section is a little over-stated. Maybe:
>>>>> OLD
>>>>> Isolation is an important requirement of IETF network slices for
>>>>> services like critical services, emergencies, etc. A consumer may
>>>>> express this request through the description of SLOs.
>>>>> NEW
>>>>> Isolation may be an important requirement of IETF network slices
>>>>> for some critical services. A consumer may express this request as
>>>>> an SLO.
>>>>> END
>>>>> == Section 9.2 ==
>>>>> While I think there is value in having this section to note that
>>>>> there is a
>>>>> concept of isolation in the realisation of a network slice, I don't 
>>>>> think
>>>>> you should get into details with examples etc. If you want to talk
>>>>> about how
>>>>> realisation of network slices works, that should be in another 
>>>>> document.
>>>>> Thus, I think you could drop the whole of the fist paragraph: it just
>>>>> duplicates some of the ideas in the second paragraph which says it more
>>>>> clearly.
>>>>> Furthermore, the final paragraph in the section seems to be all about
>>>>> realisation. I think you should drop it partly because it is 
>>>>> technically
>>>>> suspect (an L3VPN does not achieve traffic separation in the network,
>>>>> that
>>>>> is exactly the point of an L3VPN), but mainly because it is a
>>>>> discussion of
>>>>> the details and technologies of realisation.
>>>>> == Section 9.3 ==
>>>>> I tend to think that there will be value in a full and careful
>>>>> discussion of
>>>>> how IETF network slices meet the requirements of 3GPP transport
>>>>> slices, but
>>>>> I don't think it should be in this document. Thus, I agree with the
>>>>> editor's
>>>>> note that the section should be removed. Maybe interested parties could
>>>>> start a new document "Applicability of IETF Network Slices to 3GPP
>>>>> Transport
>>>>> Slices."
>>>>> Thanks,
>>>>> Adrian
>>>>> _______________________________________________
>>>>> Teas mailing list