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

[Jeff Tantsura <[e-mail]>]

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]>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
> -- 
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt