Re: [Teas] WG adoption - draft-nsdt-teas-ietf-network-slice-definition

peng.shaofu@zte.com.cn Fri, 15 January 2021 03:06 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 DF98A3A0A12 for <teas@ietfa.amsl.com>; Thu, 14 Jan 2021 19:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBStKfYtSSdq for <teas@ietfa.amsl.com>; Thu, 14 Jan 2021 19:06:22 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 C34993A0A0B for <teas@ietf.org>; Thu, 14 Jan 2021 19:06:21 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 7253FBEFCE4CCBE3F8FC; Fri, 15 Jan 2021 11:06:19 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id 10F36GBw074052; Fri, 15 Jan 2021 11:06:16 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Fri, 15 Jan 2021 11:06:16 +0800 (CST)
Date: Fri, 15 Jan 2021 11:06:16 +0800
X-Zmail-TransId: 2afd600106a83ce2feb2
X-Mailer: Zmail v1.0
Message-ID: <202101151106163678194@zte.com.cn>
In-Reply-To: <342ca5e0-7374-9ed3-762f-385628806fb6@joelhalpern.com>
References: 202101151008295415129@zte.com.cn, 342ca5e0-7374-9ed3-762f-385628806fb6@joelhalpern.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: jmh@joelhalpern.com
Cc: teas@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 10F36GBw074052
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/I1MGzAWNTwKWw2Q5AuaTNcxxBFQ>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-ietf-network-slice-definition
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: Fri, 15 Jan 2021 03:06:24 -0000

Hi Joel,






Thanks for your attention.


Here, as the direction of the request is from south to north, do you think whether the definition document need to describe this case ?


If so, the request would be very different with that is discribed in the current document. In detailed, it is sent through technology-specific interface between headend and network controller, then the network contoller may continue to request a slice from NSC, or report the created slice to NSC through technology-specific interface.






Regards,


PSF









原始邮件



发件人:JoelM.Halpern
收件人:彭少富10053815;
抄送人:teas@ietf.org;
日 期 :2021年01月15日 10:18
主 题 :Re: [Teas] WG adoption - draft-nsdt-teas-ietf-network-slice-definition


Given that station in the case below is making a request, isn't it 
reasonable to assume that the request makes its way to the control 
systems, which then handle the itneraction with the underlay network 
through the mechanisms proposed in the definitions and framework drafts?

Yours,
Joel

On 1/14/2021 9:08 PM, peng.shaofu@zte.com.cn wrote:
> 
> 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.
> 
> 
> Regards,
> 
> PSF
> 
> 
> 原始邮件
> *发件人:*VishnuPavanBeeram
> *收件人:*TEAS WG;
> *抄送人:*TEAS WG Chairs;
> *日 期 :*2021年01月04日 22:02
> *主 题 :**[Teas] WG adoption - 
> draft-nsdt-teas-ietf-network-slice-definition*
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 
> All,
> 
> 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.
> 
> Thanks,
> Pavan and Lou
> 
> 
> 
> _______________________________________________
> 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