Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt

["Joel M. Halpern" <[e-mail]>]

Comments in-line, marked <jmh></jmh>.
I still have some substantive concerns.
Yours,
Joel

On 7/20/2020 6:53 PM, Kiran Makhijani wrote:
> Hi Joel,
> My apologies, I could not reply sooner. Many thanks for paying attention to the document and reviewing it.
> Please see inline.
> Cheers
> Kiran
> 
>> -----Original Message-----
>> From: Teas <[e-mail]> On Behalf Of Joel Halpern
>> Sent: Sunday, July 12, 2020 9:00 PM
>> To: [e-mail]
>> Subject: Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt
>>
>> My thanks to the design team for the update to this document.  It is much
>> improved.
>>
>> I a  unable to understand the third paragraph of section 4.1.2.  I do not know
>> what maximum occupancy refers to.  It seems to be talking about some kind of
>> notion of objectives applying to subsets of traffic within a slice.  But I can't tell.
>>
> [KM] Maximum occupancy implies that when transport slice will 'max out' or overall limit on the slice after which it becomes best effort (may not meet its SLOs). For example, a slice can support 20 flows each with 10 Mbps data rate but 21st flow may or may not get desired bandwidth and it is not an SLO violation. There could be different kinds of limits using objectives such as number of flows, total bandwidth, or may also be other things that a user could ask for such as, max number of addresses, nf instances, etc (this part is coming from NF related resources). This is important for both network operators and transport slice controllers to plan resource allocations better.

<jmh>I am having real trouble understanding what you want to accomplish 
with this maximum occupancy.  The example you give is 20 flows of 10 
Mbps each.  However, there is no parameter given taht is bps/flow.  And 
I would hope that there would not be.  How the customer divides his 
bandwidth up among his own traffic is up to him.  Bandwidth as a total 
does not have an "occupancy".  The service is guarnateed up to the 
stated bandwidth.  If you can justify a "number of flows" SLO, then we 
can have that, although from where I sit I can not see why any slice 
service would operate in those terms.  Many years experience with 
Internet Scaling has taught us that core scaling that is based on number 
of flows will fail. </jmh>

> 
>> Appendix A.1 is labeled as discussion, and as such appears to be trying to be
>> informative rather than normative.  However, the last paragraph of introduces
>> things a customer may ask for (i.e. SLOs) that are not described in the rest of
>> the document, and do not actually seem to me to be appropriate.  I wowuld ask
>> that the last paragraph of section A.1 be stricken.
> 
> [KM] Actually, we are saying these are 'not' SLOs and the customer may have specific asks (optionally).  Examples in this paragraph help in clarifying meanings of isolations, linking with VPN+  and may also be input to NBI. Considering this could be our top-level document, we/I prefer to provide some linkage to later documents. An upshot of doing this is we will not have to repeat the discussions we had - since it is already agreed upon and can be referred to.

<jmh> Given the way the document defines SLOs, if these are parameters 
the customer can request, and may want to monitor, then they are SLOs. 
If they are SLOs, they should not be hidden in an appendix.
And if this is for framing other discussion, I would have thought that 
was the job of the framework document, not the definitions document. 
And no, I do not think the examples help clarify the meaning of 
"isolation".  And no, I do not agree with the text.  So no, it is not 
"already agreed". </jmh>

>>
>> Some minor comments:
>>
>> At one point the SLA is defined (I believe reasonably)as the contract 5that
>> describes the SLOs with the consequences for missing them.  Then in section
>> 4.1 it says "all SLOs combine to form the SLA".  Believe you mean "form the
>> objective portion of the SLA"  or "contribute to the SLA"
>> or something, since the contractual and consequence aspects of the SLA are
>> outside of the SLOs?
> [KM] Yes, that is correct. We should add this statement ( contractual aspects of the SLAS are outside the scope) to improve the text.
>>
>> Given that availability is defined in terms of the other SLOs (quite
>> reasonable) and that some of those may not be directly measurable), it seems
>> that availability should itself be considered indirectly measurable?
>>
> [KM] Since we define it as "uptime to total_time", it is measurable, however that may be.
<jmh> Since I consider this minor, I will not insist on it.  But as far 
as I can tell, you can't measure uptime.  You measure whether other SLO 
parameters are met, and then calculate what portion of the time any of 
them were out of spec.  That sounds like an indirect measurement to 
me.</jmh>

> 
>> nit - Given that the earlier text says that this is only an initial list, there is no
>> need to include a bullet in the aspects that says "Other objectives could be
>> specified".  It is true.  But has already been stated above.
> 
> [KM] :-) It is there to separate measurable vs non-measurable asks. If the nsdt agrees, I don't mind removing the sub-heading.
> 
>> In section 4.2 on transport service endpoints, the text seems to say that an
>> endpoint has a specific kind of connectivity (P2P, P2MP, ...).
>> It seems perfectly valid for a single TSE to be using both P2P and P2MP
>> communication.  It seems rather odd to have to consider it to be two TSEs.
>>  From later text, it is the slice, not the endpoint, which as a particular
>> connectivity type.
> 
> [KM] Agree.  It is not supposed to imply 2 TSEs. If I understood correctly, you think 'MP2MP' does not make sense. Am I right? If yes, then at least I was thinking of direction of the traffic flow. i.e., traffic could flow out to different TSEs or flow in from different TSE sources. We will discuss how to improve the text - add explanation or remove MP2MP.
<jmh>I was not commenting on whether there is an MP2MP service.  I was 
commenting on the fact that the text seems to assign types to the TSEs 
rather than to the slice.  Given that you agree that one should not need 
two TSEs, please remove the text that says that TSEs have a type (Pt2Pt, 
Pt2MPT, ...) </jmh>

