Re: [Teas] New term for the underlay construct used for slice realization

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 13 August 2021 12:11 UTC

Return-Path: <jie.dong@huawei.com>
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 56B2D3A1620 for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 05:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 1ZIzqY4aanvs for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 05:11:34 -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 3F2E63A161F for <teas@ietf.org>; Fri, 13 Aug 2021 05:11:34 -0700 (PDT)
Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GmMpK3qp6z6GBfc for <teas@ietf.org>; Fri, 13 Aug 2021 20:10:49 +0800 (CST)
Received: from dggpemm500006.china.huawei.com (7.185.36.236) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 13 Aug 2021 14:11:30 +0200
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 13 Aug 2021 20:11:28 +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; Fri, 13 Aug 2021 20:11:28 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Lizhenbin <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New term for the underlay construct used for slice realization
Thread-Index: AdeN+wpTY0PlvtVsQlC++M4sZJMfAAAHO8wwAA9dd4AAFeyW4ABcxq2A
Date: Fri, 13 Aug 2021 12:11:28 +0000
Message-ID: <a1e378cd81e144adad89d38987a2cb47@huawei.com>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@BY3PR05MB8081.namprd05.prod.outlook.com>
In-Reply-To: <BY3PR05MB80816B3982271C1FEA86E46CC7F89@BY3PR05MB8081.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.160.196]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-l1kfrQQGqAcLrs2NKa0X7-J4rk>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
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, 13 Aug 2021 12:11:41 -0000

Hi John, 

Thanks for your clarification. I think we are mostly aligned. 

My hope is the new term could reflect the two basic attributes of the underlay construct: partitioned resource and a (sub-)topology.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of John E Drake
> Sent: Wednesday, August 11, 2021 8:38 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Lizhenbin
> <lizhenbin@huawei.com>om>; teas@ietf.org
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
> 
> Jimmy,
> 
> Snipped, comments inline.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -----Original Message-----
> > From: Dongjie (Jimmy) <jie.dong@huawei.com>
> > Sent: Tuesday, August 10, 2021 11:03 PM
> > To: John E Drake <jdrake@juniper.net>et>; Lizhenbin
> > <lizhenbin@huawei.com>om>; teas@ietf.org
> > Subject: RE: New term for the underlay construct used for slice
> > realization
> >
> > [External Email. Be cautious of content]
> >
> underlay construct for network slice realization bound to
> > > > network slice services? That is, is the underlay construct only
> > > > for use in network slicing, or should it be generalized for more possible
> uses?
> > >
> > > [JD] Absolutely yes
> >
> > [Jie] I guess you mean "Yes" to the latter case, which is "it should
> > be generalized for more possible uses", is my understanding correct?
> 
> [JD]  Yes to the latter
> 
> >
> > >
> > > >
> > > > 2.      If the answer to question 1 is YES, should it reflect the following
> > > > characteristics?
> > > >
> > > > a.      It is about the underlay
> > > > b.      It is about the partitioned resources used to deliver the network
> slice
> > > > services
> > > > c.      It allows the 1:1, N:1, and 1:N mapping models between the
> network
> > > slice
> > > > services and the underlay construct. The 1:1 and N:1 mapping may
> > > > be straightforward. Does it also make sense to divide the elements
> > > > or traffic flows in a single network slice service to carry them
> > > > in different
> > > underlay constructs?
> > >
> > > [JD]  Yes to all of the above.  Please see:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > > af
> > > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
> > gk!TCiJHCZCwFgwpuFoujxVlZ4r9
> > > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$
> > > >
> > > > Lastly, here are some candidates of the "new term":
> > > >
> > > > Option 1: The network slice service is called "overlay slice",
> > > > then the underlay construct is called "underlay slice".
> > > >
> > > > Option 2: The network slice service is called "service slice",
> > > > then the underlay construct is called "resource slice".
> > >
> > > [JD]  I don't think we need another term for what we are already
> > > calling an 'IETF Network Slice Service'.  Adrian and I are
> > > considering the term 'resource partition' to describe the
> > > partitioning of underlay network resources in support of various
> > > overlay services such as IETF Network
> > Slice Services.
> > > This is congruent with the ideas expressed in:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > > af
> > > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-
> > gk!TCiJHCZCwFgwpuFouj
> > > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$
> > > ts-03.  What this allows one to build is an 'partitioned underlay
> > > network topology'.
> >
> > [Jie] Agree that here we are talking about the term for the underlay construct.
> > "Resource partition" captures one of its key characteristics, while
> > IMO another thing the term needs to reflect is that the resource
> > partition is needed on a subset of the links and nodes (rather than on
> > a single node or link) in the physical network, which together builds a logical
> network topology.
> 
> [JD]  In my initial email, above, I was proposing 'partitioned underlay network
> topology'
> 
> >
> > Best regards,
> > Jie
> >
> > >
> > > >
> > > > Your opinion about these candidates are much appreciated. You may
> > > > also propose other new term if it complies with the above two points.
> > >
> > > [JD]  I think you have exceeded your remit.
> > >
> > > >
> > > >
> > > >
> > > > Best Regards,
> > > > Robin
> > > >
> > > > _______________________________________________
> > > > Teas mailing list
> > > > Teas@ietf.org
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > > te
> > > > as
> > > > __;!!N
> > > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> > > > O08HqD31TGJciNjuxL2A$
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> > > as
> > > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> > ROxL4C2
> > > _xNDCrPaNQ$
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas