Re: [Teas] Network Slicing Design Team definitions

Joel Halpern Direct <jmh.direct@joelhalpern.com> Thu, 30 April 2020 15:56 UTC

Return-Path: <jmh.direct@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 E25DA3A0DF8 for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 08:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 qXDv8suw_cLg for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 08:55:57 -0700 (PDT)
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 E84503A0C0F for <teas@ietf.org>; Thu, 30 Apr 2020 08:54:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Cg1Y4sWyz1p4Rf; Thu, 30 Apr 2020 08:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588262081; bh=X8T4CgAXk4i+ANSW6mks9s0IO1xIyp4rjyt70EHp8Lw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OP0FSMlihw3oYOlN6EcIarfjjJo91aDjM85ShiBg/d8vneftEH2aWiE2r1PBLjc06 EfI0B1eUqcpSIjPxtDA+T+L8AhDSesPq/MKf8by7+IFac3Vu6g/AR4mF8/5LPxyqNa /NByyCKtvKtONVCpC8oQi4QsT2a72I9xekA9SndI=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 49Cg1X4R6mz1p4RK; Thu, 30 Apr 2020 08:54:40 -0700 (PDT)
To: Eric Gray <ewgray@graiymage.com>
Cc: Jari Arkko <jari.arkko@piuha.net>, "teas@ietf.org" <teas@ietf.org>
References: <f568ddd7-51bb-9b5c-56ca-e7126d5a590e@joelhalpern.com> <565A2F8B-01C6-45D6-B358-240857B152B6@piuha.net> <962283bf-9e7a-a4e0-f838-d1cd008bb56e@joelhalpern.com> <294BD5DB-29CE-41E1-A033-F061DC509F0B@graiymage.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <7e9aa905-fd02-2c1b-781e-68dbc49947ff@joelhalpern.com>
Date: Thu, 30 Apr 2020 11:54:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <294BD5DB-29CE-41E1-A033-F061DC509F0B@graiymage.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dIn8D8RaONzIbeYSfioBf72KIIs>
Subject: Re: [Teas] Network Slicing Design Team definitions
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, 30 Apr 2020 15:56:07 -0000

If "Service Endpoint" is supposed to include the actual source or sink 
of the packet, then the definition should say that.  It is possible it 
means that, but it is very hard to glean it from the current text.  How 
about:

Service type EP:  This type of endpoint receives and sends user packets.
     It may be the actual source or sink of the packet.  It may also be
     a node which processes and potentially modifies received packets,
     and then sends those packets onward.  This would include ...

Yours,
Joel

On 4/30/2020 11:03 AM, Eric Gray wrote:
> I believe the intention is that “service end-points” correspond to the devices connecting to the transport slice, while “transport end-points” are the devices terminating the service itself.
> 
> Add the understanding the by “devices” IO do not mean to exclude “virtual devices.”
> 
> If my understanding is correct, what could we say to make this clearer?
> 
> —
> Eric
> 
>> On Apr 30, 2020, at 10:58 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>
>> I am referring to the later text on endpoints.  It defines transport endpoints and service endpoints.  But not actual endpoints.  So I found it odd.
>>
>> Yours,
>> Joel
>>
>> On 4/30/2020 10:29 AM, Jari Arkko wrote:
>>> Joel:
>>>> Oddity:
>>>>     The definition of Endpoint has the oddity that it seems to leave the original packet source and the intended packet destination as not being Endpoints?  They can not be attached directly to the transport slice?
>>> I’d like to understand your comment better. What specific text are you referring to? The definition simply said:
>>>   "A transport slice is a logical network topology connecting a number
>>>     of endpoints and a set of shared or dedicated network resources,
>>>     which are used to satisfy specific Service Level Objectives (SLO)”.
>>> At least in my mind this isn’t necessarily related to packet source and destination addresses; I may want a VPN between your network and mine, but that’s different from the addresses used in the traffic entering the VPN. For instance, my computer’s address is not the endpoint of the VPN, my VPN router is.
>>> But maybe I misunderstood the comment. I agree that the sections that come after the definition and talk about e.g. specific characteristics may have confused something in some cases. E.g., not sure we’ve entirely covered directionality correctly in all the text.
>>> Jari
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>