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

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 <jmh@joelhalpern.com> 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 <jmh@joelhalpern.com> 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 <teas-bounces@ietf.org> On Behalf Of Adrian Farrel
> Sent: 03 August 2022 23:15
> To: teas-chairs@ietf.org
> Cc: teas@ietf.org
> 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 <i-d-announce-bounces@ietf.org> On Behalf Of
> internet-drafts@ietf.org
> Sent: 03 August 2022 23:06
> To: i-d-announce@ietf.org
> Cc: teas@ietf.org
> 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/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-14.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-14
>
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>
> _______________________________________________
> 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*