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

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 6 Aug 2020 15:12:02 +0000

Thanks Joel for your comments.

Please see inline for TSRE.

Reza

On 2020-07-12, 11:59 PM, "Teas on behalf of Joel Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    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.

[Reza]

As mentioned in draft, Transport slice realization endpoints (TSRE) are allocated and

assigned by the network controller during the realization of a  transport slice and are technology-specific, i.e. they depend on the

network technology used during the transport slice realization.

Depends on the definition of the transport slice, Transport Slice endpoints (TSE) and TSRE might be very similar but their object models are different.

Please also see the following draft which addresses the modeling of the transport slice realization:

  *   draft-liu-teas-transport-network-slice-yang-01

In summary, TRSE are assigned during the transport slice realization and will be communicated from TSC NBI to higher system “Transport slice Customer” and identifies how a transport slice is realized in the network.

We will add more clarification to the draft.

    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

    _______________________________________________

    Teas mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/teas

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 6 Aug 2020 11:17:01 -0400

Thank you for commenting the the TSRE question.
Let me reprase my question, given the comments...

Given that TSRE is strictly technology and infrastructure specific, why 
is it defined in this document?  Whether we need it or not it seems to 
be outside the scope of this document.

Yours,
Joel

On 8/6/2020 11:12 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> On 2020-07-12, 11:59 PM, "Teas on behalf of Joel Halpern" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> assigned by the network controller during the realization of a 
>   transport slice and are technology-specific, i.e. they depend on the
> 
> Depends on the definition of the transport slice, Transport Slice 
> endpoints (TSE) and TSRE might be very similar but their object models 
> are different.
> 
> In summary, TRSE are assigned during the transport slice realization and 
> will be communicated from TSC NBI to higher system “Transport slice 
> Customer” and identifies how a transport slice is realized in the network.
> 
>      >
>      > 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:
> 
>      > 
>      >
>      > There are also htmlized versions available at:
> 
>      > 
>      > 
>      >
>      > A diff from the previous version is available at:
> 
>      > 
>      >
>      >
>      > 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: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 10 Aug 2020 11:59:10 +0000

Joel

Please see inline.

Cheers,

Reza

On 2020-08-06, 11:17 AM, "Joel Halpern Direct" <[email-masked]> wrote:

[Reza] Since the transport slice definition draft addresses various aspects of the transport slice such transport slice realization were introduced and a result the TRSE was mentioned briefly to allow later drafts to discuss it in details.

Same is for example for “Transport Slice Controller (TSC)”. This document introduced the TSC concept and again later draft can give more details.

    Yours,

    Joel

    >      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

    >      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

    >      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

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

    >      seems that availability should itself be considered indirectly

    > measurable?

    >      It seems perfectly valid for a single TSE to be using both P2P and

    > P2MP

    >      I wonder if the "Transport Slice Realization endpoint" is useful?

    > Given

    >      scope of this document?  The differentiation in the diagram that

    > follows

    > As mentioned in draft, Transport slice realization endpoints (TSRE) are

    > allocated and

    > Please also see the following draft which addresses the modeling of the

    > transport slice realization:

    >      > A New Internet-Draft is available from the on-line

    >      >         Filename        :

    >      >     This document describes the definition of a slice in the

    >      >     clarity and a common understanding of the transport slice

    >      >     describe related terms and their meaning.  It explains how

    >      >     slices can be used in combination with end to end network

    >      > Please note that it may take a couple of minutes from the time of

---

From: Eric Gray <[email-masked]>
Date: Wed, 12 Aug 2020 09:45:33 -0400

Reza,

	On the topic of continued inclusion of TSRE.

	You are inappropriately assuming that we will _ever_ be undertaking standards work that details the much of the internals of the transport slice controller.

	I did not object to including some text on the topic of a South-Bound Interface (SBI) - even though this is also out of scope in our work (being again a part of the logical model for interactions between the TSC and “stuff” underlying it) - because of the argument that it is useful to think of an SBI in order to allow examples to be made for using various technology specific service models.

	This is legitimate, because the use of such examples suggests some similar work on technology-specific service models that might be useful for support some possible TSC implementations.

	But Joel makes a very good point in saying that TSRE is out of scope in this draft.  Also, Joel earlier made the point that including out-of-scope concepts strictly intended for use in future work is misguided.

	For our purposes, it would be more useful to limit ourselves to a simpler set of definitions that do not include additional and out-of-scope confusing concepts.

	Finally, your stance on whether or not to remove this concept should be based on TEAS working group consensus to continue to include it - rather than your personal inclinations to do so.  This draft was - after all - suggested for adoption by the working group, and subsequent changes will therefore be under the change control of the TEAS WG.

> On Aug 10, 2020, at 7:59 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> Joel
> Please see inline.
>  
> Cheers,
> Reza
>  
> On 2020-08-06, 11:17 AM, "Joel Halpern Direct" <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 12 Aug 2020 16:01:51 +0000

