Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Joel Halpern <jmh@joelhalpern.com> Sat, 21 May 2022 17:25 UTC

Return-Path: <jmh@joelhalpern.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 D07DAC397F58 for <teas@ietfa.amsl.com>; Sat, 21 May 2022 10:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoZBGOpMqq05 for <teas@ietfa.amsl.com>; Sat, 21 May 2022 10:25:41 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F0BC2B71DB for <teas@ietf.org>; Sat, 21 May 2022 10:25:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4L59Tx08gqz1pVtM; Sat, 21 May 2022 10:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1653153941; bh=MZ/KXpzhYji+6Ta9bGYIjY8gBBL+m8MC4p0KajoI4h4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YUWqD9jRbCP4FUKjVDkR4GQ7ZoZURRmvZraihyGzvK21M8u7V2NXskqj9mwUmczjG uaOrUZ31bq6cY6/iqS4UcHYPSdgiwvLF9SKv0dbSFQYITpVZvF2hTN1clCS+f7aBv4 8t9p/YxbYp9A8cNJ73/xYy1YvvvkJTGrDuMXR1s4=
X-Quarantine-ID: <1ar0VuVtt4kD>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.20.80] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4L59Tw2k6vz1pKsn; Sat, 21 May 2022 10:25:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------DwlDW1JSBgKMNLeRfTy4P9VZ"
Message-ID: <fbee9424-2ce6-9b67-7e50-cadd63881fdd@joelhalpern.com>
Date: Sat, 21 May 2022 13:25:39 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
Cc: teas <teas@ietf.org>
References: <921D62D1-CB07-49FC-BD46-E7E1A1DDD31D@gmail.com> <F7E81387-F400-4680-9589-B81535723E59@gmail.com> <BY3PR05MB8081F5877450A2F76BB88199C7D09@BY3PR05MB8081.namprd05.prod.outlook.com> <5b725b68b16049e99e689c3be36cd6a0@huawei.com> <BY3PR05MB8081DFB88AF6D6A9EF64B3B8C7D09@BY3PR05MB8081.namprd05.prod.outlook.com> <4d81c9d54f384bb59cadaaaff1d7daa3@huawei.com> <27948_1653028835_628737E3_27948_6_1_40684ce0704f49ccb6d587cdeaf59299@orange.com> <f10db247201044dfbeee72dea75a524e@huawei.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <f10db247201044dfbeee72dea75a524e@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Wud_KonJNUx5T2NuzKQDhGYjcDE>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.34
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: Sat, 21 May 2022 17:25:44 -0000

I am not sure that your analogy holds across the usages.  I have seen a 
number of descriptions which treat the normal traffic flow as going over 
a default network slice.  As such, that is treating the whole network as 
a default partition and a default topology. I am also struck that while 
we do need to agree on how to refer to this, it is much less significant 
than most of the other aspects we are discussing.

Yours,

Joel

On 5/21/2022 3:00 AM, Dongjie (Jimmy) wrote:
>
> Hi Med,
>
> Thanks for providing your view on this.
>
> I fully agree that the number of NRPs can be dynamic and will increase 
> from a small number to a large number based on the service demands.
>
> While my point is when we introduce the first NRP into a network, it 
> will make the network two separate sets: the first NRP, and the rest 
> of the underlay network (which may be called the default NRP).
>
> This is similar to the VPNs (although at a different layer): when the 
> first VPN is introduced into the network, the PE nodes need to 
> maintain two separate routing tables, one for the VPN instance, 
> another one is the default routing table.
>
> Thus IMO the introduction of the NRP concept and its instantiation to 
> the network will make the underlay network at least two partitions. 
> And it is better that a legacy network with the physical underlay 
> network as a whole not be called an NRP, just like we do not call the 
> public internet a VPN.
>
> Best regards,
>
> Jie
>
> *From:*mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
> *Sent:* Friday, May 20, 2022 2:41 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>; John E Drake 
> <jdrake@juniper.net>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>; 
> adrian <adrian@olddog.co.uk>
> *Cc:* teas <teas@ietf.org>
> *Subject:* RE: [Teas] [E] Re: Slicing Framework Open issue #1 : 
> Service != Realization
>
> Hi Jie,
>
> We should not forgot network dynamics: the number of NRPs won’t be 
> frozen, not the underlay networks themselves (think about network 
> merging and splits that are happening while the above services are 
> still offered to customers).
>
> There is nothing wrong that a deployment starts with a single NRP to 
> address a specific service case and then adjust the tweaking to 
> address other vertical needs (if/when they come).
>
> What actually matters is not whether one can call the whole physical 
> underlay network an NRP, but how introducing the concept of NRP will 
> allow to manage smoothly the dynamics mentioned above.
>
> From a technical standpoint, I don’t think we can impose a minimum # 
> of partitions to start make use of the NRP concept.
>
> Cheers,
>
> Med
>
> *De :*Dongjie (Jimmy) <jie.dong@huawei.com>
> *Envoyé :* vendredi 20 mai 2022 03:54
> *À :* John E Drake <jdrake@juniper.net>; Krzysztof Szarkowicz 
> <kszarkowicz@gmail.com>; adrian <adrian@olddog.co.uk>; BOUCADAIR 
> Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* teas <teas@ietf.org>
> *Objet :* RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service 
> != Realization
>
> Hi John,
>
> Please see inline.
>
> Best regards,
>
> Jie
>
> Juniper Business Use Only
>
> *From:*Dongjie (Jimmy) <jie.dong@huawei.com>
> *Sent:* Wednesday, May 18, 2022 9:52 PM
> *To:* Krzysztof Szarkowicz <kszarkowicz@gmail.com>; John E Drake 
> <jdrake@juniper.net>; adrian <adrian@olddog.co.uk>; mohamed.boucadair 
> <mohamed.boucadair@orange.com>
> *Cc:* teas <teas@ietf.org>
> *Subject:* RE: [Teas] [E] Re: Slicing Framework Open issue #1 : 
> Service != Realization
>
> *[External Email. Be cautious of content]*
>
> Hi Krzysztof and all,
>
> Most of this text looks good to me except the last sentence. "A single 
> NRP with the resources of the entire underlay network" is the same as 
> a network without network resource partition. I think we agreed that 
> an NRP refers to a subset of the underlay network resources (e.g. a 
> subset of the buffer/queueing/scheduling resources), thus it is 
> different from the whole underlay network.
>
> *//*
>
> */[JD]  A subset can consist of the entire set /*
>
> [Jie] Maybe this is true in general, while I’m not sure such 
> generalization is helpful in the context of network slicing. Do you 
> consider the whole physical underlay network can be called an NRP?
>
> *//*
>
> */[JD]  Absolutely/*
>
> [Jie #2] Fine, then we could also generalize that network slicing is 
> already supported in legacy networks for yearsJ
>
> That said, an NRP may have the same topology as the underlay network.
>
> IMO we need to keep in mind that resource and topology are two 
> separate attributes of an NRP.
>
>
> Best regards,
>
> Jie
>
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas