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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 13 August 2021 15:52 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 865CA3A1D3D for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 08:52:54 -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=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 OaomJ8UTO2cd for <teas@ietfa.amsl.com>; Fri, 13 Aug 2021 08:52:48 -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 73D133A1D39 for <teas@ietf.org>; Fri, 13 Aug 2021 08:52:48 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GmSjY5RvTz6GC5R for <teas@ietf.org>; Fri, 13 Aug 2021 23:52:01 +0800 (CST)
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Fri, 13 Aug 2021 17:52:43 +0200
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 13 Aug 2021 23:52:41 +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 23:52:41 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] New term for the underlay construct used for slice realization
Thread-Index: AdeN+wpTY0PlvtVsQlC++M4sZJMfAAAHO8wwAA9dd4AAFeyW4ABcxq2A///IAYD//1m2YA==
Date: Fri, 13 Aug 2021 15:52:41 +0000
Message-ID: <ebe9719f35e54eef9cc954e6b67736a5@huawei.com>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@BY3PR05MB8081.namprd05.prod.outlook.com> <a1e378cd81e144adad89d38987a2cb47@huawei.com> <dfc0233d-4021-f127-545b-5d0cccd236f7@joelhalpern.com>
In-Reply-To: <dfc0233d-4021-f127-545b-5d0cccd236f7@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.172.135]
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/crCHaSvGoKRXp31B4LjC5Ji9WVY>
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 15:52:55 -0000

Hi Joel,

Since usually the set of resources are allocated on a subset of the nodes and links in the underlay network, there is a need to specify the sub-topology on which the resources are allocated. That's why we say "VTN is associated with a logical topology", and it aligns with what you said "it needs to be tied to a topology where it is supported". So, I hope we agree that it is "a set of resources provisioned in a sub-topology". 

And I agree we don't need to introduce a new topology identifier. There are well-defined mechanisms (e.g. MT, Flex-Algo) to specify the sub-topology, and it just need to refer to an existing "topology identifier".

As for "it is not a forwarding construct", may I know your definition of "forwarding construct"? To me the resources are allocated in the forwarding plane, thus it should be considered as a "forwarding construct". Please note this is a general discussion about the functionality of this construct, which can be applicable to different data plane encapsulations.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, August 13, 2021 9:30 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; teas@ietf.org
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
> 
> If, as per the bestbar draft and the discussion of VTN-ID on 6man, this
> construct is NOT a forwarding construct, then I do not see how it
> identifies a sub-topology.   It needs to be tied to a topology where it
> is supported.  But since it is not the forwarding construct, it doesn't need to
> identify that topology as far as I can tell.
> 
> Yours,
> Joel
> 
> On 8/13/2021 8:11 AM, Dongjie (Jimmy) wrote:
> > 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/d
> >>>> r
> >>>> 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/d
> >>>> r
> >>>> 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/t
> >>>> e
> >>>> as
> >>>> __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> >>> ROxL4C2
> >>>> _xNDCrPaNQ$
> >>
> >> _______________________________________________
> >> 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
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas