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

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 <jmh.direct@joelhalpern.com>
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 <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 *
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>