Eric:
In my mind, the scope at least for definitions is to identify components that help describe the transport slices concept and hopefully normalize the terms in context. It helps someone reading this document for the first time. I agree that NBI and upper layers will not see this mapping. On the other hand, framework and SBI when extended may use it.
We could balance clarity vs concerns raised by augmenting the text as below. What do you think?

   TSEs will get mapped to the endpoints that are allocated and
   assigned by the network controller during the realization of a
   transport slice and are technology-specific, i.e. they depend on the
   network technology used during the transport slice realization.  They
   are identified by a node and some associated data. They may be referred to as
   TSREs when necessary. A non-exhaustive
   list of nodes containing TSREs are routers, switches, PON nodes,
   Wireless nodes and Optical devices.

   When TSC receives a request via its NBI to create a transport slice between
   multiple TSEs, it will send the request via its SBI to realize the transport slice.
   The TSRE will be notified by network controller during TS realization to enable
   mapping between TSREs and the TSEs.

Thanks
Kiran

From: Teas <[email-masked]> On Behalf Of Eric Gray
Sent: Wednesday, August 12, 2020 6:46 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Cc: Joel Halpern Direct <[email-masked]>; [email-masked]
Subject: Re: [Teas] I-D Action: draft-nsdt-teas-transport-slice-definition-03.txt

Reza,

On Aug 10, 2020, at 7:59 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:

Joel
Please see inline.

Cheers,
Reza

On 2020-08-06, 11:17 AM, "Joel Halpern Direct" <[email-masked]<mailto:[email-masked]>> wrote:

    Yours,
    Joel

    On 8/6/2020 11:12 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
    > <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    >
    >      that an endpoint has a specific kind of connectivity (P2P, P2MP, ....).
    >
    >      On 7/12/2020 10:49 PM, [email-masked]<mailto:[email-masked]> wrote:
    >
    >      >
    >
    > https://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-nsdt-teas-transport-slice-definition%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948000379&sdata=bICHb3oQ2hIAdRRf8CNOZymu7vasTHEbdzVxJaZJfiA%3D&reserved=0>
    >
    >      >
    >
    > https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948010373&sdata=vyE5VdDvTyslo%2FRlk0KVlZBmQtlZ6DoAyetrUkru56I%3D&reserved=0>
    >
    >      >
    > https://datatracker.ietf.org/doc/html/draft-nsdt-teas-transport-slice-definition-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948010373&sdata=0wLSeZRxwfYUcrFKRw%2F%2FAFUPJ2dnVt86fHlxjapKUVs%3D&reserved=0>
    >
    >      >
    >
    > https://www.ietf.org/rfcdiff?url2=draft-nsdt-teas-transport-slice-definition-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948020371&sdata=giogMjMpGmobb0zz7YGsfHzI2tqSJbu4k2czUNOK7GI%3D&reserved=0>
    >
    >      >
    >
    >      >
    >
    >      > until the htmlized version and diff are available at tools.ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948030365&sdata=hghAQnNNIX%2FXfbv8X3z%2FIFy%2BHriu3%2BQcfe%2BXjfcJNKk%3D&reserved=0>.
    >
    >      >
    >
    >      > ftp://ftp.ietf.org/internet-drafts/<https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948030365&sdata=nVkpi%2Bv6JSbWF1PKm9LR8DNlNWQ5gf%2FhcBnfCM8Idcs%3D&reserved=0>
    >
    >      >
    >
    >      >
    >
    >      > [email-masked]<mailto:[email-masked]>
    >
    >      > https://www.ietf.org/mailman/listinfo/i-d-announce<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948040359&sdata=rRZCAC4mf982bb4C%2FYuTNThQQEir8%2BtWzXc9XcqKwRI%3D&reserved=0>
    >
    >      > Internet-Draft directories: http://www.ietf.org/shadow.html<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948040359&sdata=iU9vE1Uot8y3SQqravDe2pcGZKgMdzhLlL0C8KWP79I%3D&reserved=0>
    >
    >      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Fietf%2F1shadow-sites.txt&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948050355&sdata=gvaLMawMGuwUeaF9oDH2Wzi1pBadiBuVsBQogAHKiZs%3D&reserved=0>
    >
    >      >
    >
    >      [email-masked]<mailto:[email-masked]>
    >
    >      https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948060356&sdata=tpRGrMNo8l3QwFhsIYxprZmet6uRXMrI5jXzLf2HrsI%3D&reserved=0>
    >
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948060356&sdata=tpRGrMNo8l3QwFhsIYxprZmet6uRXMrI5jXzLf2HrsI%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 13 Aug 2020 13:48:38 -0700

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

Regards,
Greg

On Mon, Jul 20, 2020 at 8:01 PM Joel M. Halpern <[email-masked]> 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 <[email-masked]> On Behalf Of Joel Halpern
> >> Sent: Sunday, July 12, 2020 9:00 PM
> >> To: [email-masked]
> >> Subject: Re: [Teas] I-D Action:
> much
> >> improved.
> 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>
>
> >
> 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:
> >>
> 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"
> 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.
> >>
> 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>
>
> >
> 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.
> >
> that an
> >> endpoint has a specific kind of connectivity (P2P, P2MP, ...).
> 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>
>
> >
> >>
> 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
> >>
> >>> 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
> >>>
> >>>
> >>> 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
> >>>
> >>
> >> 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: Eric Gray <[email-masked]>
Date: Wed, 19 Aug 2020 10:37:39 -0400

