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

[John E Drake <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Adrian Farrel
Sent: 03 August 2022 23:15
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of
[e-mail]<mailto:[e-mail]>
Sent: 03 August 2022 23:06
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAOmcE7UH$>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!DfW1N0cjCbeJWPEPQcMrHwkODxKDARgTvJ1nbNE8C0UWAtGjdnjksDsda4z9JIvLN7O7Vz9zo3GYAGzOL_kb$>