[Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 05 February 2021 17:04 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6F1763A1377 for <teas@ietfa.amsl.com>; Fri, 5 Feb 2021 09:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QSgtt2Bsh2ws for <teas@ietfa.amsl.com>; Fri, 5 Feb 2021 09:04:30 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678433A1379 for <teas@ietf.org>; Fri, 5 Feb 2021 09:04:30 -0800 (PST)
Received: from localhost (localhost []) by maila2.tigertech.net (Postfix) with ESMTP id 4DXMGQ0VHLz6GWJr for <teas@ietf.org>; Fri, 5 Feb 2021 09:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612544670; bh=1nA85NLaRw4/hQi6iD+xwye66+lCl8mr7WMB9TYufFo=; h=To:From:Subject:Date:From; b=KxYgKRQ+SYVF+LcjMZRHhdX4VkQVj2oCQu/s0WzviFdWATdMkg9F5DvLoD5zBe9Z7 zSsDWlOo4KIsPM9LJki6oIDE35Zgfw6JeLX6h/Yjhgb1yecBqRrt943dttWmw2oIUy TTjqAPY4BxSgoLEY8hE0Upoz2q8Bu2VKzRKyLswU=
X-Quarantine-ID: <5LGAa-Y_dT6w>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DXMGP4XZ1z6GJgp for <teas@ietf.org>; Fri, 5 Feb 2021 09:04:29 -0800 (PST)
To: "teas@ietf.org" <teas@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com>
Date: Fri, 5 Feb 2021 12:04:29 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/vYB3X6OdA_4GIJXZBqKfHpLXHYc>
Subject: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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: Fri, 05 Feb 2021 17:04:31 -0000

Rereading this draft, I realized that I am either confused by or 
disagree with the description of the "Network Slice Endpoint" contianed 

The endpoint that I think matters is the place where the IETF Network 
Slice Controller starts controlling the QoS and traffic delivery.  The 
Controller doesn't care about the identity of the device outside of that.

Figure 1 in section 4.2 seems to define that endpoint as the network 
slice realiation endpoint, and describes the network slice endpoint as 
the thing outside the IetF network slice.  This seems counter-productive 
to me.  It complicates teh relationship between the endpoitn and the 
service being abstracted.  For example, if the service is beign 
delivered with MPLS, the Network Slice Endpoint likely can not put the 
labels on the packet for the MPLS, as it is outside of the IETF network 
Slice.  So we will need yet another layer of classification, and yet 
more interworking.
Further, someone has to get the queueing right for traffic coming out of 
the Network Slice Endpoint.  But it is not part of the IETF Network 
Slice, so we don't have any way to get it right.

If we define the edge of the space we care about co-incident with the 
edge of the space we influence, things get a lot cleaner.