Re: [Teas] Default NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]

Gyan Mishra <hayabusagsm@gmail.com> Mon, 26 September 2022 19:50 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 14FCCC14CE27 for <teas@ietfa.amsl.com>; Mon, 26 Sep 2022 12:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.994
X-Spam-Level:
X-Spam-Status: No, score=-1.994 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 (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 7YTPaBWP9s42 for <teas@ietfa.amsl.com>; Mon, 26 Sep 2022 12:50:13 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 72007C14F74D for <teas@ietf.org>; Mon, 26 Sep 2022 12:50:13 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id q26so7662763vsr.7 for <teas@ietf.org>; Mon, 26 Sep 2022 12:50:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=nkDNo3l+EhzpMdvwQ+UHnKldlkB8Cy0Mx9vvg5O6tdw=; b=AwGqBZADL42FBuMpbSuD3lQr7UHZb8eiPhqpgzVRAXGrjmX7KSkWwjOmQTFk4UTo3X wqqr6TAvud3I2Upubp9z1FL2CvNrkAAqLNZye3mMfnbgyZ2RX/NgQBb12r2+3qx1ArU4 3jH9AF0j/g6WlgquS7RLdzz4u5D833vKBa2ogL8ts2NMz8sYUxgzdW0TdMnddVgjRVxg vtzcL1h2VwW2ysRz9DOyxxeW9uBtuKDMjTsZcxCJcpqYU15aY9YjG79fc+kCc1FvsFBg fMjqw3gx4l53FufBTl9iugJ4UfaTcdqwfMMbZiFjc6cW6/jxtBWJeQWJugCDbfkVE9EN nLXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=nkDNo3l+EhzpMdvwQ+UHnKldlkB8Cy0Mx9vvg5O6tdw=; b=l45vDZUnx5Z7dCHmXoCfNVkFIL5pKAPbeddv/4bIMD9ZIVJ8bZVOpwZU5+ai7oP7A4 OcEh6XdE2NDnKnqli0zuF1eVVk9n/EHynq5o1PJTfviwj+LGFoOVJMGVT3kwsBAlJQYI omLeT591MvoSTBiZBe3NBKlL4N4vseyy389AIKOIMoqNh/2qUsmZ9dmUGA1hrUTiTLDY 9pfcZwrwWZzRi7S98y4B58zN46KduiwTxHp5ZkwujWInfdAoQz73KXAHuAAqG/RSiORv J9Hg2te2llllAWXieMg51Hvy6XBj+4C2gA0gP1AdPxkmtXakzVRix48C8xSOBt7O7xlf uAzg==
X-Gm-Message-State: ACrzQf2ILnazMtapXYa1iSbue4Q16Cn1Pj5/CTu2YPjH8Ko/tVEvFxCx 1+hwBNb+NHLcHvZldc8u5D/jq8O77O2Y14ZOTiIzsTmx
X-Google-Smtp-Source: AMsMyM52M7LESEPumq/hayXIaV63xZ9S+MEluuugYtyd1oIL4yh08M4aFGApPpfuEZLJOXKWPL0YI9DzmfTr/E0gcjA=
X-Received: by 2002:a05:6102:6d3:b0:398:6ba5:f6ac with SMTP id m19-20020a05610206d300b003986ba5f6acmr9458503vsg.65.1664221812252; Mon, 26 Sep 2022 12:50:12 -0700 (PDT)
MIME-Version: 1.0
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> <045601d8ce6c$b8e1df70$2aa59e50$@olddog.co.uk> <052001d8cea0$af181570$0d484050$@olddog.co.uk> <6E9D00B0-432A-4EE7-9231-A560640CFBFC@gmail.com> <BY3PR05MB8081C358D102BD76F34B5C8DC7539@BY3PR05MB8081.namprd05.prod.outlook.com> <8F023FDA-802B-4BDA-B110-B88F456BD604@gmail.com> <CA+RyBmWQ=xdkBv3E4ZQe9DuWSikw4Sc9A75UMksiBPmgzSw9vg@mail.gmail.com> <B3BF4BDC-053B-498B-B9F9-36B38C83F621@juniper.net> <089201d8d1c7$cc3a75b0$64af6110$@olddog.co.uk> <62E99A66-D895-4CC1-BC4F-C78894A05DD7@gmail.com> <CA+RyBmWNDzxaFi7Ai74DStRmSrvEaEEKMuDshbZ4B5mzDWKCPw@mail.gmail.com> <6EE9CA44-408B-4F6A-85BB-CC3FE96FF3ED@gmail.com>
In-Reply-To: <6EE9CA44-408B-4F6A-85BB-CC3FE96FF3ED@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 26 Sep 2022 15:50:00 -0400
Message-ID: <CABNhwV03TPmA8h8EGfeY6yqupqdbthnUcCJcrawu=jm7SxxWTQ@mail.gmail.com>
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Greg Mirsky <gregimirsky@gmail.com>, John E Drake <jdrake@juniper.net>, teas@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f267c105e999d508"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/4Ycsithc0RAHYHvHV-00nw4qFBM>
Subject: Re: [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: Mon, 26 Sep 2022 19:50:18 -0000

Hi Krzysztof

When you think of todays operators networks and existing technologies that
is where the confusion comes as far as “single NRP”.

So in todays networks using existing technologies L2 VPN, L3 VPN, QOS AFxx
marking and PHB scheduling queuing / buffering all happening within in
underlay made up of links and nodes composite.

So the existing underlay in todays networks described above we are not
talking NRP yet until the NSC controller is provisioned Day 1 to program
the underlay in software and then the single NRP is instantiated.

So when that happens the underlay made up of all link and nodes composite
that makes up the underlay would now become that first NRP.

So the NSC would configure that first NRP explicitly.

So I think if the NSC configures the first NRP automatically it would be
implicit which would imply a Default NRP concept.

I think the explicit makes more sense then implicit for the first NRP and
all subsequent NRP instantiation.

Hope this helps

Gyan

On Mon, Sep 26, 2022 at 3:27 PM Krzysztof Szarkowicz <kszarkowicz@gmail.com>
wrote:

> Greg,
>
> That is my opinions as well. And, as a consequence, it leads to an
> implicit NRP.
>
> Regards,
> Krzysztof
>
>
> On 2022 -Sep-26, at 21:17, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Krzysztof,
> in my opinion and based on my experience, even if an operator has not
> explicitly configured the NRP in the underlay network, it is performed by
> the SW according to the programmer's understanding of how networking should
> be operated.
>
> Regards,
> Greg
>
> On Mon, Sep 26, 2022 at 11:37 AM Krzysztof Szarkowicz <
> kszarkowicz@gmail.com> wrote:
>
>> Adrian,
>>
>> In today’s operator’s network, where services with SLOs are delivered,
>> NRP is not (explicitly) defined.
>>
>> Are we saying, that today’s network are providing these services without
>> NRP (a) at all, or with implicit (default) NRP (b) that uses all resources
>> in the network.
>>
>> —
>> Krzysztof
>>
>>
>> On 2022 -Sep-26, at 18:48, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>
>> I would add that Krzysztof’s default NRP **is** explicitly defined. That
>> it, the system is operated with the simple instruction “all resources are
>> in the single NRP”. That is, it is not default and this is a policy
>> operational decision. It may be that the operational decision is made at
>> purchase time (this equipment supports only having a single NRP that
>> contains all of the resources of the underlay network), but it is still an
>> active decision. I see know benefit in referring to it as “default” since
>> (as was pointed out way up this thread) the concept of defaulting becomes
>> unclear when a second NRP is defined.
>>
>> But shouldn’t we step back from the naming and talk about what function
>> we need to achieve?
>>
>> Adrian
>>
>> *From:* John E Drake <jdrake@juniper.net>
>> *Sent:* 26 September 2022 17:33
>> *To:* Greg Mirsky <gregimirsky@gmail.com>
>> *Cc:* Krzysztof Szarkowicz <kszarkowicz@gmail.com>; Adrian Farrel <
>> adrian@olddog.co.uk>; teas@ietf.org
>> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for
>> last call on draft-ietf-teas-ietf-network-slices]
>>
>> Greg,
>>
>>
>> A most excellent point.  All attempts to describe a transition from a
>> single NRP to a default NRP have foundered on this distinction.
>> Sent from my iPhone
>>
>>
>> On Sep 26, 2022, at 12:29 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>
>> 
>> *[External Email. Be cautious of content]*
>>
>> Hi Krzysztof,
>> I would note that the meaning of "default", as defined in, for example, Merriam-Webster
>> dictionary
>> <https://urldefense.com/v3/__https:/www.merriam-webster.com/dictionary/default__;!!NEt6yMaO-gk!H1gH-SvWJAhAijZq1KDgW_aaVA0pN9BVcWY3L4Fti4wjpwvCpYxtvhBWeBCAWTUSowUsDZ2Ur17W1aoiW-wt$>,
>> is not the same as "single":
>>
>> computers : a selection automatically used by a program in the absence of
>> a choice made by the user
>>
>> As I understand it, "default" exists and might be used in the presence of
>> other alternatives, NPRs, in our case. Hence, it appears that by equating
>> "single NPR" with "default NPR" we'll limit the applicability of the
>> latter. WDYT?
>>
>> Regards,
>> Greg
>>
>>
>> On Sun, Sep 25, 2022 at 8:07 AM Krzysztof Szarkowicz <
>> kszarkowicz@gmail.com> wrote:
>>
>> Thanks John,
>>
>> Please see inline.
>>
>> //Krzysztof
>>
>>
>> On 2022 -Sep-25, at 16:51, John E Drake <jdrake@juniper.net> wrote:
>>
>> Hi,
>>
>> Comments inline below
>>
>> Yours Irrespectively,
>>
>> John
>>
>>
>> Juniper Business Use Only
>> *From:* Krzysztof Szarkowicz <kszarkowicz@gmail.com>
>> *Sent:* Sunday, September 25, 2022 10:36 AM
>> *To:* Adrian Farrel <adrian@olddog.co.uk>
>> *Cc:* John E Drake <jdrake@juniper.net>; teas@ietf.org
>> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for
>> last call on draft-ietf-teas-ietf-network-slices]
>>
>> *[External Email. Be cautious of content]*
>>
>> Adrian,
>>
>> I have couple of questions here:
>>
>>
>> 1. Taking into consideration typical SP network today, where we have:
>>
>> a) differentiated services realized via mapping of DCSP and/or MPLS TC
>> values to buffers, and deploying some differentiated scheduling
>> b) running services (L3VPN, L2VPN, ...) over such network
>> c) possibly (but not necessarily) deploying some TE
>>
>> Do we refere to typical current SP deployment as using ’single NRP’ or
>> not using NRP at all?
>>
>> *[JD]  A single NRP*
>>
>>
>> [Krzysztof] So, isn’t it wise to call this single NRP as ‘default’ NRP,
>> as it is not explicitly defined? Adrian mentioned: "NRPs should be
>> explicit. Sure, you can have a single one that includes all resources on
>> all links, but that is still an active choice." I can assure you, that
>> these operators have no idea, they operate the network using single NRP.
>> Wording proposed by Adrian (and commented by Jie) for default NRP looks
>> good to me.
>>
>>
>>
>> 2. If I have in my network two set of tunnels between PE nodes, using
>> different link metric types (e.g. one set of tunnels uses IGP link metric
>> to determine the path through the network, another set of tunnels using TE
>> link metric to determine the path through the network), and these two sets
>> of tunnels use exactly the same resources: entire topology, i.e. all links
>> and nodes in the network, and the PHB is exactly the same (i.e., packet
>> with QoS marking ‘X’ get exactly the same treatment in terms of
>> buffering/scheduling, regardless if forwarded over tunnel from 1st tunnel
>> set, or tunnel from 2nd tunnel set) are we talking about one NRP or two
>> NRPs?
>>
>> *[JD]  A single NRP.  You are using different path computations on the
>> same NRP*
>>
>>
>> [Krzysztof] If we are changing the framework text, might be some
>> clarification wording for this point would be needed, as I heard opinions
>> that this constitute two NRPs.
>>
>>
>>
>> //Krzysztof
>>
>>
>>
>> On 2022 -Sep-22, at 18:30, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>
>> John makes some good points.
>>
>>
>>    1. Adding a definition of a term that is only used in parentheses in
>>    one (early) individual draft where one of the authors says it was a mistake
>>    to use it, seems excessive. Perhaps we should all just stop using the term?
>>    2. The idea of “default” seems wrong in any case. NRPs should be
>>    explicit. Sure, you can have a single one that includes all resources on
>>    all links, but that is still an active choice.
>>
>>
>> Adrian
>>
>> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *John E Drake
>> *Sent:* 22 September 2022 14:55
>> *To:* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>;
>> adrian@olddog.co.uk; teas@ietf.org
>> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for
>> last call on draft-ietf-teas-ietf-network-slices]
>>
>> Adrian,
>>
>> Upon reflection, the revised wording changes the meaning.  We start by
>> observing that “The connected set of links can be the entire set of links
>> in the underlay network” and then continue with “ **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”.  I.e.,  We can
>> define one or more NRPs that use the entire underlay network topology but
>> we can also define, in this case, a single NRP that uses all of the
>> underlay network resources – the underlay network has a topology and it has
>> resources.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>
>> Juniper Business Use Only
>> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *John E Drake
>> *Sent:* Thursday, September 22, 2022 9:01 AM
>> *To:* adrian@olddog.co.uk; teas@ietf.org
>> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for
>> last call on draft-ietf-teas-ietf-network-slices]
>>
>> *[External Email. Be cautious of content]*
>>
>> Adrian,
>>
>> I am okay with your revised wording for single NRP, but I don’t agree
>> that we need to define a ‘default NRP’ because it is attempting to detail
>> how a given service provider **might** operate its underlay network.
>> I.e., it is pure speculation.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>
>> Juniper Business Use Only
>> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Adrian Farrel
>> *Sent:* Thursday, September 22, 2022 6:19 AM
>> *To:* teas@ietf.org
>> *Subject:* [Teas] Default NRP definition [Was: Repeated call for last
>> call on draft-ietf-teas-ietf-network-slices]
>>
>> *[External Email. Be cautious of content]*
>>
>> 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>
>> 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 mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!C0Cbp6e6wcOCIVeA1aT1n44Wf96-VKMA8tnK1DUNPN_0pNkp0OBouxUGsaaZCen03sfeMUmURWIB-wW6HCBj$>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!H1gH-SvWJAhAijZq1KDgW_aaVA0pN9BVcWY3L4Fti4wjpwvCpYxtvhBWeBCAWTUSowUsDZ2Ur17W1QCegxMj$>
>>
>>
>>
> _______________________________________________
> 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*