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

[Kiran Makhijani <[e-mail]>]

Hi Joel, 

In defense of not removing the text I'd say, we should see this as a standalone/easy to read document that clarifies transport slice concepts (the what part). Unless there is strong justification, removing supporting text makes document too abstract/vague. Right now, I am not seeing strong reasons yet.

I pulled snippets up for better readability. Hope that's ok.

> 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.
[KM] The reason I use number of flows example is because transport slice may be of a particular kind of service e.g. eMBB or low latency. Then the characteristics of each flow will be roughly similar. I'd also think that when you talk about core scaling, you are thinking of implementation details. But customers would think only their own requirements not core network implementation.

>If they are SLOs, they should not be hidden in an appendix. ...it should be in the framework.
[km] we don’t say isolation is an SLO. Therefore, it is not in SLO section. It is a property of transport slice that user may ask for in one, many or all of the described ways. It is whatever gives customer the perception of "own dedicated network". I just want to have enough information in definitions so other documents are motivated to describe them further. 

> please remove the text that says that TSEs have a type (Pt2Pt, Pt2MPT, ...)
[km] Hmm, I looked at the document again. We don’t say TSE has a type. We say it is a connectivity type as in section ' 4.2.1.  Transport Slice Connectivity Types'. Will do proof reading again to make sure we don’t say endpoints have type.

> I do not think the definition of TSRE will be used in any of the
> followon work. 
Interesting point. Since it's only used with in the transport slice controller and not exposed to the user. When the network controller will return the "mapped things" do we need a name for them in our data models? I don't know the answer yet.
Will discuss this further in NSDT meeting.

Thanks
Kiran  

> -----Original Message-----
> From: Joel M. Halpern <[e-mail]>
> Sent: Monday, July 20, 2020 8:02 PM
> To: Kiran Makhijani <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt
> 
> 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