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

[Greg Mirsky <[e-mail]>]

Dear Joel, Kiran, et al.,
I want to bring to your attention a draft that we've submitted right before
IETF-108 - Error Performance Measurement in Packet-switched Networks
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/>. As part of
defining metrics of EPM, the document specifies the method to detect and
measure availability and unavailability. I hope you'll be interested and
much appreciate your comments, including the IPPM WG list <[e-mail]>.

Regards,
Greg

On Mon, Jul 20, 2020 at 8:01 PM Joel M. Halpern <[e-mail]> wrote:

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