Re: [Teas-ns-dt] Definitions draft review

[Greg Mirsky <[e-mail]>]

Dear All,
I've got a minor comment regarding updating the following sentence:
  This document provides a definition of 'transport slices' in IETF,
  and describes considerations for their realization.
The update proposed by Jari suggests, as I understand, s/IETF/IP/. I think
that does make the sentence more technology-oriented but maybe not in
sync with the way IP listed among other examples of realizing a transport
network in the following:
 ... within the scope of transport networks (e.g. IP, MPLS, GMPLS).
Considering the latter, would change in the former from "in IETF" to, for
example, "in Packet-Switched Networks" be acceptable?

Regards,
Greg

On Mon, Jan 27, 2020 at 10:00 AM Shunsuke Homma <[e-mail]>
wrote:

> Hi Jari,
>
> I appreciate for your kind review and feedback. Please see inline.
>
> Regards,
>
> Shunsuke
>
> 2020年1月27日(月) 23:05 Jari Arkko <jari.arkko=[e-mail]>rg>:
>
>> I did a review of the definitions draft. We're off to a good start but I
>> wanted to convey some smaller and larger comments, the latter mostly with
>> the intent to scope the document down to a very specific goal, with the
>> intent that it can be specified and approved as an IETF RFC easily and
>> without extended discussions.
>>
>> > the definition of transport slice in IETF
>>
>> I wonder if the organization matters or rather the substance. Maybe “in
>> IP networks” instead of “in IETF”. Or equivalent. What tech are you
>> specifying? You should speak about that, not the standards org.
>>
>> [SH] "in IP network" seems better, and I'll change the term.
>
>
>> >  Network Slicing is considered very useful because there
>> >  is a need to generalize control, operations and management of diverse
>> > set of services and related resource requirements that can then be
>> >  applied to any number or type of proposed, implemented and/or
>> >  deployed technologies and associated devices.  Some key applications
>> >   which might benefit from the use of network slicing include:
>>
>> I think there's two separate benefits here. First, why does one need
>> slicing, partitioning, etc?  And secondly, if one needs it, why does one
>> need to generalise it?
>>
>> [SH] We'll consider replacing the text for emphasizing the two points:
> allowing diverse devices/applications which have different requirements on
> communication to coexist on the same network efficiently, and enabling
> tenants to deploy slices across multiple domains.
>
>
>> > Transport slices are a
>> >  part of network slice that fulfills connection requirements, which
>> >  are created and managed within the scope of transport networks (e.g.
>> >  IP, MPLS, GMPLS).
>>
>> Since the word endpoint is introduced above, maybe use it here too.
>> Perhaps:
>>
>>  ... connection requirements between endpoints. Transport slices are
>> created ...
>>
>> [SH] Agree. I'll modify it.
>
>
>> >   This document provides a definition of 'transport slices' in IETF,
>> >  and describes considerations for their realization.
>>
>> I wonder if this should be in this document or elsewhere. E.g., the
>> framework or a separate use cases document.
>>
>> [SH] Yes, I also think that considerations for realization should be
> moved to the framework document.
>
>
>
>> >   o  UPF: User Plane Function
>>  >  o  gNB: Next Generation Node B
>>
>> Many terms and definitions... how much of this is necessary? Will this
>> extra detail clutter what one tries to achieve with the definition? The
>> crisper definition you have, the less you need to talk about mobile
>> networks or other use cases. Considering writing another draft with use
>> cases if that's necessary.
>>
>> [SH] Sure. We'll filter the list to only essentials.
>
>
>> > 3.  High Level Architecture of End-to-End Network Slicing
>>
>> This section is interesting and well written, but I wonder if it belongs
>> to this document. We're not specifying the full slicing architecture. We
>> should specify transport slices.
>>
>> How about defining transport slices *without* having to refer to
>> end-to-end slice?
>>
>> (It would be ok to have a small note like the one about sub-slice terms
>> in Section 4.1)
>>
>> [SH] IMHO, some description about relationship between E2E slice and
> transport slice would be important, because transport slice won't
> necessarily provide e2e connectivity. However, the current description may
> includes too much information, and we'll reconsider and polish the
> description.
>
>
>>  > "A transport slice is an abstract network topology connecting a
>>  >  number of endpoints, with expected objectives specified through a set
>>  >  of service level objectives (SLO)".
>>
>> Seems fine... but one has to fill in the definition of endpoints (maybe
>> forward ref to Section 5.2), the SLO in more detail (maybe forward ref to
>> section 5), and also specify what "connecting" means.
>>
>> [SH] We need more elaboration with referring other I-Ds and RFCs.
>
>
>> > 4.2.  Overview of Transport Slice Structure
>>
>> This is good material and generic.
>>
>> [SH] Thanks.
>
>
>> > 4.2.2.  Transport Slice Controller Interfaces
>>
>> Potentially fodder for removal, isn't this something that the framework
>> document should talk about?
>>
>> [SH] OK. We can move this subsection to the framework doc. Btw, should
> stakeholders section be moved as well?
>
>
>> > 5.1.  Service Level Objectives on Transport Slice
>> >
>> >   A transport slice is defined in terms of several quantifiable
>> >   objectives or SLOs.  These objectives define a set of network
>> >   resource parameters or values necessary to provide a service a given
>> >   transport slice.  A non-exhaustive list of characteristics types for
>> >   transport slice is described below:
>> >
>> >   o  Guaranteed Bandwidth
>> >   o  Guaranteed Delay
>> >   o  Prevention of Jitter
>> >   o  High Reliability (i.e., low packet loss rate)
>> >   o  High Availability (i.e., MTBF, MTTR)
>> >   o  Secure network
>> >   o  etc.
>>
>> I'd prefer to see a more complete and fully defined set of criteria
>> (including references to definitions) which then can of course be extended
>> by future docs.
>>
>> [SH] Sure. Let's continue the clarification.
>
>
>> > 5.3.  Vertical Transport Slice
>>
>> This is ok, as is 5.4.
>>
>> [SH] Thanks.
>
> > 6.  Realization of Transport slice
>>
>> Maybe the realisiation part is something that one should consider moving
>> somewhere else. Potentially also the other parts, because while the first
>> example for instance is quite good, it has a number of details that aren't
>> core to the definition of a slice. Do we need a use case doc?
>>
>> [SH] I agree with that this section should be moved to other document.
> For example, can we describe these in an appendix of the framework doc? (It
> will take long time to make a new draft and reach our consensus. )
>
> Thanks again.
>
>
>> Jari
>>
>>
>> --
>> Teas-ns-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>