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

[Shunsuke Homma <[e-mail]>]

Thanks, Jeff.
I'll change the text to "This document describes the definition of slice in
transport network and its characteristics."
I think it is layer agnostic and can cover all types of transport network.

Regards,

Shunsuke

2020年1月28日(火) 20:11 Jeff Tantsura <[e-mail]>om>:

> Hi Shunsuke/Greg,
>
> Any time you explicitly mention a particular “layer” you exclude others,
> in PSN case L1. I think a layer agnostic definition would be more
> appropriate. “Transport networks” seems to cover it all.
>
> P.S. GMPLS is not a proper term to use as it doesn’t identify a particular
> layer but a suite of protocols.
>
> Regards,
> Jeff
>
> On Jan 28, 2020, at 02:25, Shunsuke Homma <[e-mail]> wrote:
>
> 
> Hi Greg,
>
> Thank you for your review and comment. Our scope will include MPLS and
> GMPLS in addition to pure IP, and your proposal makes sense to me. For now,
> I replace "in IETF" to "in Packet-Switched Networks". If anyone has opinion
> here, please let us know.
>
> Regards,
>
> Shunsuke
>
> 2020年1月28日(火) 4:44 Greg Mirsky <[e-mail]>om>:
>
>> 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]
>>> >:
>>>
>>>> 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
>>>
>> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
>