Re: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 04 March 2021 16:02 UTC

Return-Path: <jmh@joelhalpern.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 D971E3A0E7A; Thu, 4 Mar 2021 08:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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.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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lk_sGlep8Va; Thu, 4 Mar 2021 08:02:08 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 E8B723A0E77; Thu, 4 Mar 2021 08:02:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Drwc05c4dz1nv9S; Thu, 4 Mar 2021 08:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1614873728; bh=C3bVVJaURmQZxEauN7E/WORziQ0fnqFW1Ms4ZSDQkLI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GD81QWoQkmMtNs3xtGsV6JLkh5OChKoM6gKFhK9FCggiOLn+d1xYUFoXNOSR5vqf4 k/rkSXh5KMIfzkebpxv5DyVqtwi/ylqwzREbzTqlgSDWf0w5TmiirZlbUvNNUMJz9Q aS+4Vb6Cvr1EZHr6SQR3Bc9VeSku0Gt0NsvOXSa0=
X-Quarantine-ID: <sXlZAoSZwbdo>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Drwbz6tqcz1ntX2; Thu, 4 Mar 2021 08:02:07 -0800 (PST)
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, TEAS WG <teas@ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
References: <309691A9-7DEE-479B-9BDC-3469138FFB92@nokia.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0fb3bf1c-880d-f7d1-a662-930d647ef6eb@joelhalpern.com>
Date: Thu, 4 Mar 2021 11:02:06 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <309691A9-7DEE-479B-9BDC-3469138FFB92@nokia.com>
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/uBlZc2i-_rP48PlqpZhpAtd8Dk8>
Subject: Re: [Teas] Response of IETF Network slice coauthors to TEAS mailing list
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: Thu, 04 Mar 2021 16:02:10 -0000

(I am not retaining the original message.  Please see it separately as 
it is long and detailed.)

I am confused by at least two aspects of the proposals from the document 
authors.

1) I am confused as to why PE is not listed as a viable term for the 
endpoint.  It seems the natural endpoint of the IETF Network Slice (not 
from the perspective of the service user) just as the PE is the endpoint 
of the operators service in the VPN cases, even though the customer's 
focus is on the CE devices.

2) I am confused by the assertion taht the 4G use case requires that the 
end points be the CE.  In those environments, the CE is not under the 
control of the what 3GPPP calls the Transport Network Slice controller. 
  As such, the CE can not be the endpoint of the IETF Network Slice.

I suspect that there are other places where I am misunderstanding the email.