From nobody Mon May 17 02:09:50 2021 Return-Path: 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 4614C3A2FAB for ; Mon, 17 May 2021 02:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 i1T6JPGuShNM for ; Mon, 17 May 2021 02:09:45 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32763A2FA7 for ; Mon, 17 May 2021 02:09:44 -0700 (PDT) Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FkChV4Tq0z689bY for ; Mon, 17 May 2021 16:58:02 +0800 (CST) Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Mon, 17 May 2021 11:09:36 +0200 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 17 May 2021 17:09:34 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2176.012; Mon, 17 May 2021 17:09:34 +0800 From: "Dongjie (Jimmy)" To: "Joel M. Halpern" , "teas@ietf.org" Thread-Topic: [Teas] A draft on the framework for end-to-end IETF network slicing Thread-Index: AddHoyBLABnySO+KTBWZMMOaXQaqcf//mhSA//37oYCAA4qsgP/62Mzg Date: Mon, 17 May 2021 09:09:34 +0000 Message-ID: <65fb48d6e1984952b3f2b9a29f5ec892@huawei.com> References: <16d8b18dc5574d728842f086227efa97@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing X-BeenThere: teas@ietf.org 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: Mon, 17 May 2021 09:09:49 -0000 Hi Joel,=20 The traffic monitoring may happen at the edge or inside the domain, depends= on the required scope of monitoring. For example, a customer may ask for e= dge-to-edge service monitoring by default, once there is service degradatio= n, per-hop or per-segment monitoring could be triggered to help figure out = and fix the problem timely. How the monitoring is performed in the network = is not the focus of this document, it just shows some information about the= end-to-end service may be used by the network nodes for monitoring. Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, May 14, 2021 12:05 PM > To: Dongjie (Jimmy) ; teas@ietf.org > Subject: Re: [Teas] A draft on the framework for end-to-end IETF network > slicing >=20 > Do you mean traffic monitoring at the domain edges? Or inside the domain= ? > If at the domain edges, then any mapping technology can also be used for > monitoring. > If inside the domain, this places a significant disaggregated statistics = collection > load on the internals of the network. > Edge-to-Edge monitoring by the consumer (client? customer?) of the > component is clealry useful. But does not requrie such identification. > Nor does it requrie internal disaggregated state reporting. > the internals presumably will monitor the aggregated behavior. Which aga= in > does not require the identification. >=20 > Yours, > Joel >=20 > On 5/13/2021 11:54 PM, Dongjie (Jimmy) wrote: > > Hi Joel, > > > > Thanks for your comments. > > > > The requirement of carrying network slice related identifier in the dat= a packet > was described in draft-dong-teas-enhanced-vpn-vtn-scalability and other > relevant documents. Currently there are several proposals about the > encapsulation of network slice related identifiers. Based on that, this d= ocument > further describes the considerations about the multi-domain IETF network = slice > scenario, and the interaction with other technical domains for 5G end-to-= end > network slicing. > > > > You are right that the path selection, resource allocation and traffic = handling > would be based on the identifiers internal to a network domain. As descri= bed in > this draft, the end-to-end network slice identifier may be used for traff= ic > monitoring at the end-to-end network slice granularity. > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Thursday, May 13, 2021 12:49 PM > >> To: Dongjie (Jimmy) ; teas@ietf.org > >> Subject: Re: [Teas] A draft on the framework for end-to-end IETF > >> network slicing > >> > >> It is not at all clear that any identifiers are needed inside the > >> various networks, and specifically it is not clear that an internal > >> identifier for the end-to-end network slice is needed at the level of > >> the IETF network slice as is being defined by teas. Since path > >> selection, QoS parameter handling, and resource allocation needs to > >> be handled in aggregate, it seems likely that no such identifier is ne= eded. > >> > >> Yours, > >> Joel > >> > >> On 5/12/2021 10:53 PM, Dongjie (Jimmy) wrote: > >>> Hi WG, > >>> > >>> Recently we published a draft on the framework for end-to-end IETF > >>> network slicing: > >>> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network > >>> -s > >>> licing > >>> >>> k- > >>> slicing> > >>> > >>> This document describes the scenarios of end-to-end network slicing, > >>> and the framework of network slice mapping between different network > >>> segments and network domains. Multiple network slice related > >>> identifiers are defined to covers different network scopes. > >>> > >>> The network slice related identifiers of different network scopes > >>> can be instantiated with MPLS or IPv6 data plane, which are further > >>> described in the following drafts: > >>> > >>> https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slic > >>> in > >>> g/ > >>> >>> ci > >>> ng/> > >>> > >>> https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network > >>> -s > >>> licing > >>> >>> k- > >>> slicing> > >>> > >>> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-ne > >>> tw > >>> ork-slicing > >>> >>> et > >>> work-slicing> > >>> > >>> Your review and comments are welcome. (Comments on the specific data > >>> plane draft can go to the corresponding WG mail list). > >>> > >>> Best regards, > >>> > >>> Jie > >>> > >>> > >>> _______________________________________________ > >>> Teas mailing list > >>> Teas@ietf.org > >>> https://www.ietf.org/mailman/listinfo/teas > >>> >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas