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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 373493A0B60 for <>; Tue, 16 Feb 2021 08:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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 ZBfNx37o3oef for <>; Tue, 16 Feb 2021 08:40:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BD1E3A0CA7 for <>; Tue, 16 Feb 2021 08:39:06 -0800 (PST)
Received: from (unknown [xx.xx.xx.9]) by (ESMTP service) with ESMTP id 4Dg69z6p4Mz8tPS; Tue, 16 Feb 2021 17:39:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1613493544; bh=OJB9yshXYxmxgzpKoY5kvMA7eOpgNF8LubW6HSFcOyA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZuP8HgROC/p5kKWO7OCcKyswJxmUMxyznVyQzJ5EKMR02tVsXNQt3slMOasBLIzEO MUBpKwx+pmC+7f21xaMsg/4UrwJxA4pmTeyARSjhUqB7xO/yRH8Wq+xa84X6g5cZr/ jN3muknSWeqN4XzvSPV0Z2ZIrOve0nbJP8w7Mn/l11tqJHfjnaWurvAdvZJh/WfeAx otf+MUSGB4ItN/GyhjCOnUnWLygESJ9YY1d05O3Ck79L+S7fj/GE5GbrK9RZxV662v ArkHjjXr9eRzXF5JJ1NuAZDvwva21ZB4nrrhFSXIXTznWnzNcSdyMUMZgIDdSrTMjS MlSM1ixcaQf7A==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by (ESMTP service) with ESMTP id 4Dg69z5xKDz5vMq; Tue, 16 Feb 2021 17:39:03 +0100 (CET)
From: <>
To: "Joel M. Halpern" <>, "" <>
Thread-Topic: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Thread-Index: AQHXBH5yU2/MeEBEyEKqarhBNrQMb6pa9rsA
Date: Tue, 16 Feb 2021 16:39:02 +0000
Message-ID: <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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:40:28 -0000


Please see inline. 


> -----Message d'origine-----
> De : Teas [] De la part de Joel M.
> Halpern
> Envoyé : mardi 16 février 2021 17:12
> À :
> Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> network-slice-definition-00
> The document is not about the request from the external customer (the
> request for the end-to-end network slice). It is about the request
> from other orchestration systems to the IETF Network Slice management
> systems. 

[Med] ... which is still behaving as the customer role. 

 Yes, those systems need to know where they intent to
> utilize the IETF network slice.  But the IETF network slice does not
> need to know about that.

[Med] This is what I fail to see. The orchestrator has an internal vision that is not available to the entity asking for a slice. These nodes are not even known to the "other orchestration systems" when asking for a slice. 

> In particular, when we get to talking about configuring the IETF
> Network Slice properties, the edge (ingress) that the IETF Network
> Slice controller controls (and corresponding egress) is what needs to
> be provisioned.

[Med] Agree, but that is a distinct phase. 

BTW, ingress/egress are as a function of the traffic direction. A node (PE) may behave as both ingress and egress for the same slice.  

> It is possible that on the egress side there needs to be information
> about how to deliver the traffic externally.

[Med] Agree. That node does not need to be visible (known in advance) to the entity that will consume the corresponding slice.

  But that would not be
> in terms of end-points since from the perspective of the IETF Network
> Slice, on the egress that is not an endpoint of anything.

[Med] I agree that "endpoint" is confusing. "Customer Node/Edge" vs "Provider Edge" are my favorite here. 

> Yours,
> Joel
> On 2/16/2021 11:05 AM, wrote:
> > 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.
> >
> > Cheers,
> > Med 


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.