Hi Kiran.

Your proposed text misses a few important points.

	On the topic of “SBI"
1) As mentioned multiple times, “SBI” is a logical concept that may or may not exist in any instance of TSC interactions.
2) As such, it is incorrect to assert that the TSC “will send the request via its SBI …”
3) In fact, a more accurate (and less restrictive) wording would be along the lines of “When a TSC receives a request via its NBI, it needs to map the NBI-provided information in the request to one or more transport slice realization instances, using - for example - some form of SBI.”

	On the topic of whether or not we need to include “TSRE"
4) TSRE is a concept that - as discussed so far - is not visible to the Transport Slice consumer.
5) As I have so far understood the concept, TSE and TSRE are not interchangeable (were they actually interchangeable, we should only define and use one of these terms) - hence it is not clear how it is even possible to refer to a TSE as a TSRE, let alone imagine why it would be “necessary.”

Note that - if the distinction between TSE and TSRE arises from the possibility that transport slice service termination points may exist either on consumer nodes, or on provider nodes - then this is something that would likely be visible to the slice consumer.  But - if that is the case - that has not been clear in ongoing discussions and is not AFAIK explicitly stated in the draft.

—
Eric

> On Aug 12, 2020, at 12:01 PM, Kiran Makhijani <[email-masked]> wrote:
> 
> Eric:
> On Aug 10, 2020, at 7:59 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Joel
> Please see inline.
>  
> Cheers,
> Reza
>  
>     > <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>     > 
>     >      On 7/12/2020 10:49 PM, [email-masked] <mailto:[email-masked]> wrote:
>     > 
>     >      >
>     > 
>     > https://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-nsdt-teas-transport-slice-definition%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948000379&sdata=bICHb3oQ2hIAdRRf8CNOZymu7vasTHEbdzVxJaZJfiA%3D&reserved=0>
>     > 
>     >      >
>     > 
>     > https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-03 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948010373&sdata=vyE5VdDvTyslo%2FRlk0KVlZBmQtlZ6DoAyetrUkru56I%3D&reserved=0>
>     > 
>     >      > 
>     > https://datatracker.ietf.org/doc/html/draft-nsdt-teas-transport-slice-definition-03 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948010373&sdata=0wLSeZRxwfYUcrFKRw%2F%2FAFUPJ2dnVt86fHlxjapKUVs%3D&reserved=0>
>     > 
>     >      >
>     > 
>     > https://www.ietf.org/rfcdiff?url2=draft-nsdt-teas-transport-slice-definition-03 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-nsdt-teas-transport-slice-definition-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948020371&sdata=giogMjMpGmobb0zz7YGsfHzI2tqSJbu4k2czUNOK7GI%3D&reserved=0>
>     > 
>     >      >
>     > 
>     >      >
>     > 
>     >      > until the htmlized version and diff are available at tools.ietf.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948030365&sdata=hghAQnNNIX%2FXfbv8X3z%2FIFy%2BHriu3%2BQcfe%2BXjfcJNKk%3D&reserved=0>.
>     > 
>     >      >
>     > 
>     >      > ftp://ftp.ietf.org/internet-drafts/ <https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948030365&sdata=nVkpi%2Bv6JSbWF1PKm9LR8DNlNWQ5gf%2FhcBnfCM8Idcs%3D&reserved=0>
>     > 
>     >      >
>     > 
>     >      >
>     > 
>     >      > [email-masked] <mailto:[email-masked]>
>     > 
>     >      > https://www.ietf.org/mailman/listinfo/i-d-announce <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948040359&sdata=rRZCAC4mf982bb4C%2FYuTNThQQEir8%2BtWzXc9XcqKwRI%3D&reserved=0>
>     > 
>     >      > Internet-Draft directories: http://www.ietf.org/shadow.html <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948040359&sdata=iU9vE1Uot8y3SQqravDe2pcGZKgMdzhLlL0C8KWP79I%3D&reserved=0>
>     > 
>     >      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Fietf%2F1shadow-sites.txt&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948050355&sdata=gvaLMawMGuwUeaF9oDH2Wzi1pBadiBuVsBQogAHKiZs%3D&reserved=0>
>     > 
>     >      >
>     > 
>     >      [email-masked] <mailto:[email-masked]>
>     > 
>     >      https://www.ietf.org/mailman/listinfo/teas <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948060356&sdata=tpRGrMNo8l3QwFhsIYxprZmet6uRXMrI5jXzLf2HrsI%3D&reserved=0>
>     > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cc540b0786b4147a7db5d08d83ec61e0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637328367948060356&sdata=tpRGrMNo8l3QwFhsIYxprZmet6uRXMrI5jXzLf2HrsI%3D&reserved=0>