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

Krzysztof Szarkowicz <kszarkowicz@gmail.com> Thu, 19 May 2022 07:49 UTC

Return-Path: <kszarkowicz@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 36A3CC14F687 for <teas@ietfa.amsl.com>; Thu, 19 May 2022 00:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6_dzOfM1dfL for <teas@ietfa.amsl.com>; Thu, 19 May 2022 00:49:01 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 907B2C14EB1F for <teas@ietf.org>; Thu, 19 May 2022 00:48:56 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id c2so4091024plh.2 for <teas@ietf.org>; Thu, 19 May 2022 00:48:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WacW1JSZaE3Usnra2r8/eKjcBf2lxDPdcOh5cHX8XZY=; b=BFzoBcJpEmyjfcvHBOGj/62nBrgD/cocTC1VUz4YVi2Oeb+mUv9vP5Ng18q0T44Acj h5GF4ce4A8nRxKo/Vkb3cNAuLcoKKk+Ugq/RTzxA55c702X3nMrM6zWgQE1//oYLiqOJ X3o5T4ybTU9UBFVPQXJo/VUHq0o7fXHaL8Wi+fp6mzc4ztWI14prcSm6VMxCe5L1Qghv 9nIKfm8/qYEg+1eD1z27vlQTya9GY5w9/HbbEZAFoR59O22NKhKW0TvF3wqUUALKBTOn ANTLZVZf7L8hqhN9RugrhchW/WmgNWDcWgXua2wb6/UUGf7wT7at3qf0wVyc47Q8Ng+L JJ7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WacW1JSZaE3Usnra2r8/eKjcBf2lxDPdcOh5cHX8XZY=; b=bsukr3PcQnkpDyimgskRUFUTdXKR4obN7vim0u0P91WJx1UN7QjJnTbDrt5TwPIDHz HdptrUmHGd1n+cg1HnugwV30Vmxv/4u/66wfcQ3708Sr4W4DYCB3uN707H8L/vM/A37o N12aCIrgB6MdkocVmG9P5j/OnhkaFhknhwDjgWcgvi1FJ/sO15KS6Z0mV5RPhszdwa9z 7pLnqwzPicoo2MYo7pp+jTN/ISnMpS2h6d2NKoeCmqWlO17hBUt1UZC5n0xYHVZgfY07 eQitEZcPUy/UeEgj4OnH0Fd+HNkmB8KqHoqYGhj2EyyKIaCdxu98PVlqOMggmV9vcMWo kbCg==
X-Gm-Message-State: AOAM531oUmn1XbF6rnsn0ipj4qUB9QS9ILkZ4QWegK/3Ej0pFuent2Yz ID1mgqd+1qILPOksbD9NgUw=
X-Google-Smtp-Source: ABdhPJxcG7PAEtAuFcS455QPh4iduZFr/K6wySrUvVIb/akkjEEFNxbZ8nmXerLcPj5SSnp8E/urPQ==
X-Received: by 2002:a17:90b:3708:b0:1df:56ac:65c6 with SMTP id mg8-20020a17090b370800b001df56ac65c6mr4445189pjb.23.1652946535408; Thu, 19 May 2022 00:48:55 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat12.juniper.net. [193.110.49.12]) by smtp.gmail.com with ESMTPSA id bf7-20020a170902b90700b0015f2e3e495asm3001814plb.239.2022.05.19.00.48.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 May 2022 00:48:54 -0700 (PDT)
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Message-Id: <5C49774F-C132-47A5-BD19-54F2541A4B15@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F868F4C-D3A7-445F-9905-2E671C0F1C17"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Thu, 19 May 2022 09:48:44 +0200
In-Reply-To: <BY3PR05MB8081272AF157CD283EB530DBC7D19@BY3PR05MB8081.namprd05.prod.outlook.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>
To: John E Drake <jdrake@juniper.net>
References: <042601d84029$1de567c0$59b03740$@olddog.co.uk> <501D30C7-5DE7-45E9-86EC-0A6665319F02@gmail.com> <2d25ec2c0b164146aeadb09aadcfa66b@huawei.com> <DF539A34-AD85-4666-9704-EB7EA8B3BA1A@gmail.com> <411896c7b1c94b4997dca596df3828bf@huawei.com> <333A778F-B542-4CD6-80B5-0FD639DE2C44@gmail.com> <621779c1e05c48eda022dc051d182f9d@huawei.com> <B67E6A59-1878-462F-8D5A-AB027051274F@gmail.com> <2e60088e815d4081a71bede289f752ae@huawei.com> <756B77A9-B393-4FEA-A25D-224A9097D4D5@gmail.com> <aa1fcaa639ce4aed8555a0513fe2c59e@huawei.com> <BY3PR05MB8081EE86385E627E2BF4E9C8C7FA9@BY3PR05MB8081.namprd05.prod.outlook.com> <8601ab681f5c415bb0a1eaaf9c0f2576@huawei.com> <BY3PR05MB8081D3CFB2F1B47EE47878BBC7FD9@BY3PR05MB8081.namprd05.prod.outlook.com> <3f314d1be1c54ac6bc4d4cd4a6e833f8@huawei.com> <BY3PR05MB80814A03CBB3954501AF2CA5C7FD9@BY3PR05MB8081.namprd05.prod.outlook.com> <921D62D1-CB07-49FC-BD46-E7E1A1DDD31D@gmail.com> <F7E81387-F400-4680-9589-B81535723E59@gmail.com> <27ff69a9-e18e-c663-3a43-8d50c44aabd9@joelhalpern.com> <BY3PR05MB8081272AF157CD283EB530DBC7D19@BY3PR05MB8081.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/zoFIVC_y2IZalH0jej6lKSlClQg>
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: Thu, 19 May 2022 07:49:06 -0000