> 
>>
>> I wonder if the "Transport Slice Realization endpoint" is useful?  Given that
>> many things are in both the sample TSE list and the sample TSRE list, it is going
>> to be hard to tell them apart.  And as far as I can tell, the TSRE is internal to the
>> transport, and therefore outside the scope of this document?  The
>> differentiation in the diagram that follows the description does not seem to
>> line up with the description, and leaves me more confused.
> [KM] Yes, it is internal to transport. The reason we have them is to highlight the 1:N mappings. There may be more than one TSRE mapped to one TSE. Todo: need to think about improving the figure.

<jmh> I understand that things are realized.  And the question of how 
resources are used internally is internal.  I don't see the value in 
discussing it in this document.  I do not think the definition of TSRE 
will be used in any of the followon work. </jmh>

>>
>> Yours,
>> Joel
>>
>> On 7/12/2020 10:49 PM, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>           Title           : IETF Definition of Transport Slice
>>>           Authors         : Reza Rokui
>>>                             Shunsuke Homma
>>>                             Kiran Makhijani
>>>                             Luis M. Contreras
>>>                             Jeff Tantsura
>>> 	Filename        : draft-nsdt-teas-transport-slice-definition-03.txt
>>> 	Pages           : 21
>>> 	Date            : 2020-07-12
>>>
>>> Abstract:
>>>      This document describes the definition of a slice in the transport
>>>      networks and its characteristics.  The purpose here is to bring
>>>      clarity and a common understanding of the transport slice concept and
>>>      describe related terms and their meaning.  It explains how transport
>>>      slices can be used in combination with end to end network slices, or
>>>      independently.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>>> tracker.ietf.org%2Fdoc%2Fdraft-nsdt-teas-transport-slice-definition%2F
>>>
>> &amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b41549c
>> af08d82
>>>
>> 6e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302096
>> 09577396
>>>
>> 3&amp;sdata=7buYe3eJIHKFpKR09vulM9iebHux1y5ZS%2B8lDucs19A%3D&am
>> p;reser
>>> ved=0
>>>
>>> There are also htmlized versions available at:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
>>> s.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&amp;
>>>
>> data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b41549caf08d
>> 826e13a
>>>
>> ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63730209609577
>> 3963&amp
>>>
>> ;sdata=%2BDoN%2Fj%2BsIG4SidwevIEKt%2BAlEBSl5mGY%2BrV8bOKruxY%3D
>> &amp;re
>>> served=0
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-transport-slice-defini
>>> tion-
>> 03&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b415
>> 49c
>>>
>> af08d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
>> 3020960
>>>
>> 95773963&amp;sdata=rROaEyLnsvX3i83zAt3DKHD822SQ9cZ4vw05CZzGKYk%
>> 3D&amp;
>>> reserved=0
>>>
>>> A diff from the previous version is available at:
>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>> ietf.org%2Frfcdiff%3Furl2%3Ddraft-nsdt-teas-transport-slice-definition
>>> -
>> 03&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C7b2262bf8d9b415
>> 49caf08
>>>
>> d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302
>> 09609577
>>>
>> 3963&amp;sdata=VDTj6H50YyxvSKeUxXdDTxUmlhVb34%2FKkRIXMWd4W%2
>> BY%3D&amp;
>>> reserved=0
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
>>> tf.org%2Finternet-
>> drafts%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%
>>>
>> 7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753a1d559
>> 1fedc%
>>>
>> 7C1%7C0%7C637302096095783957&amp;sdata=P0ZsXdbhq7q%2BbaTOWOK
>> w8kXUEQQLn
>>> W4CILvj3D87Ghg%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
>> announce&amp;data=02%7C01%7Ckiranm
>>>
>> %40futurewei.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b
>> 24018
>>>
>> 9c753a1d5591fedc%7C1%7C0%7C637302096095783957&amp;sdata=UKy30l
>> dThBDSB%
>>> 2F9513KCraQ4ODcTtq%2F%2FDfHSwi8Y6Nk%3D&amp;reserved=0
>>> Internet-Draft directories:
>>>
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i
>>>
>> etf.org%2Fshadow.html&amp;data=02%7C01%7Ckiranm%40futurewei.com%
>> 7C7b22
>>>
>> 62bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753a1d5591fedc%
>> 7C1%7C
>>>
>> 0%7C637302096095783957&amp;sdata=c5sC8mBqP2lTaDxRiqMmVWXQVfBi
>> 0SGf1Nn1A
>>> 5Tiekg%3D&amp;reserved=0 or
>>> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
>>> tf.org%2Fietf%2F1shadow-
>> sites.txt&amp;data=02%7C01%7Ckiranm%40futurewe
>>>
>> i.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b240189c753
>> a1d559
>>>
>> 1fedc%7C1%7C0%7C637302096095783957&amp;sdata=7kPSpNmxVrwrE6by
>> 55jlY%2B5
>>> yBSHeMXgwZhPYM%2F9yj3Y%3D&amp;reserved=0
>>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fu
>> turewei.com%7C7b2262bf8d9b41549caf08d826e13aab%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C0%7C637302096095783957&amp;sdata=3q4fLZ
>> 2BdNuYfXsMHmGd%2Be0RO%2BBzxvi4%2FzvL0LCSKPM%3D&amp;reserved=
>> 0