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

[Joel Halpern <[e-mail]>]

Does that single NRP admit multiple diffserv code points / queueing 
behaviors?

If so, then the notion of NRP is itself purely an arbitrary collection 
of behaviors, and thus not helpful or particularly meaningful.

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.  Antoher 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.

None of this is about the number of topologies.

There are likely other ways out.  But the current text is clearly 
ambiguous, as John and I came to different conclusions about what it means.

Yours,

Joel

On 9/21/2022 1:33 PM, John E Drake wrote:
>
> Hi,
>
> I think a discussion may be in order but I am not convinced the 
> existing text is either incorrect or imprecise.  I.e., in the limit, a 
> single NRP should consist of the entire underlay network, both its 
> topology as well  as its buffer, queuing, and scheduling resources:
>
> “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.”
>
> Yours Irrespectively,
>
> John
>
> Juniper Business Use Only
>
> *From:* Teas <[e-mail]> *On Behalf Of * Vishnu Pavan Beeram
> *Sent:* Wednesday, September 21, 2022 12:10 PM
> *To:* Joel Halpern <[e-mail]>
> *Cc:* Gyan Mishra <[e-mail]>; Krzysztof Szarkowicz 
> <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* Re: [Teas] Repeated call for last call on 
> draft-ietf-teas-ietf-network-slices
>
> *[External Email. Be cautious of content]*
>
> 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 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.
>
> Regards,
>
> -Pavan and Lou
>
> On Wed, Sep 7, 2022 at 5:06 AM Joel Halpern 
> <[e-mail]> wrote:
>
>     It is true that an operator may deploy one topoogy.  (It seems a
>     little odd to declare that all traffic shall take the low delay
>     path, but an operator is certainly allowed to do so.
>
>     That does not mean there is only one NRP.  NRPs are about the
>     queueing and scheduling properties the devices apply to the
>     traffic.  While bound to a topology, they are not themselves
>     topologies.
>
>     Yours,
>
>     Joel
>
>     On 9/6/2022 7:32 PM, Gyan Mishra wrote:
>
>         Hi Joel
>
>         My thoughts and understanding is for flexibility for operators
>         the underlay can consist of a single NRP which could be let’s
>         say a low delay Flex Algo  FAD.  When that happens all of the
>         Differential services AF-X PHB classification that happens
>         would all still remain in that single NRP.
>
>         As operators start carving the underlay into multiple slices /
>         NRP, at that time specific AF-X values would get mapped  to
>         the different NRPs.
>
>         Kind Regards
>
>         Gyan
>
>         On Wed, Aug 24, 2022 at 1:09 PM Joel Halpern
>         <[e-mail]> wrote:
>
>             As far as I can tell, if you have two different queues,
>             one for AF1x traffic and one for AF2x traffic, then that
>             is not a single NRP.  It is two NRPs.   Which nicely makes
>             NRP a generalization of tehcnologies we understand and use.
>
>             But whether the text means what I think it means, or what
>             Krzysztof things it means, the fact that we read it
>             differently means we should clarify it.
>
>             Yours,
>
>             Joel
>
>             On 8/24/2022 1:05 PM, Krzysztof Szarkowicz wrote:
>
>                 I think the current text is pretty clear:
>
>                    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.
>
>                 All link/buffer/queuing/scheduling resources can
>                 assigned to single NRP, based on above text.
>
>                 Best regards,
>
>                 Krzysztof
>
>                     On 2022 -Aug-24, at 18:51, Joel Halpern
>                     <[e-mail]> wrote:
>
>                     In discussion with various people, I am finding
>                     that there is a lot of confusion about meaning of
>                     "default NRP", and the related perspective that as
>                     far as I can tell one can deliver modest numbers
>                     of NRPs with existing technologies.
>
>                     I am talking to folks trying to come up with
>                     proposed better language.
>
>                     Yours,
>
>                     Joel
>
>                     On 8/24/2022 10:30 AM, Adrian Farrel wrote:
>
>                         Hi chairs,
>
>                         Three weeks on, just wanted to ask what the
>                         status is.
>                         I'm sure you have a queue of documents pending
>                         WG last call. It would be
>                         helpful if you could make that public so that
>                         I don't have to keep asking
>                         you for status.
>
>                         Thanks,
>                         Adrian
>
>                         -----Original Message-----
>                         From: Teas <[e-mail]> On Behalf
>                         Of Adrian Farrel
>                         Sent: 03 August 2022 23:15
>                         To: [e-mail]
>                         Cc: [e-mail]
>                         Subject: Re: [Teas] I-D Action:
>                         draft-ietf-teas-ietf-network-slices-14.txt
>
>                         Hi Chairs (and WG),
>
>                         This version includes the additional
>                         appendixes as discussed on the list.
>
>                         I believe we are done with this document and
>                         we should push it through WG
>                         last call, getting thorough review as we do
>                         it. I think that is fairly
>                         pressing to reach conclusion on this framework
>                         so that the other dependent
>                         documents know that they are building on
>                         stable foundations.
>
>                         Thanks,
>                         Adrian
>
>                         -----Original Message-----
>                         From: I-D-Announce
>                         <[e-mail]> On Behalf Of
>                         [e-mail]
>                         Sent: 03 August 2022 23:06
>                         To: [e-mail]
>                         Cc: [e-mail]
>                         Subject: I-D Action:
>                         draft-ietf-teas-ietf-network-slices-14.txt
>
>
>                         A New Internet-Draft is available from the
>                         on-line Internet-Drafts
>                         directories.
>                         This draft is a work item of the Traffic
>                         Engineering Architecture and
>                         Signaling WG of the IETF.
>
>                                 Title           : Framework for IETF
>                         Network Slices
>                                 Authors         : Adrian Farrel
>                                                   John Drake
>                                                   Reza Rokui
>                                                   Shunsuke Homma
>                                                   Kiran Makhijani
>                                                   Luis M. Contreras
>                                                   Jeff Tantsura
>                           Filename        :
>                         draft-ietf-teas-ietf-network-slices-14.txt
>                           Pages           : 51
>                           Date            : 2022-08-03
>
>                         Abstract:
>                            This document describes network slicing in
>                         the context of networks
>                            built from IETF technologies.  It defines
>                         the term "IETF Network
>                            Slice" and establishes the general
>                         principles of network slicing in
>                            the IETF context.
>
>                            The document discusses the general
>                         framework for requesting and
>                            operating IETF Network Slices, the
>                         characteristics of an IETF Network
>                            Slice, the necessary system components and
>                         interfaces, and how
>                            abstract requests can be mapped to more
>                         specific technologies. The
>                            document also discusses related
>                         considerations with monitoring and
>                            security.
>
>                            This document also provides definitions of
>                         related terms to enable
>                            consistent usage in other IETF documents
>                         that describe or use aspects
>                            of IETF Network Slices.
>
>
>                         The IETF datatracker status page for this
>                         draft is:
>                         https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/
>                         <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAEi61KMk$>
>
>                         There is also an HTML version available at:
>                         https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-14.html
>                         <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-14.html__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAHX5pDKb$>
>
>                         A diff from the previous version is available at:
>                         https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-14
>                         <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-14__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAAWuPlSA$>
>
>
>                         Internet-Drafts are also available by rsync at
>                         rsync.ietf.org::internet-drafts
>
>
>                         _______________________________________________
>                         I-D-Announce mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/i-d-announce
>                         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAJm-iSr9$>
>                         Internet-Draft directories:
>                         http://www.ietf.org/shadow.html
>                         <https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAO1gMJ2k$>
>                         or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>                         <https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow-sites.txt__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAP7-I7P9$>
>
>                         _______________________________________________
>                         Teas mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/teas
>                         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
>
>                         _______________________________________________
>                         Teas mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/teas
>                         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
>
>
>                     _______________________________________________
>                     Teas mailing list
>                     [e-mail]
>                     https://www.ietf.org/mailman/listinfo/teas
>                     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
>
>             _______________________________________________
>             Teas mailing list
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/teas
>             <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
>
>         -- 
>
>         <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAOmcE7UH$>
>
>         *Gyan Mishra*
>
>         /Network Solutions Architect /
>
>         /Email [e-mail]/
>
>         /M 301 502-1347/
>
>     _______________________________________________
>     Teas mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas