Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00 Tue, 16 February 2021 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B1473A0981 for <>; Tue, 16 Feb 2021 08:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIR0ibkKgI1l for <>; Tue, 16 Feb 2021 08:05:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C2DF3A0964 for <>; Tue, 16 Feb 2021 08:05:15 -0800 (PST)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 4Dg5Qx65jhz2xqf; Tue, 16 Feb 2021 17:05:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1613491513; bh=UN7Gm0dSzWUQujoFwbwIdKHTbpXeRujRqKLRcBTnezY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iudqa6ZsIFnP9w4psTHPofsHNmxUsyoYQVtvOFCuQhg7Dg7GLBPrzIESsg7hU6nvF FmWQw8EDwxV84ynRRDYe2Ai4mmpT1UxfKcF/mP1jyK2eIBALZpGkKNlcdAmxhtQ8jR SOBvimNpuUz3MT28VAEXr6PbizRAS1+nlLc34A4LafUA0oIDihUwB+xRLHR0YVyyK6 BM+8Vb4QD7cH5bWzYMeOus9lfnjtKoSN5Ozavi9hnTBO3xNHUMx18Sz5M5oh2B90iF 94VDWqbJjDE/Ra/uByTUBd+sDUhcLBXm3YSIuiiIE4Cscubud3Q9Y8Urs7UCzJd650 +MOiYMBqCSw+w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by (ESMTP service) with ESMTP id 4Dg5Qx5GjdzBrLj; Tue, 16 Feb 2021 17:05:13 +0100 (CET)
From: <>
To: "Joel M. Halpern" <>, "" <>
Thread-Topic: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Thread-Index: AQHW++D9mVt/GtRqUUatUUOGUWSCQKpa/xNw
Date: Tue, 16 Feb 2021 16:05:13 +0000
Message-ID: <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.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: Tue, 16 Feb 2021 16:05:17 -0000

Hi Joel, 

I disagree with this note. I do think that both flavors of "endpoint" should be included in the draft. 

>From the customer standpoint, a slice request cannot be characterized by elements not visible to the customer. The scope of a requested slice can only be characterized between nodes that are known to the requestor. This is usually called, CE.  

The mapping between a CE and a network device (typically, a PE) is a process that is internal to the slice provider.  

The CE-PE link cannot be systematically excluded as some specific behaviors may need to be enforced in the CE-PE link. Think about a slice that is implemented by means of a PE-based VPN and which requires some specific routing + QoS policies at the CE-PE link.


> -----Message d'origine-----
> De : Teas [] De la part de Joel M.
> Halpern
> Envoyé : vendredi 5 février 2021 18:04
> À :
> Objet : [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


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.