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

From: Joel Halpern <[email-masked]>
Date: Sun, 12 Jul 2020 23:59:32 -0400

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.

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.

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?

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?

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.

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.

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.

Yours,
Joel

On 7/12/2020 10:49 PM, [email-masked] 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://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-03
> https://datatracker.ietf.org/doc/html/draft-nsdt-teas-transport-slice-definition-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-nsdt-teas-transport-slice-definition-03
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 20 Jul 2020 22:53:22 +0000

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 <[email-masked]> On Behalf Of Joel Halpern
> Sent: Sunday, July 12, 2020 9:00 PM
> To: [email-masked]
> 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.

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

> 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, ...).
> 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.

> 
> 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.
> > 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
> >
> > 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
> >
> 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.
> >
> > 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
> >
> >
> 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
> [email-masked]
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Jul 2020 23:01:33 -0400

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

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

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

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

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

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

> [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.…
<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>

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

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 21 Jul 2020 05:21:24 +0000

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  

> From: Joel M. Halpern <[email-masked]>
> Sent: Monday, July 20, 2020 8:02 PM
> To: Kiran Makhijani <[email-masked]>; [email-masked]
> Cc: [email-masked]
> >> Subject: Re: [Teas] I-D Action:
> >> draft-nsdt-teas-transport-slice-definition-03.txt
> >>
> >> 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
> > [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.
> 
> 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.
> 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:
> >>
> >> 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.
> >>
> >> reasonable) and that some of those may not be directly measurable),
> >> it seems that availability should itself be considered indirectly measurable?
> >>
> <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>
> 
> >
> >> "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.
> >
> >> 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
> > [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.
> 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
> >>