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

[Shunsuke Homma <[e-mail]>]

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
>>
>