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

Adrian Farrel <> Mon, 09 November 2020 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBE883A14B5; Mon, 9 Nov 2020 14:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WbrPO9IE1gWV; Mon, 9 Nov 2020 14:43:12 -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 7CE573A14B3; Mon, 9 Nov 2020 14:43:11 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 0A9Mh9l3003568; Mon, 9 Nov 2020 22:43:09 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 352A12203A; Mon, 9 Nov 2020 22:43:09 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 1F72822032; Mon, 9 Nov 2020 22:43:09 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 0A9Mh8kj017892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Nov 2020 22:43:08 GMT
From: Adrian Farrel <>
To: "'Joel M. Halpern'" <>,
References: <059e01d6b6ce$0f74a830$2e5df890$> <>
In-Reply-To: <>
Date: Mon, 09 Nov 2020 22:43:07 -0000
Organization: Old Dog Consulting
Message-ID: <05f901d6b6e9$b1ea5d10$15bf1730$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJK0Oit4RAb34CsJ7/kEIyUPjt1rQKuxijNqMKu3rA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--17.888-10.0-31-10
X-imss-scan-details: No--17.888-10.0-31-10
X-TMASE-Result: 10--17.888400-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFqyoI+bK8UPQnFPUrVDm6jtIiTd2l7lf6F9y6OaSLZZAqUi 8ZPRSO7Jt4aKvLq1VW1jjjG2+MnmeLCul2XVVRIPvOAv94sAIMRxwd2E9HfHcuYS38oBQHVU2+I Z8ewswif9BxIarPfLB7sHGWcFq2VU/kT8m1LJ+ENK9CbrGqYI8lHewY36PuY0cBOzQn722txnOh YgYp+C3bUgpEbCTkPX0BkpfhIXys7lNp7BmTNDTuIfK/Jd5eHmv/9ovxpTvIAgVZAf8m502KXtZ 8mQILa09/7iRpuXQ4EGcqHDk09pFlypVJFmh6sL8eSmTJSmEv2JE9Tq+96NclAoBBK61BhcZ4Ys L3LbKzFZQ5MmdixBrbPfT2HouvngSV6DMuPW8hbdVgYo1m+Z+webMc7dN8D4sYrD6khqn6V6fxt HhEI7nmGuwAw1GZQ2c9uqRy87Ezo5CPhzmt790/RUId35VCIeZZ5HkRNGNgOW/cHxFnWaGE1oNp RtMImz4sOfGAg2QIznAwqUIKdw8t5xKQ1PuX/ZQC90vhPOlk1dA4rYaKGKwlabQmUcC70BEj34B ad2yLw5nEP7Qbp/14DH02jiwWT8d3lO5dgnh383aW/7bl6SZ83VJwt1d9zqvK1LW7VnvPqz7GAB evf9QfVL+nyqq5mVmwTlrlXub1HzLuGqRda7mNtuAjgC5ilXQCoHzuo2nBl+SLLtNOiBhm8AyzA JO0+xYqalFk63HxQdbIQcINqTm5VvPoxSj5rmDcFFYSBeqVZMtkHpT9ho+tTRSqmN+EOXTSodzF AVOHdUiXLTiA0nj3ZBoRjYTnUZ1x7q6N2snaeeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zhG2qikEpQGVQWV48z04iDebVgiML2ckmXnOt0cDSxR1+rsBaQBV5iCFASTKa woSo
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
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: Mon, 09 Nov 2020 22:43:15 -0000

Yes Joel,

I think "isolation" as an SLO is a shorthand for "not only do I want my SLOs met, but I don't want any of the SLIs I forgot to capture in SLOs to be impacted by other services."

But 9.1 does say:
- can be met by simple conformance with other SLOs
- isolation from other services might be only a means [an] end
I think those are probably the points you are making when you say you don't see the point of an isolation SLO.

But we might usefully strike the five lines of example:
   For example, traffic congestion (interference from other services)
   might impact on the latency experienced by an IETF network slice.
   Thus, in this example, conformance to a latency SLO would be the
   primary requirement for delivery of the IETF network slice service,
   and isolation from other services might be only a means to that end.


-----Original Message-----
From: Joel M. Halpern <> 
Sent: 09 November 2020 21:45
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

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.


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 ==
>     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.
>     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 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:
>     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.
>     Isolation may be an important requirement of IETF network slices
>     for some critical services.  A consumer may express this request as
>     an SLO.
> == 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