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

Adrian Farrel <> Fri, 05 February 2021 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93C4A3A0CB2 for <>; Fri, 5 Feb 2021 14:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mqeE33bFWAd2 for <>; Fri, 5 Feb 2021 14:29:08 -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 757343A0CB0 for <>; Fri, 5 Feb 2021 14:29:07 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 115MT5bq004939; Fri, 5 Feb 2021 22:29:05 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 568652203B; Fri, 5 Feb 2021 22:29:05 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 412A12203A; Fri, 5 Feb 2021 22:29:05 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 115MT4ZD003078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Feb 2021 22:29:05 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Joel M. Halpern'" <>
Cc: <>
References: <>
In-Reply-To: <>
Date: Fri, 5 Feb 2021 22:29:04 -0000
Organization: Old Dog Consulting
Message-ID: <022001d6fc0e$4facba70$ef062f50$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKkHwJGzCaQ8Mp5a65/8LWCXraT6aiv2xAQ
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--5.749-10.0-31-10
X-imss-scan-details: No--5.749-10.0-31-10
X-TMASE-Result: 10--5.749400-10.000000
X-TMASE-MatchedRID: C/snMIRQLS2yoI+bK8UPQnFPUrVDm6jtOxjb9QQbt+QtferJ/d7Ab08e 8uKrAhcoDYAHxkJ/ebW2jSLcggsvz7Z8nZGj3zvj3VYGKNZvmfs9DpdZx5HaZfz8/tFdCtAASCD KnwjRqQ7GvXIxVoG1fJ8AgPrLgHgUfBDl+p5qW7NpTt57XuqMc+DTYjejIZTwrGgVRjGm0Jc68+ rwcOUkgHtaRNl72+ZfNlyx5NRtFzxz4sVWKF9cYyjqhevdGUVYpxoLgv7S3sAHWqZnaQo5zNeul 29/x8ODENRGJfFquEc8IJjIWPVzqpTQ0IkqhJ+D5p1ddw6V4RscVnvRa+w/RjTdFbpwEeewbRcL HUOVSeZkNPoxOtX+6w9cxkKLkAwlTdo28FTeGnyF3ltzGc7tOwV54COoxb6XLIjthNyswgprQgS Rg6yiRQI9USq47T0GWqLBUk/Na0sdEHuT9yl/7J4CIKY/Hg3AtOt1ofVlaoKKLuVdohwX9bDszp 3K5gqD9xS3mVzWUuCXGE8JXoztzYHKdCQb/YuokQ7FbmHNrc90Y6INNFyqmaqgqD2dHW2Vr+kqS L+glbaUTGVAhB5EbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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: Fri, 05 Feb 2021 22:29:11 -0000

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.


-----Original Message-----
From: Teas <> On Behalf Of Joel M. Halpern
Sent: 05 February 2021 17:04
Subject: [Teas] network Slice Endpoint in

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.


Teas mailing list