+1

> On 2022 -May-18, at 21:40, John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>> wrote:
> 
> Joel,
>  
> You’re correct.  A long time ago, I had said that an NRP consisted of a subset of the buffer/queuing/scheduling resources on each of a connected set of links in the underlay network.  The connected set of links can be the entire set of links in the underlay network and in this case there can be a single NRP and it has the all of the buffer/queuing/scheduling resources for each of the links in the underlay network.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Joel Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> 
> Sent: Wednesday, May 18, 2022 3:25 PM
> To: Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>; Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>; John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>
> Cc: teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> [External Email. Be cautious of content]
>  
> I mostly like that.  But there is a dimension that I am having trouble mapping to the text you provide.
> 
>  
> 
> The case that persuaded me to get interested in NRP in the first place was queueing resources.  (Specifically, the fact that for SR-MPLS the 8 diffserv code points are not enough to represent the needed range of queueing behaviors.)  How does that relate to the text you have below?  It has little or nothing to do with the topology.
> 
>  
> 
> Yours,
> 
> Joel
> 
> On 5/18/2022 3:16 PM, Krzysztof Szarkowicz wrote:
> Hi,
>  
> So, do we have agreement for following change:
>  
>  
>           An NRP is simply a collection of resources identified in the underlay network. The amount and granularity of resources allocated in different portions of an NRP can be flexible. Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one possible case is that the entire underlay network topology is used by all the NRPs. Some realization might as well use single NRP only with the resources of the entire underlay network topology.
>  
> Best regards,
> Krzysztof
>  
>  
> 
> On 2022 -Apr-29, at 14:57, Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> wrote:
>  
> So, 
>  
> Are we OK now? From my perspective it look good.
>  
> Best regards,
> Krzysztof
>  
>  
> 
> On 2022 -Apr-28, at 16:58, John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>> wrote:
>  
> And I think it’s incorrect
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> 
> Sent: Thursday, April 28, 2022 10:57 AM
> To: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> Cc: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> [External Email. Be cautious of content]
>  
> Hi John,
>  
> The sentence you quoted was the last sentence in Krzysztof ‘s proposal, and I just reused it in my proposed text:
>  
> “… where the entire underlay network topology is used by all NRPs.”
>  
> Best regards,
> Jie
>  
> From: John E Drake [mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>] 
> Sent: Thursday, April 28, 2022 8:28 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> Cc: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> The text that I thought was incorrect:  “, one possible case is that the entire underlay network topology is used by all the NRPs.”
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> 
> Sent: Thursday, April 28, 2022 12:56 AM
> To: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> Cc: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> [External Email. Be cautious of content]
>  
> Hi John,
>  
> My understanding is that when NRP is introduced to the network for supporting IETF network slices, there would be at least two NRPs. Only one NRP with the entire underlay network topology would be same thing as the underlay network, do we need to call it an NRP?
>  
> Besides, the text I proposed is general and can even apply to the “one NRP” case you mentioned.
>  
> Best regards,
> Jie
>  
> From: John E Drake [mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>] 
> Sent: Wednesday, April 27, 2022 9:15 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> Cc: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi,
>  
> I don’t think the text identified with [jie#4} is correct, because in the limiting case there is only one NRP and it consists of the entire underlay network topology.  I think this was what Krzysztof and Med were noting, and adding a simple statement of this in the Framework draft would make sense. 
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> 
> Sent: Wednesday, April 27, 2022 5:52 AM
> To: Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> [External Email. Be cautious of content]
>  
> Hi Krzysztof,
>  
> Please see inline [Jie #4]:
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Tuesday, April 26, 2022 2:47 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
>  
> Please see inline [Krzysztof #3]
>  
> 
> On 2022 -Apr-26, at 05:18, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi Krzysztof,
>  
> Please see inline [Jie #3]:
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Tuesday, April 26, 2022 4:58 AM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
> Please see inline [Krzysztof #2]
>  
> 
> On 2022 -Apr-21, at 09:41, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi Krzysztof,
>  
> Please see inline with [Jie #2]:
>  
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Wednesday, April 20, 2022 11:23 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
> Please see inline.
>  
> Thanks,
> Krzysztof
>  
> 
> On 2022 -Apr-20, at 10:31, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi Krzysztof,
>  
> Please see some replies inline:
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Tuesday, April 19, 2022 12:17 AM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
> I still see tight coupling between NRP and the topology. There will be realizations that do not use topology filtering (i.e, multiple NRPs use the same topology -> potentially entire network), so I am not sure, why realization with coupling between topology and NRP is so emphasized, while other realizations are not.
>  
> [Jie] Totally agree that multiple NRPs can share the same topology, and as you said one extreme case is that the NRPs are created using the base topology of the network. While in any of these cases, an NRP needs to be associated with a topology to determine the set of links and nodes involved for resource management/reservation and path computation of the NRP.
>  
> That said, I agree that topology filtering is just one optional approach to determine the topology of the NRP, and may not need to be highlighted in the text.
>  
> What about following text (or something like that):
>  
>  
>       An NRP is simply a collection of resources identified in the underlay network. The details about tracked resources might depend on NRP realization. Some NRP realizations might put more focus on transport access resources, while some other NRP realizations might focus on transport core, or both transport access and transport core resources. Furthermore, some NRP realizations might build on tight coupling of an NRP with underlying filtered topology, while some other NRP realizations might not use separate filtered topologies at all. The framework is open for different NRP realizations, but the details of these realizations are out of scope for this document.
>  
> [Jie] I’m not sure whether it is needed to mention access/core as they are only applicable to specific network types. And the term transport has been proved controversial in the past.
>  
> [Krzysztof] I am OK to change the terms for something different, to be more technology agnostic. What I would like to see as the outcome of the framework document is, that different NRP realizations might have different focus on then granularity of resource tracking in different part of the underlay network. I.e.,  as a simple example, in case of packet switched network as the underlay technology, realizing e.g. P2P service slice might be achieved by kind of converting the packet switched network to circuit switched network (with granular tracking of resources across the entire path used for service delivery), but some other realization of such P2P service might only track the resources with high granularity at the access (AC), and use other techniques in other parts of the network to realize the service. 
>  
> I see the framework document should address that, without calling any technology details.
>  
> [Jie #2] I can understand your point that the amount and granularity of resource management/reservation (I guess it is what your called resource tracking) for an NRP does not have to be the same everywhere, aggregation or sharing with certain criteria could be allowed.
>  
>  
>  [Krzysztof #2] Indeed. Moreother, some NRP realizations might focus (=more granular resource management/reservation) in part ‘X’ of the network, while less granular in part Y, whole some other NRP realization just to the opposite - more granular in part Y, while less granular in part X. I see this should be somehow captured in the framework.
>  
> [Jie #3] I think there could some text about the different granularity of resources for NRPs.
>  
> [Krzysztof #3] I proposed some text regarding to this referring to ’transport access’ and ’transport core’. You didn’t liked this terms. So, can you propose some text?
>  
> [Jie #4] How about some text like this:
>  
>           An NRP is simply a collection of resources identified in the underlay network. The amount and granularity of resources allocated in different portions of an NRP can be flexible. Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one possible case is that the entire underlay network topology is used by all the NRPs.
>  
>  
>  
> 
>  
> 
>  
> Regarding the relationship between NRP and topology, here is my suggested text:
>  
>                Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may use shared topology for multiple NRPs, one extreme of which is to use the entire underlay network topology for the NRPs.
>  
> [Krzysztof] What about following text:
>  
>      Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may use shared topology for multiple NRPs. Some realizations might even not use NRP topology differentiation at all, where the entire underlay network topology is used by all NRPs.
>  
> [Jie #2] I see we are converging on this. The remaining small difference is whether all NRPs built on the entire underlay network topology can be seen as a special case of “multiple NRPs sharing the same topology”.  
>  
> The main point of this text is an NRP is associated with a topology, which can be either a dedicated topology or a shared topology, and can be either a sub-topology or the entire underlay network topology. 
>  
> Thus I’d prefer an description with enough generality, then the special case could be described under the general statement. What do you think?
>  
> [Krzysztof #2] I am nart sure, what text are you proposing.
>  
> [Jie #3] The generic text I propose is similar to what is in my previous mail:
>  
> Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one extreme case is that the entire underlay network topology is used by all the NRPs.
>  
> [Krzysztof #3] What is ‘extreme’ for one realization, can be considered as ’normal’ (default) for another realization. So, my proposed text was avoiding such verbiage.
>  
> [Jie #4] In my understanding, “each NRP with separated topologies” and “all NRPs with the same topology” are the two extremes of the solution space. And please see the modified text in reply to your last comment. 
>  
> Best regards,
> Jie
> 
>  
> Please note that using shared topology for multiple NRPs is considered as one optimization approach in draft-dong-teas-nrp-scalability.
>  
> Best regards,
> Jie
> 
>  
> Best regards,
> Jie
> 
>  
> Best regards,
> Jie
>  
> Best regards,
> Krzysztof
> 
>  
> 
> On 2022 -Apr-18, at 12:18, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi Krzysztof,
>  
> Thanks for your reply. Please see some further inline with [Jie]:
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Friday, April 15, 2022 3:01 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
> Thank you for fast response.
>  
> I fully agree with you, that the realization is the combination of various techniques, and in particular realization, there could be more focus on some technique ‘A’, while in some other realization there could be some more focus on technique ‘B’. And, the framework should be open for different realizations.
>  
> [Jie] Agree the framework should be open to different realizations, and this is my understanding about the NRP description in the framework draft.
>  
> I have re-read section 6.1, I am still confused with the first paragraph on page 30, which says:
>  
>    An NRP is simply a collection of resources identified in the underlay
>    network.  Thus, the NRP is a scoped view of a topology and may be
>    considered as a topology in its own right.  The process of
>    determining the NRP may be made easier if the underlay network
>    topology is first filtered into a Filter Topology in order to be
>    aware of the subset of network resources that are suitable for
>    specific NRPs, but this is optional.
>  
> It is very tight coupling between NRP and the topology. IMHO, is some realizations this tight coupling might be true, I’m some realizations it might not be true. This paragraph is most distracting for me.
>  
> [Jie] My understanding about the topology here is that it is a generic term used to represent the set of network nodes and links that belong to the NRP, it does not constrain any mechanism to build or select the topology.  
>  
> But I agree the text could be improved. My suggestion is something like:
>  
>       An NRP is simply a collection of resource identified in the underlay network. The set of nodes and links belonging to the NRP provide the scoped view of a topology, and the NRP may be considered as a topology in its own right.
>  
> The rest text about filter topology (or call it sub-topology) is considered optional and I’m fine to either remove it or keep it.
>  
> Best regards,
> Jie
>  
> Best regards,
> Krzysztof
>  
>  
> 
> On 2022 -Apr-15, at 07:00, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi Krzysztof,
>  
> Yes NRP is a concept introduced for the realization of IETF network slice, and it is the result of long time WG discussion about the terminology for the underlay network construct which is used to support the IETF network slice services. My personal understanding is that the NRP concept and definition belongs to the framework document, while the technologies used to instantiate NRP are out of its scope. For sure there can be multiple ways to build an NRP, as long as they comply to the NRP definition in the framework.
>  
> I understand your concern is whether the framework mandates only one or two mechanisms to build NRP, I don’t think this is what the current framework indicates. Thus to me the examples about detailed realization mechanisms are not quite necessary for the framework document and may contradict with its role as a high-level framework.
>  
> On the other hand, discussion about the possible mechanisms to build NRPs can continue in the WG.
>  
> To me an NRP is usually realized with the combination of a set of data plane and control plane technologies. Constrained path computation or Flex-Algo can only be seen as a component rather than a complete solution. As you mentioned, one or multiple technologies such as admission control/advanced or basic QoS/capacity planning/resource reservation either on the edge nodes or the transit nodes would be needed, and the mechanisms can have specific applicability to different network applications.
>  
> Best regards,
> Jie
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>] 
> Sent: Thursday, April 14, 2022 9:00 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi Jie,
>  
> I agree, NRP is a realization, and a such, my initial comments (few weeks ago) was that it should not be mentioned at all in the framework document, but should be left to the documents describing the realization.
>  
> If, however, NRP is mandated by the framework document for realization, the wording for NRP in the framework document should be wide enough, to allow different realization options (described in different realization documents). For example, realization option mentioned by Med:
>  
> * admission control with advanced QoS (large number of edge QoS classes) at the transport edge
> * basic QoS (limited number of transport core QoS classes) in transport core
> * mapping between large number of transport edge QoS classes to limited number transport core QoS classes
> * capacity planning
>  
> has no good match with current wording about NRP in the framework document, IMHO.
>  
> Please see as well inline.
>  
> Thanks,
> Krzysztof
>  
>  
> 
> On 2022 -Apr-14, at 09:05, Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>  
> Hi John,
>  
> Thanks for the discussion on this point. Please see further inline with [Jie]:
>  
> From: John E Drake [mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>] 
> Sent: Wednesday, April 13, 2022 9:44 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>; Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc: teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Hi,
>  
> Upon re-reading Krzysztof’s email, I think we should keep the existing text and supplement it with Krzysztof’s text, but striking the second sentence.  Comments inline below.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> 
> Sent: Wednesday, April 13, 2022 2:53 AM
> To: Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc: teas@ietf.org <mailto:teas@ietf.org>
> Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> [External Email. Be cautious of content]
>  
> Hi Krzysztof,
>  
> One concern is the text you proposed is the level of detail which the framework document was trying to avoid.
>  
> And as for the examples you provided, I’m not sure if all of them can be called NRP. For example:
>  
> a)       collection of paths optimized based on certain criteria. For example low latency paths for NSP-A, and high capacity paths for NSP-B.
>  
> Low latency paths and high capacity paths may be obtained by using different metric types in Flex-Algo or other path computation, while as mentioned in a previous mail, depends on the network structure and topology, the path computed based on different metric types or constraints may still be the same or contain a set of shared links.
>  
> [JD]  What you are describing is how the NRP specified in a), above, might be instantiated.  I think a) is consistent with the existing text  
>  
> [Jie] My point was that the mechanism in a) may not be a good example for NRP instantiation. As it is only path computation and does not describe how the resources are managed or reserved for different NRPs.
>  
> Then it is not clear how the performance of services mapped to different NRPs with shared paths or links can be guaranteed. IMO some kind of resource reservation or management is needed for different NRPs. 
>  
> [JD]  This is an issue for the service provider
>  
> [Jie] Indeed service provider needs the mechanisms which can create NRPs to meet the performance requirement of different services, even if the paths or links are shared with other services. 
>  
> [Krzysztof] This is the question of realization, not the question of the framework. Some realization might use some advanced resource reservation/management for each link in the network, to squeeze out the link to last possible bit, some other realization might just use advanced reservation techniques on some links only (for example transport edge links), while using more loosely techniques on other links (e.g. transport core links). Some other realization might over provision certain links, instead of using advanced reservation mechanisms on these links. And, there could be dozens of different realization options, optimized for specific underlying technology. The framework document should not dictate any realization option, IMHO. It should be left to the realization documents.
>  
> 
>  
> Best regards,
> Jie
>  
>  
> From: Teas [mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>] On Behalf Of Krzysztof Szarkowicz
> Sent: Tuesday, April 12, 2022 10:08 PM
> To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>>; <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc: teas@ietf.org <mailto:teas@ietf.org>
> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> John, Adrian, Med
>  
> In that case, I would propose following text update. The reason is, from the current text, I cannot extract the the examples provided by Med and Adrian could be and well considered as an NSP realization.
>  
> ===== Current Text ============
> An NRP is simply a collection of resources identified in the underlay network.  Thus, the NRP is a scoped view of a topology and may be considered as a topology in its own right.  The process of determining the NRP may be made easier if the underlay network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs, but this is optional.
> ====== End of current text ==========
>  
>  
> ===== New Text ============
> It is out of scope for this document to describe the details, how an NSP can be realized. However, at a high-level, an NRP is simply a collection of resources identified in the underlay network. Some (none exhaustive) examples of an NSP realization are:
>  
> a) collection of paths optimized based on certain criteria. For example low latency paths for NSP-A, and high capacity paths for NSP-B.
>  
> b) admission control - possibly with large number of QoS classes - at the transport access, coupled with limited set of transport core QoS classes (PDBs), and N:M mapping between access and core classes.
>  
> c) combination of above
>  
> d) more complex realization schemes, with combinations of advanced QoS at both the access and transport core, possibly coupled with Filter Topology and different path optimizations methods.
> ====== End of new text ==========
>  
> Best regards,
> Krzysztof Szarkowicz
>  
> On 2022 -Apr-01, at 14:43, John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net>> wrote:
>  
> Krzysztof,
>  
> The usual answer to such a request is to ask you to provide text.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> 
>  
>  
>  
> 
> On 2022 -Apr-01, at 15:44, mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> wrote:
>  
> Re-,
>  
> Indeed.
>  
> FWIW, some of this is captured in RFC7297 with a focus on legacy mechanisms:
>  
> ==
>    These requirements include: reachability scope (e.g., limited scope,
>    Internet-wide), direction, bandwidth requirements, QoS parameters
>    (e.g., one-way delay [RFC2679], loss [RFC2680], or one-way delay
>    variation [RFC3393]), protection, and high-availability guidelines
>    (e.g., restoration in less than 50 ms, 100 ms, or 1 second).
>  
>    These requirements are then translated into IP/MPLS-related technical
>    clauses (e.g., need for recovery means, definition of the class of
>    service, need for control-plane protection, etc.).  In a later stage,
>    these various clauses will be addressed by the activation of adequate
>    network features and technology-specific actions (e.g., Multiprotocol
>    Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource
>    Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First
>    (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), by
>    means of CPP-derived configuration information.
>  
>    …
>  
>    The CPP template aims to capture connectivity needs and to represent
>    and value these requirements in a standardized manner.  Service- and
>    Customer-specific IP provisioning rules may lead to a dramatic
>    increase of the number of IP transfer classes that need to be
>    (pre-)engineered in the network.  Instantiating each CPP into a
>    distinct class of service should therefore be avoided for the sake of
>    performance and scalability.
>  
>    Therefore, application-agnostic IP provisioning practices should be
>    recommended, since the requirements captured in the CPP can be used
>    to identify which network class of service is to be used to meet
>    those requirements/guarantees.  From that standpoint, the CPP concept
>    is meant to design a limited number of generic classes so that
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    individual CPP documents, by capturing the connectivity requirements
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    of services, applications, and Customers, can be easily mapped to
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    these classes.
>    ^^^^^^^^^^^^
> ==
>  
> Cheers,
> Med
>  
> De : Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> 
> Envoyé : vendredi 1 avril 2022 15:26
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc : adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; teas@ietf.org <mailto:teas@ietf.org>
> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Med,
>  
> We are on the same page here. I see this as well as predominant approach, in fact.
>  
> Cheers,
> Krzysztof
>  
>  
> 
> On 2022 -Apr-01, at 15:20, <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> wrote:
>  
> Krzysztof,
>  
> Admission control + use of limited set of core QoS classes (PDBs) + much more access QoS classes + map access QoS classes to core classes + no multi-topology/customized path selection is also an example network partitioning. I even expect this to be the privileged approach when legacy forwarding mechanisms should be used to fulfil slicing objectives.
>  
> Cheers,
> Med
>  
> De : Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> 
> Envoyé : vendredi 1 avril 2022 10:30
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>
> Cc : teas@ietf.org <mailto:teas@ietf.org>
> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>  
> Adrian, Med,
>  
> Returning to this. I’ve seen many design cases with SPs, where the network is designed physically in very structured manner. Also, I’ve seen some analysis done by couple of SPs, that as the result of this very structured network design, after making internal analysis, they don’t really see the difference between path placement done using IGP metric, and path placement done using delay metric. Hence, even introducing some flex-algos (TE meshes) with different metric optimization is questionable here (as the resulting paths are the same).
>  
> To realize services with SLO commitments, these SPs today extensively use admission control at the edge (some times even relatively complex admission control schemes at the edge). But, they don’t use anything specific (TE, Flex-Algo) in the transport, apart from mentioned admission control at the edge (ingress/egress policers/shapers), basic QoS on transit, network capacity planning, and timely capacity upgrades, where needed.
>  
> Does this approach could be considered as well as some way of ’network resource partitioning’ mentioned in the draft?
>  
> Cheers,
> Krzysztof
>  
>  
> On 2022 -Mar-28, at 12:26, Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> wrote:
>  
> OK,
>  
> If a realization example of network partition is flex-algo + admission control, then I am fine.
>  
> Thanks,
> Krzysztof
>  
>  
> _________________________________________________________________________________________________________________________
>  
> 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 <mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!D-qeTJJnBrpgJcdpHdF57kkq8L9e4BdW1FyYQftk_KpcRhDufgTtsbUcYVmXAVntq0Qa6jF31qVv2f8$>