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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 10 February 2021 14:09 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 44A883A10C0 for <teas@ietfa.amsl.com>; Wed, 10 Feb 2021 06:09:31 -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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_0h2JK-dnUv for <teas@ietfa.amsl.com>; Wed, 10 Feb 2021 06:09:29 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A4C283A10BE for <teas@ietf.org>; Wed, 10 Feb 2021 06:09:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DbM893HFBz6G8Vs; Wed, 10 Feb 2021 06:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1612966169; bh=M9rOJ//icJRcpl9ct1diHSkHVdn0fz4jeRykOT7bXQo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vd9e5ryhYQGSXXVOXP2s4dSJhsgGVMgktro6MYpOI/VCJrRUkcUirLGoMpsalseOy jHf8cvrri2SkdA56yHLu1DsGbezJJLC6aqQu9QsB7fDI6dH86qpMEqi21azfZp2bmB 7molVp0fkm0Suarc2KA+BcJBnKZXyDEK6+xW1k3U=
X-Quarantine-ID: <W8dk07bzjW0C>
X-Virus-Scanned: Debian amavisd-new at a2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 4DbM886GXdz6G7r1; Wed, 10 Feb 2021 06:09:28 -0800 (PST)
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, "teas@ietf.org" <teas@ietf.org>
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <022001d6fc0e$4facba70$ef062f50$@olddog.co.uk> <86EF8667-4A3F-463A-BA3E-FE74F4875772@nokia.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d821a574-bcc4-e067-a553-4c79adbbe163@joelhalpern.com>
Date: Wed, 10 Feb 2021 09:09:28 -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
In-Reply-To: <86EF8667-4A3F-463A-BA3E-FE74F4875772@nokia.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/pYT3RHlVBmmbF5japUWd-fqHWvQ>
Subject: Re: [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: Wed, 10 Feb 2021 14:09:31 -0000

Rexza, there seems to be an inconssitency at the end of your note.
You state that whatever technology is used for teh IETF network slice 
must be supported by the endpoint.  If by Endpoint we mean the edge of 
the IETF Network Slice, I agree.
However, you actually draw the "Network Slice Endpoint" as being outside 
of the IETF Network Slice.  This creates two problems.  First, the IETF 
Network Slice Controller can not ensure that the correct technology 
usage is applied, as the Network Slice Endpoint is not under the control 
of the IETF Network Slice Controller.  Second, this implies that the 
IETF Network Slice will trust the technology marking (for example MPLS 
label) being sent by the external entity.  The general model is that 
such trust is not assumed.

Thus, I can not see how to make what you have diagrammed work.
Given that, I am asking the WG (which now owns the document) to modify 
the figure.

Yours,
Joel

On 2/10/2021 7:39 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> Joel and Adrian,
> 
> Agreed that there shall be clarity about the endpoints.
> 
>                  >>>>>> There are traffic endpoints (the sender and 
> receiver of packets), and there are endpoints of the service (the 
> ingress and egress to the slice).
> 
> This is correct Adrian.
> 
> An “IETF network slice” is between two or more endpoints as outlined in 
> the draft.
> 
> In summary, the  IETF network slice is defined  between various 
> device/applications/network functions on multiple “IETF network slice 
> endpoints”.  These are traffic endpoints of the IETF network slice. We 
> refer to them in the draft as “NSE” (IETF Network Slice Endpoints).
> 
> In addition , as Adrian mentioned there are endpoints to the realization 
> of the transport slice (i.e. various services/tunnels/paths). I am 
> suggesting to use term “NSI” (IETF Network Slice Ingress).  Please 
> provide your suggestions for NSI if you have any other suggestions.
> 
>                  >>>> For example, if the service is being
> 
>      delivered with MPLS, the Network Slice Endpoint likely cannot 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.
> 
> This is not correct.  Whatever technology is used to realize the IETF 
> network slice must be supported by endpoints. If MPLS is technology of 
> choice, the endpoint must support it in its data-path (and might also 
> support it in its control-plane).
> 
> Cheers,
> 
> Reza
> 
>      ------------------Original Message-----------------------
> 
> On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" 
> <teas-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:
> 
>      Ah, the old "endpoint" discussion.
> 
>      Yes, Joel is right, we need to disambiguate endpoints from endpoints.
> 
>      There are traffic endpoints (the sender and receiver of packets), 
> and there
> 
>      are endpoints of the service (the ingress and egress to the slice).
> 
>      There is probably a risk that we get sucked in to the wider 5G 
> picture, but
> 
>      we need to focus (as Joel says) on the IETF network slice.
> 
>      I suggest "source/destination" and "IETF network slice ingress/egress".
> 
>      And we can avoid discussion of the wider 5G context, as noted 
> elsewhere in
> 
>      the draft, by diverting that material into a dedicated document.
> 
>      Cheers,
> 
>      Adrian
> 
>      -----Original Message-----
> 
>      From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> 
>      Sent: 05 February 2021 17:04
> 
>      To: teas@ietf.org
> 
>      Subject: [Teas] network Slice Endpoint in
> 
>      draft-ietf-teas-ietf-network-slice-definition-00
> 
>      Rereading this draft, I realized that I am either confused by or
> 
>      disagree with the description of the "Network Slice Endpoint" 
> contianed
> 
>      there.
> 
>      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.
> 
>      Yours,
> 
>      Joel
> 
>      _______________________________________________
> 
>      Teas mailing list
> 
>      Teas@ietf.org
> 
>      https://www.ietf.org/mailman/listinfo/teas
> 
>      _______________________________________________
> 
>      Teas mailing list
> 
>      Teas@ietf.org
> 
>      https://www.ietf.org/mailman/listinfo/teas
>