Re: [Teas] New term for the underlay construct used for slice realization
Kiran Makhijani <kiran.ietf@gmail.com> Wed, 11 August 2021 14:59 UTC
Return-Path: <kiran.ietf@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 6BB9A3A1971 for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 07:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 dhsGpcEAqAzS for <teas@ietfa.amsl.com>; Wed, 11 Aug 2021 07:59:51 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 765183A193F for <teas@ietf.org>; Wed, 11 Aug 2021 07:59:50 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id d1so3082688pll.1 for <teas@ietf.org>; Wed, 11 Aug 2021 07:59:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=dr+m7Vw+My3A5Zv/jOlQsg+XWNKqjCsP3E8dpchBJvE=; b=jMFaZvoDyM/LBa8fbO6eQl9SBYck4n7nWy77ZqSHbfyYEqoORZkp0EkqQjz+qdWm2M 55F+2K/7mKYnTpbGDyy3jIX3+diEHBt8gNxNK6t6zLyINI2WBINWztsWAQPrtyUbnOnm USu9FXZemAEXrX0nawFc5LrdFuXEnBEJStZW5MP4AbcrIDZriK3atANhqcTqy8Kl7Ur0 aPNgfMLI9uFd7dTRW1XvlZMP08Mr1loR696lB0SPknaMA/PSUjQaldaXYQgr3IjPFy8h oRmJ4HTQS7K3H2YLQcVMOmbgHy0ihFSBrVEYbgBq1RTLz2BsQCwWyt8p7FBMT0b4EZFD naow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=dr+m7Vw+My3A5Zv/jOlQsg+XWNKqjCsP3E8dpchBJvE=; b=tUSE/NBV7ATfbVjwGsTRvMy1m8HdVFBfdHqRzUUuhyXByewur6OVWhIcNHiefnTkL9 gSyLYj+b0ED3B4p8Tj9LFT/I/ZeSLbDsJYw64guq92Ud9kObkNNqluG0sDEWszWM/HYI REq6hJHSFP366sVUGT3Ad3TEInVnbccnh41x45QzCU7jx8XUrGrXKpo64doAQySqpFKR ZZl3Ndno2KmRMyT5PAwCvk/pTp4b0wLUwFfVvvRX9053Gthv7Jqc0aWkV5CAY+dOTn3f iEcgZNOiHhhIg22SP4+SDOlUcfx6vsvsJz6WJhI7wMKZv9sUFaUt4AIhHi2qm18nE7OP 092Q==
X-Gm-Message-State: AOAM532u+yjE1Ebo1OYJ0keMuKrIf96XuDAR8WA+01FMxaDSv4IDTHmm EyChdGASZAZhFvTzBqkeZiU=
X-Google-Smtp-Source: ABdhPJz5WkEwoKktimZxQEMpK9/EabUhlMvjK+zIdheLOQOIkxW3mtAPqtQ/q+6xT2FShJUelVCOBA==
X-Received: by 2002:a05:6a00:2b5:b029:3bc:3183:c370 with SMTP id q21-20020a056a0002b5b02903bc3183c370mr34565276pfs.68.1628693988654; Wed, 11 Aug 2021 07:59:48 -0700 (PDT)
Received: from [192.168.1.54] (c-73-202-182-183.hsd1.ca.comcast.net. [73.202.182.183]) by smtp.gmail.com with ESMTPSA id s5sm22416331pji.56.2021.08.11.07.59.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Aug 2021 07:59:48 -0700 (PDT)
From: Kiran Makhijani <kiran.ietf@gmail.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Lizhenbin <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Date: Wed, 11 Aug 2021 14:59:47 +0000
Message-Id: <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2>
In-Reply-To: <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@by3pr05mb8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com>
Reply-To: Kiran Makhijani <kiran.ietf@gmail.com>
User-Agent: eM_Client/8.2.1473.0
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/kjAPyEVGRTv6iOIFOIE3BPIeEwU>
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: Wed, 11 Aug 2021 15:00:06 -0000
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] 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