Re: [Teas] WG adoption - draft-nsdt-teas-ietf-network-slice-definition Fri, 15 January 2021 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F1253A0408; Thu, 14 Jan 2021 18:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i52ZmZbNsLBn; Thu, 14 Jan 2021 18:08:44 -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 12B893A03FB; Thu, 14 Jan 2021 18:08:43 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 3D0E3BBE5C6E967CBBB8; Fri, 15 Jan 2021 10:08:39 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 1B61C29C5AE6E70B0961; Fri, 15 Jan 2021 10:08:39 +0800 (CST)
Received: from ([]) by with SMTP id 10F28TC3017367; Fri, 15 Jan 2021 10:08:29 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Fri, 15 Jan 2021 10:08:29 +0800 (CST)
Date: Fri, 15 Jan 2021 10:08:29 +0800 (CST)
X-Zmail-TransId: 2afd6000f91d48fa6ffb
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 10F28TC3017367
Archived-At: <>
Subject: Re: [Teas] =?utf-8?q?WG_adoption_-_draft-nsdt-teas-ietf-network-slic?= =?utf-8?q?e-definition?=
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, 15 Jan 2021 02:08:46 -0000

A little comment:

It seems that the definition document only support that the realization of IETF network slice is triggered by the consumer through the interface to NSC with specific SLO. I think it is not enough. Please see if it is needed to support the case for a network device (the headend) to explicitly request a slice on demand, and request a connection path within the specific slice on demand.




收件人:TEAS WG;
抄送人:TEAS WG Chairs;
日 期 :2021年01月04日 22:02
主 题 :[Teas] WG adoption - draft-nsdt-teas-ietf-network-slice-definition

Teas mailing list

 This is start of a two week poll on making
draft-nsdt-teas-ietf-network-slice-definition-02 a TEAS working group document.
 Please send email to the list indicating "yes/support" or "no/do not
 support". If indicating no, please state your reservations with the
 document. If yes, please also feel free to provide comments you'd
 like to see addressed once the document is a WG document.
 The poll ends January 18th.
 Pavan and Lou