Re: [Teas] New term for the underlay construct used for slice realization
Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 17 August 2021 18:51 UTC
Return-Path: <vishnupavan@gmail.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 C9D4A3A2AA7 for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 11:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IeC0b_1k-mE2 for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 11:51:42 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09F33A2AAB for <teas@ietf.org>; Tue, 17 Aug 2021 11:51:41 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id f11so29047373ioj.3 for <teas@ietf.org>; Tue, 17 Aug 2021 11:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzRHcTFkqDZuvUaxe1zm7t25eppV63WFytejNZmpXWE=; b=Ek6he9OsNokgF5YOBLlBsDrvNqNibviYEE/dKENSZ1EtTa/u7rIf5Hc2N+6QwnOlxD B+SEr5vUjoa0Gzv0iTE+/ekXyP7JDo3y+Qw5vEKvS6gRQ7DBMhkXKPsvsd9c4tWqxtuL qvtJyFPcRxJvwTCWK6LnJBMai7yLfO0yH7b2DUKy36T+pAXrUlrrdYDuW+O4mkDRQdU6 1Tyunhz3NGM3drQXHfBEdXVEo6/XWbACOsAxTudU1O8nyzt23DFwBB45/bjVvYK2bbJI mr48h+IDQ8gre/5ZAHGBqeAMjGtxKNo4OMZfTBbxfISMcVTPvmVD90lcXtmHhFszuIye bNyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jzRHcTFkqDZuvUaxe1zm7t25eppV63WFytejNZmpXWE=; b=iBNMT0VkK4jHV5YdyDXeYzVcQSfMGPU5EOVT7uoa+bkys3Me77pVZ/YOpfVXrkPe1d clO7K8Xa2tbhRh0xRO6ugp+9Ag74EBIkZTwHxV+0ccFyMmTqjYmJb62ljhn+jn5a+8fM rioDwwGOlIvL0C3AM/OCNWytHJNXUhwkbFiAK+J3/onHylOrUK5YxIDOB+zQsPNzP8r7 4IMUa4cgJN2Ud8Gm4G7ro+GwCrNDLaYfoe1I6n+cjeQuYxgYDvzrNYA34VXAGe9FAgv5 RH5Xmomi7YjODctX5x2SKs4JRh7QtTfvpPDrFgysf5VYeuXaia3TD3LdAOVuxH9BfAC4 U9yA==
X-Gm-Message-State: AOAM531UZh8SQcsGh9l26mVAhCSHsnB6Ykf+exWcIQYsZRTqAE/NzSJp uQzrQ9q219jRIQkKc/5QRsqN9JxuoxoV4wwnn3G3Zmb1wpw=
X-Google-Smtp-Source: ABdhPJwcs1pmocyCgOM4m/SNSuBPtIEqftIk1oulyc1sWcNQ0sR9ASxTQqI2szdzwiSE5EMc8pLlbJmTJJ+6nfVoeVQ=
X-Received: by 2002:a02:cbb0:: with SMTP id v16mr4244284jap.114.1629226299909; Tue, 17 Aug 2021 11:51:39 -0700 (PDT)
MIME-Version: 1.0
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@by3pr05mb8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com> <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2> <00e401d78ee8$5ea55790$1bf006b0$@olddog.co.uk> <CA+YzgTt-kLPSStbgbWmeKJwO9Zggs+0M04BUUL-E7rg3nZ_zbQ@mail.gmail.com> <068f01d79388$f9144710$eb3cd530$@olddog.co.uk>
In-Reply-To: <068f01d79388$f9144710$eb3cd530$@olddog.co.uk>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 17 Aug 2021 13:51:28 -0500
Message-ID: <CA+YzgTtdSypUSsbDHZzsatP2EG2pzKO2WSGZ=7TkBMCuXveSag@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd6aaa05c9c5ce3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/U1bU_ENhUpf_9Fn5Lfc68R1dAbQ>
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: Tue, 17 Aug 2021 18:51:48 -0000
Thanks for the humble clarification! :) I understand that you don't want to put a name to the "collection of slice flows" that are mapped to (and use) a specific network resource partition (or group or pool). But I do want to ensure that the scope of the network resource partition is clearly articulated. I interpreted your response as there being a one-to-one mapping between the "network resource partition" and the "collection of slice flows" using it. Thanks, -Pavan (WG participant) On Tue, Aug 17, 2021 at 11:57 AM Adrian Farrel <adrian@olddog.co.uk> wrote: > Hi Pavan, > > > > > ** As a WG participant.. ** > > > > ** As a humble servant of the WG and pen-holder for the document ** > > > > > Adrian, Hi! > > > > > >> Why "resource partition"? Well it is a collection of "nodes, links, and > network > > >> resources that are marked within the network for use by a set of > network slice > > >> traffic flows". > > > > > > In the definition above, Is “resource partition” a collection of “items” > that are > > > marked within the network for “exclusive” use by a set of network slice > traffic > > > flows (slice aggregate)? Or can multiple slice aggregates use the same > resource > > > partition? > > > > I see that you have determined to introduce a separation between the > concept you call a “slice aggregate” and the resources used by that thing. > > > > I, on the other hand, had considered that the “resource partition” is the > set of resources available for / used by the collection of slice flows, and > that there is no need to introduce a separate construct. That is, in one > hand you have a set of slices each comprised of one or more traffic flows, > and in the other hand you have a network. You map one to the other by > associating slice flows with the resources they can use. > > > > There could be a debate about “resource sharing”. That is, when resources > in one partition are not being used, can they be “borrowed” by another > partition? I suppose the answer is yes, but I wonder how both slices can > guarantee the service SLAs if the resources they use are not guaranteed to > be available. This is considerably different from borrowing resources for > best effort traffic, which can happen in any resource reservation scheme. > > > > Regards, > > Adrian (as a humble WG participant and pen-holder for the document) > > > > > Regards, > > > -Pavan (as a WG participant) > > > > > > > > On Wed, Aug 11, 2021 at 2:38 PM Adrian Farrel <adrian@olddog.co.uk> wrote: > > I wonder whether we can pick this apart and put it back together in a way > that makes sense. > > The customer's view of all this is an "IETF network slice service". I think > (hope) we are all agreed on this. The customer may ask (in shorthand) for a > "network slice", but: > - they are talking about IETF technology, so they asking for an "IETF > network slice" > - they actually want behavioural characteristics and have no right to tell > the operator > how to manage the network, so they are asking for an "IETF network slice > service." > > The operator has a bigger set of things to worry about. > > 1. At the top of the operator's view is the "IETF network slice service" as > requested by the customer. We have this defined already, so nothing > more > to say. > > 2. The operator maps the request for a slice service into the "IETF network > slice" which is the expression of the service in terms of network > connectivity > in the context of the operator's network. The relationship here is like > the > relationship between the L3SM and L3NM. > > 3. At the bottom of their view is an underlying network. The technology of > this > network depends, of course, on the operator's offering, but this is the > network > technology being sliced. It may be an IP network, and MPLS network, an > OTN, > or whatever. I would call this the "Underlay Network." This network may, > in > turn, be built upon an underlay network of the same or a different > technology, > and it may be facilitated through network slicing - but this need not > concern > us here. > > 4. That leaves the glue in the middle: the bit that enables the scaling and > maps > the network slice to the network. And I think it is this bit that is > causing the > most debate about terminology. There are some points to consider: > > a. The term "network resources" applies to the bandwidth, queues, > buffers, > etc. available on the links and nodes in the network. That may be > extended to refer to whole links and nodes. > > b. The number of IETF network slice services is potentially large and > the > operator needs a mechanism to scale the mapping of services to > network resources. > > c. The IETF network slices may be grouped for identical treatment to > achieve scaling, where the grouping collects IETF network slices > with > similar SLAs. > > d. It may be that different traffic flows within a single IETF network > slice > have different characteristics. In this case, it may be beneficial > to group > together some of the traffic flows from different slices. > > e. The grouped slices/flows are enabled in the network using network > resources assigned for that purpose. The assignment may be anything > from a fully-fledged virtual network (such as in ACTN or VPN+), > through > network reserved resources (such as in MPLS-TE), and centrally > accounted resources (such as SDN or possible SR), to statistically > shared resources. > > There seems to be various points for and against 4d. But, it would appear > that this is an implementation or deployment issue that doesn't change what > the protocols need to do. So we should probably allow it architecturally, > or > at least, not disallow it. > > Of course, as Kiran points out, 4c/d/e may be a pass-through. That is, it > is > not necessary to implement such groupings either because there are only a > few slices (which has been the view of some operators) or because the > network systems can handle the number of slices. And it is in the nature of > architectures of this sort that all functions can be nulled out without > loss > of generality, and we have to recall that the internals of provisioning > systems may appear as functional blocks in our architectures, but we don't > compel implementations to adhere to that type of architecture. So I don't > think we have to worry on that account. > > And that brings the question of how we name the resources that are gathered > in 4e. > > I can't decide whether it is helpful to spend time saying why I don't like > each of the proposed terms. I certainly have things I don't like about (for > example) "slice aggregate" (because of 4d, which means it is really a > "slice > sub-flow aggregate"), and I am not a fan of "VTN" (because of "transport" > and maybe it is not really a network). But maybe it is better for me to say > what I think we should call things? I think we have... > > - IETF network slice service (customer view) > - IETF network slice (operator view) > - Resource partition (delivery mechanism) > - Underlay network (network used to support the slice) > > Why "resource partition"? Well it is a collection of "nodes, links, and > network resources that are marked within the network for use by a set of > network slice traffic flows". > It is possible that the word "partition" is too strong because it may imply > to some people that resources in a partition cannot be shared, but I don't > feel that. > Softer words than "partition" would be "group", "bundle", "pool", and I > could live with any of them. > > Best, > Adrian > > > -----Original Message----- > From: Teas <teas-bounces@ietf.org> On Behalf Of Kiran Makhijani > Sent: 11 August 2021 16:00 > To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>; Dongjie (Jimmy) > <jie.dong@huawei.com>; Lizhenbin <lizhenbin@huawei.com>; teas@ietf.org > Subject: Re: [Teas] New term for the underlay construct used for slice > realization > > Hi John, (and all), > > Two very basic clarification questions: > 1. How do we differentiate between the slice-segments that are > resource-aware vs those that are not? I had assumed that since a slice > has an SLO, it will need network resource allocations in some form. > > 2. Is it ok to assume that the customer view of slice is an 'IETF > network slice service' and the 'IETF slice realization' of that service > in a provider network is raises the question of underlay and overlay > constructs. Am I right? > (a) if so, then we are acknowledging the presence of another layer of > abstraction (for realization). It could be underlay/overlay or > aggregate/??. Then the term 'slice aggregate' is better and my > preference, it is easier to see that different slice-services are > aggregated into a single construct in a provider network. Use of > underlay/overlay are confusing. > (b) for a leaner provisioning, I would also prefer to see it documented > that the aggregate is optional and it should be possible to directly map > a slice-service to physical or real resources in the network. > specifically useful when a single domain is carving out slices for > different purposes. > > Thanks > Kiran > > > ------ Original Message ------ > From: "John E Drake" <jdrake=40juniper.net@dmarc.ietf.org> > To: "Dongjie (Jimmy)" <jie.dong@huawei.com>; "Lizhenbin" > <lizhenbin@huawei.com>; "teas@ietf.org" <teas@ietf.org> > Sent: 8/11/2021 5:38:05 AM > 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>; Lizhenbin <lizhenbin@huawei.com > >; > >>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/draf > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> > >> > 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/draf > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> > >> > 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 > <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/teas > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas> > >> > __;!!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 > >
- [Teas] New term for the underlay construct used f… Lizhenbin
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… gregory.mirsky
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Kiran Makhijani
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… gregory.mirsky
- Re: [Teas] New term for the underlay construct us… Gyan Mishra
- Re: [Teas] New term for the underlay construct us… Kiran M
- Re: [Teas] New term for the underlay construct us… Gyan Mishra
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Luis M. Contreras
- Re: [Teas] New term for the underlay construct us… Tarek Saad
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Kiran M
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… Dongjie (Jimmy)
- Re: [Teas] New term for the underlay construct us… Joel M. Halpern
- Re: [Teas] New term for the underlay construct us… Igor Bryskin
- Re: [Teas] New term for the underlay construct us… peng.shaofu
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… Lizhenbin
- Re: [Teas] New term for the underlay construct us… John E Drake
- Re: [Teas] New term for the underlay construct us… 龚立艳
- Re: [Teas] New term for the underlay construct us… Lizhenbin
- Re: [Teas] New term for the underlay construct us… Tarek Saad
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram
- Re: [Teas] New term for the underlay construct us… Adrian Farrel
- Re: [Teas] New term for the underlay construct us… Vishnu Pavan Beeram