[Teas] Default NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]
Adrian Farrel <adrian@olddog.co.uk> Thu, 22 September 2022 10:19 UTC
Return-Path: <adrian@olddog.co.uk>
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 4F186C1594A6 for <teas@ietfa.amsl.com>; Thu, 22 Sep 2022 03:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 BX3rmYGQYq3C for <teas@ietfa.amsl.com>; Thu, 22 Sep 2022 03:19:01 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3D7C1594A4 for <teas@ietf.org>; Thu, 22 Sep 2022 03:19:00 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 28MAIv8B009945 for <teas@ietf.org>; Thu, 22 Sep 2022 11:18:57 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 51A4946050 for <teas@ietf.org>; Thu, 22 Sep 2022 11:18:57 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C6AD4604D for <teas@ietf.org>; Thu, 22 Sep 2022 11:18:57 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS for <teas@ietf.org>; Thu, 22 Sep 2022 11:18:57 +0100 (BST)
Received: from LAPTOPK7AS653V (152.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.152] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 28MAIu8X002022 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <teas@ietf.org>; Thu, 22 Sep 2022 11:18:56 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: teas@ietf.org
References: <165956437769.55050.16490105634807702976@ietfa.amsl.com> <0f3d01d8a786$731d5cb0$59581610$@olddog.co.uk> <01dc01d8b7c6$02ee2a00$08ca7e00$@olddog.co.uk> <e2e196b0-6edf-a7bc-9a16-236b270c9c67@joelhalpern.com> <C10CA5B1-99EC-44C5-BEAF-C0A9E519B196@gmail.com> <184d1468-8fec-6425-05fc-f8fe41833985@joelhalpern.com> <CABNhwV0f37Y8WULLSq5COZyFyfg81OP_8JHRUaLGWEtUp10dLg@mail.gmail.com> <20d1ffc2-276a-90d8-d03f-a60b9bb2ab65@joelhalpern.com> <CA+YzgTsiFTbe=w6yX2BR9p8q31pgDnvn_3mhbPN9yEMCGwNtxw@mail.gmail.com> <BY3PR05MB8081ED2E8CCFCFE3EDCA2773C74F9@BY3PR05MB8081.namprd05.prod.outlook.com> <3ab8c72e-7813-05ff-6d3d-72fca5e7d252@joelhalpern.com> <BY3PR05MB80812E4C8381F24FEF9B43F4C74F9@BY3PR05MB8081.namprd05.prod.outlook.com> <0FE5FD9A-A52B-4046-A16A-BBC7D7EFE402@gmail.com> <03f101d8ce07$c00e86a0$402b93e0$@olddog.co.uk> <CA+YzgTs8YTKcQ-u=1B3waYbO4P_9T1L=eEgCsMUiX2EcNA1O4g@mail.gmail.com>
In-Reply-To: <CA+YzgTs8YTKcQ-u=1B3waYbO4P_9T1L=eEgCsMUiX2EcNA1O4g@mail.gmail.com>
Date: Thu, 22 Sep 2022 11:18:55 +0100
Organization: Old Dog Consulting
Message-ID: <045601d8ce6c$b8e1df70$2aa59e50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0457_01D8CE75.1AA77FF0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdjObLPsuODvX5wTTHWqWBFn28B7IA==
Content-Language: en-gb
X-Originating-IP: 81.174.197.152
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27156.007
X-TM-AS-Result: No--35.294-10.0-31-10
X-imss-scan-details: No--35.294-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27156.007
X-TMASE-Result: 10--35.293700-10.000000
X-TMASE-MatchedRID: hFd9GDLCAzgZnuop9luYIDZoNXJMbH+nsBSA1tuZVSal4Myqx+N7eO3y sWjNsapACqIlUwwPgewZ/z/mqxr5pLzEus57uN4wBe3KRVyu+k2YasbATu5ay1gLks93sG9t7kO yZefHxfffVRkbRQShuFPtO0xWOZc43gbr9TlFf7gX6pCkJZNSOXZljA0GozoidE7HIe9l0mzBZq EdJyZjPcgfSosmpqsATmvVyVEN4oXVm14t84/DtJVRzPxemJL0tNPXK3NCnaSu9yzHHu0Zift+k +9NtAMEiq0PzbJsBzndALfp9fQ5EfJW6Mbl18qzx7+NomOZVWVg0ehWOQsmmWUS/oAi0pYXwisn IbO8h0O4uSE3VuoW9ci52+zk8CFP3axH5q+MQOAJN6i943RQTbqGBW9J0Yqjy8ftIFhtAGTwyyp BltycsRe109oIw0UQBlFNdihulab4xEDDKsmaCUrOO5m0+0gEU2fjZiNvIymeEPi9wVyFrof61d bc+smNdbP0O3DGWKRt1av1ivNTb9f+mH7tF0IQlFz9z7doHVGc4qcCnuCXte54Zsf9ToX1mBQvL jMBsUE+GyeGbunbGS8jtdVZy+fHCZOct4mwShIEOhHzDsL05snlJe2gk8vIgQF5fS5D6ekNobS9 dl2K8+/MUSfwSVefj9ZO2uEJKCiPdrnpG/SR/ZIr4JXKmCdCBPY4SegK3jzMl2IQTlmRgJ/vLk4 ECKhoNtrqBJtuOX6I40w6RysGJoc7+Qb8+03p/HTKStsDGMK/d317BwwdBxbM9NvE7tH690ibxL 4bz6Auy+d2rXUBkptVVeKU/pCr8IMW9dkWZjKeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg1KMqIeOstiftT4piLWpY7p+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/0zzmkJcpgy0ysuHxAzRpfi1Ym4U>
Subject: [Teas] Default NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
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, 22 Sep 2022 10:19:04 -0000
Hi all, again. Jumping in at the top of the thread, yet again, to try to dig into two pieces of terminology. Picking up particularly on Greg, Jie, and Pavan’s points. “Single” does, indeed, mean “just one”. But it’s usage is very deterministic, meaning “one of (potentially) many” in some cases, and meaning “there is exactly one” in other cases. Perhaps it would help if: OLD 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 all of the buffer/queuing/scheduling resources for each of the links in the underlay network. NEW The connected set of links can be the entire set of links in the underlay network and in this case there can be precisely one NRP supported in the underlay network where that NRP has all of the buffer/queuing/scheduling resources for each of the links in the underlay network. END “Default” has, of course, a clear meaning in English (although there are several different meanings). As engineers, we should be careful not to introduce terms without also writing a clear definition. If we want to use the term “default NRP” then we should define it and, in that case, this document seems like a fine place to include it. But we are definitely fishing around for what “we” mean by the term. I think we are getting to… Default NRP: The default NRP is constructed from all of the buffer/queuing/scheduling resources on all of the links in the underlay network that have not been assigned for use by any other NRP. That is, it consists of the residue resources. If no other NRP has been defined, the default NRP comprises all of the buffer/queuing/scheduling resources of the underlay network. If a further NRP is subsequently defined, the default NRP will be reduced by the resources assigned to the new NRP. If an NRP is deleted, its resources are released back into the default NRP. Commensurate with that, the text quoted above could can become… In the case where there is just the default NRP and no other NRPs have been defined, the connected set of links can be the entire set of links in the underlay network, and in this case there is precisely one NRP (the default NRP) supported in the underlay network where that NRP has all of the buffer/queuing/scheduling resources for each of the links in the underlay network. Thoughts? Cheers, Adrian From: Vishnu Pavan Beeram <vishnupavan@gmail.com> Sent: 22 September 2022 06:34 To: adrian@olddog.co.uk Cc: Krzysztof Szarkowicz <kszarkowicz@gmail.com>; Joel Halpern <jmh@joelhalpern.com>; teas@ietf.org; John E Drake <jdrake=40juniper.net@dmarc.ietf.org> Subject: Re: [Teas] Repeated call for last call on draft-ietf-teas-ietf-network-slices Adrian, Hi! Thanks for the top-post. Please see inline (prefixed VPB). Regards, -Pavan On Thu, Sep 22, 2022 at 3:46 AM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > wrote: Hi, Sort of top-posting on the thread, and speaking as editor. Krzysztof >> > I see that the current text is clear and precisely describes the > intent of single (default) NRP, so it doesn’t need any change/correction. Well, it was certainly the intent that the text would be clear, but if some people are confused or unclear, we should seek to make things clearer. Note well that the term "default NRP" is not one that is used in the document, and any lack of clarity about the term must be laid at the feet of the people using the term! I *think* the term is being used to describe the limiting case where there is just one NRP that is all of the resources in the network. Joel >> > Does that single NRP admit multiple diffserv code points / queueing behaviors? [JD] That is at the discretion of the underlay network operator I think John and Joel may be at cross-purposes with the same conclusion. To Joel: Yes, the single NRP admits the possibility of multiple diffserv code points / queueing behaviors. To John: Yes, the underlay network operator is free to make the default NRP have multiple or fewer codepoints / queueing behaviors. Joel >> > If so, then the notion of NRP is itself purely an arbitrary collection of > behaviors, and thus not helpful or particularly meaningful. "Arbitrary" and "helpful" are possibly a bit loaded. Recall that the NRP is an internal mechanism for the underlay network operator. It is not exposed to the customer, but is a tool for the operator. It allows the operator to partition their network in a way that they find useful for the rapid construction of network slices. What that amounts to is that the operator may profile the resources of the network into collections (NRPs) to enable the support of particular types of network slice service. The way that an operator does this is entirely up to them (it's a policy), so it could be arbitrary or highly logical. But some people think that it won't be necessary to build NRPs and so we have the concept of "the default NRP" which is essentially all of the resources of the network. It's a null-op in the process, but we keep it there to have a consistent picture. Joel >> > One way out is to declare that relative to any given device, the collection of behaviors in > an NRP may be different diffserv code points but may not be further differentiated. > Another way out is to declare that the collection referred to in the definition refers to > the collection across devices, but within a device an NRP has only one queueing > behavior / resource. But I wonder if there is a confusion between resources and behaviors? The text in the draft is clear that it is describing resources. How the resources are used is surely a different matter, or is it? As a quick reference, the text we're talking about is... A Network Resource Partition (NRP) is a collection of resources (bufferage, queuing, scheduling, etc.) in the underlay network. The amount and granularity of resources allocated in an NRP is flexible and depends on the operator's policy. Some NRP realizations may build NRPs with dedicated topologies, while some other realizations may use a shared topology for multiple NRPs; one possible realization is of a single NRP using all of the resources of the entire underlay network topology. Thus, an NRP consists 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 all of the buffer/queuing/scheduling resources for each of the links in the underlay network. Pavan and Lou >> > This thread does seem to suggest there are some loose ends with > respect to the notion of a default NRP that need to be tied before > publication. There are some open questions on how resources in > the default NRP get impacted when you start adding resource > partitions in the underlay network. We do have to return to ask, "What is this default NRP that you are talking about?" If it is, as I assume, the "single NRP" that "has all of the buffer/queuing/scheduling resources for each of the links in the underlay network" then it should be fairly obvious that adding other NRPs does change the definition of the "default NRP." This happens because the default NRP stops being the only NRP and so stops being the default NRP. I believe you have yourself wrapped around the definition of a term that doesn't exist. [VPB] You are right -- draft-ietf-teas-ietf-network-slices does not use the term "default NRP". draft-ietf-teas-ns-ip-mpls, which extensively discusses the notion of one or more network resource partitions, also does not use this term (yet). But, we are starting to discuss slicing realization documents in the WG that are building on this notion of a "default/single/only NRP" as framed in draft-ietf-teas-ietf-network-slices (see draft-srld-teas-5g-slicing which does use this term) and for that purpose it may be useful to discuss what this entails (now rather than later). As Jie has pointed out in this thread, there is an interpretation here that you may start with a default NRP (no explicit resource partitioning) to realize slicing, but you may end up having the default NRP co-exist with non-default NRPs as they get gradually added to the network. The default NRP in this interpretation may simply translate to the set of resources that don't meet the selection criteria of any explicit user-specified NRP (if there are no user-specified NRPs, then the default NRP includes all the resources in the underlay network). Another interpretation of the default NRP is (like you said) that it ceases to exist when the first resource partition is made (two explicit NRPs get created). [VPB] We (the WG) may end up saying that we don't need to discuss "default NRP" or its semantics in draft-ietf-teas-ietf-network-slices, but rather have it discussed in draft-ietf-teas-ns-ip-mpls (which does talk about slicing realization using one or more resource partitions) instead. But it is a loose end that needs to be tied at some point. Pavan and Lou >> > We are hoping that the WGLC (the process for which has just begun) > would be a forcing function for those of you (chairs included) who > intend to suggest text/edits to clear this up. It would be great if exactly that happened. That is, text suggestions. Cheers, Adrian
- [Teas] I-D Action: draft-ietf-teas-ietf-network-s… internet-drafts
- Re: [Teas] I-D Action: draft-ietf-teas-ietf-netwo… Adrian Farrel
- [Teas] Repeated call for last call on draft-ietf-… Adrian Farrel
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Repeated call for last call on draft-i… Joel Halpern
- Re: [Teas] Repeated call for last call on draft-i… Krzysztof Szarkowicz
- Re: [Teas] Repeated call for last call on draft-i… Joel Halpern
- Re: [Teas] Repeated call for last call on draft-i… Vishnu Pavan Beeram
- Re: [Teas] Repeated call for last call on draft-i… Gyan Mishra
- Re: [Teas] Repeated call for last call on draft-i… Joel Halpern
- Re: [Teas] Repeated call for last call on draft-i… Vishnu Pavan Beeram
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Repeated call for last call on draft-i… Joel Halpern
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Repeated call for last call on draft-i… Krzysztof Szarkowicz
- Re: [Teas] Repeated call for last call on draft-i… Joel Halpern
- Re: [Teas] Repeated call for last call on draft-i… Adrian Farrel
- Re: [Teas] Repeated call for last call on draft-i… Greg Mirsky
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Repeated call for last call on draft-i… Greg Mirsky
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Repeated call for last call on draft-i… Gyan Mishra
- Re: [Teas] Repeated call for last call on draft-i… Greg Mirsky
- Re: [Teas] Repeated call for last call on draft-i… Dongjie (Jimmy)
- Re: [Teas] Repeated call for last call on draft-i… Vishnu Pavan Beeram
- [Teas] Default NRP definition [Was: Repeated call… Adrian Farrel
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Repeated call for last call on draft-i… John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Adrian Farrel
- [Teas] NRP definition [Was: Repeated call for las… Adrian Farrel
- Re: [Teas] NRP definition [Was: Repeated call for… Joel Halpern
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Joel Halpern
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Greg Mirsky
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Adrian Farrel
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … Greg Mirsky
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … Greg Mirsky
- Re: [Teas] Default NRP definition [Was: Repeated … Gyan Mishra
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] Default NRP definition [Was: Repeated … Greg Mirsky
- Re: [Teas] Default NRP definition [Was: Repeated … Gyan Mishra
- Re: [Teas] Default NRP definition [Was: Repeated … Adrian Farrel
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Dongjie (Jimmy)
- Re: [Teas] Default NRP definition [Was: Repeated … Dongjie (Jimmy)
- Re: [Teas] Default NRP definition [Was: Repeated … peng.shaofu
- Re: [Teas] Default NRP definition [Was: Repeated … Daniele Ceccarelli
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Tarek Saad
- Re: [Teas] Default NRP definition [Was: Repeated … Daniele Ceccarelli
- Re: [Teas] NRP definition [Was: Repeated call for… mohamed.boucadair
- Re: [Teas] NRP definition [Was: Repeated call for… Joel Halpern
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Tarek Saad
- Re: [Teas] NRP definition [Was: Repeated call for… John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Daniele Ceccarelli
- Re: [Teas] Default NRP definition [Was: Repeated … John E Drake
- Re: [Teas] Default NRP definition [Was: Repeated … Gyan Mishra
- Re: [Teas] Default NRP definition [Was: Repeated … Krzysztof Szarkowicz
- Re: [Teas] NRP definition [Was: Repeated call for… mohamed.boucadair
- Re: [Teas] NRP definition [Was: Repeated call for… Joel Halpern