Re: [Teas] New term for the underlay construct used for slice realization
Gyan Mishra <hayabusagsm@gmail.com> Thu, 12 August 2021 01:00 UTC
Return-Path: <hayabusagsm@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 049933A2D6F for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 18:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 G9ItTjMEwawF for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 17:59:54 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 D35A43A2D69 for <teas@ietf.org>; Wed, 11 Aug 2021 17:59:54 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id d17so5010634plr.12 for <teas@ietf.org>; Wed, 11 Aug 2021 17:59:54 -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=XNCCEJdMXo59Ji5e6PnUKLKTRujnAbSoK0CWhB3erjQ=; b=Lqz13owNKpB1kk0j4Wu1v0GGylg6ItMtkZKWCtobIdVp/V0AD6aG2w6NNzckIK1S1B 5hKqIsFPPc/3i4+pzBNGfeyAET/uEaEFgfcUf+jCbeGs/Ovi+J2UgS+Kolyhhh89Niy1 bOisLrsXM8bBZdFD3plraJGOgDv1udyt6POB04KLAXMMsmMgksjVNIrbBundDOCsy85/ EvcOVwbr6zCDg2+pSE2kof7mJB+UHMsHMPgj8NDnY9XQglEw4h2AYxV9XJ5sTj/aE6/a Qs2ceFaV3RWjzSzdZD/nr8kpeS1yDcw1cO9rSjuDKtg+DhbewemEwb8l9XQXdmPNaQq7 s60g==
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=XNCCEJdMXo59Ji5e6PnUKLKTRujnAbSoK0CWhB3erjQ=; b=camCH+ooqDkm7fBFj0DahTAa5t97u8y3E48Kwzl+B5bM/MMmRJ+D3sSxfjstmrBTdD vBH7DIDIkVT8kypfSpEXT+F6w1mqIrwrnv7vhFgz/IWkqbOz/J7qqWu9nw1rHL2zkAwu s8HlGEtPRQGdsHg4w/YE25oDuULyS8lWun4tm668mbwn6nLoFB5qfkLaKawSVP00R/F5 1d7fZRdtK5eB/Y9v4mn/hZdICPCwwyKIiDAi7EIgy+sKgS9/2sba8LUqhWItT0Y2QADT LG68p/+U+ycQWmo3RCBzwiU9M+MsyF6N8rZK/slQiaibhCA3jUxf3LLnvzN7lmvn+19Z B2gA==
X-Gm-Message-State: AOAM531fT/xHPVmaSHiPztDu0GOLLuGdYnLG9fjqjM7NuEOTo+AS/HC2 5cxtItMog+0TOnYN2ycptzjp25hF36DjC17RXB8=
X-Google-Smtp-Source: ABdhPJw0SbPY9jcwK1pPX3ipgVx1zMqG7zhao1Xuz5To1B9dQELuJ5OpCROyafWZziSqKu5eFSVS/SU5J8dSF5XnL/Q=
X-Received: by 2002:a63:504a:: with SMTP id q10mr1368710pgl.383.1628729993373; Wed, 11 Aug 2021 17:59:53 -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> <em1310ead9-1b78-4908-80a4-1767f5357260@tromso.local>
In-Reply-To: <em1310ead9-1b78-4908-80a4-1767f5357260@tromso.local>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 11 Aug 2021 20:59:42 -0400
Message-ID: <CABNhwV1S4CkSWj3geAk-M1EYJMG5Bu9dQ2GR1zj07aPLYPOKYw@mail.gmail.com>
To: Kiran M <kiran.ietf@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Lizhenbin <lizhenbin@huawei.com>, adrian@olddog.co.uk, teas@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b0ab3805c952405b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/jcL69K_xcq1H8WGXVN574arGF3k>
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: Thu, 12 Aug 2021 01:00:02 -0000
Hi Adrian Excellent job breaking this down and making it clear to all of us!! The term partition is strong as I agree it implies underlay resources that are not shared, however group sounds like a perfect. Pool goes to far in the other direction as if all resources are shared. Bundle I think is at about the same as far as right context in line with group implying shared resources. However I think from a nomenclature perspective I like group better. Kind Regards Gyan On Wed, Aug 11, 2021 at 8:28 PM Kiran M <kiran.ietf@gmail.com> wrote: > Hi Adrian, > Thank you for breaking it down clearly. It helped me see the delta due > to use of term 'IETF network slice service’ instead of just slice. > > In this 4-tier architecture (for the sake of convenience), few things > could be documented after clarification: > > 1) is it mandatory that operator must have an 'IETF Network slice > instance' to realize an IETF network slice service? > - One of the things we discussed early on was that it should be > possible to map a customer’s network slice request even when the > operator does not have slice-infrastructure. This is why Southbound > interface had lot of discussions on using existing data models. Should > we now redefine what a SBI would be? Is it between 2nd and 3rd tier? > Should architecture allow 1st to 3rd? Since resource-partitioning is an > important part of slices should we name the interface between 3rd to 4th > tier? > > 2) in order to scale the slices, hierarchical slices were defined. The > stitching could be done horizontally or vertically over the > resource-partitions. are they still needed in this architecture. > > In my mind, what you call a resource partition is nothing but an > abstraction of connected network resources (vaguely resembles the > definition of slice, isn’t it?). What happens above that is an > orchestration on different slice segments to produce the desired > effects. > > So I think, with this architecture we would need to clean up/edit the > text on 3 items in the document - SBI, optionality of 2nd tier (if you > agree - related to your 4c/d/e), section on hierarchical structure. > > Thanks > Kiran > > On 8/11/2021 12:37:49 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 > >>> > 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 > >>> > 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/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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [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