Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

["Luis M. Contreras" <[e-mail]>]

Hi Joel,

please, see my replies in-line.

Best regards

Luis

El vie., 21 ago. 2020 a las 17:42, Joel M. Halpern (<[e-mail]>)
escribió:

> Luis, I think I disagree with you.
> Not of course, about the question of whether operators care about
> isolation properties.
> But about whether it belongs in this document.
>
> I am quite sure that when designing services for customers, you and your
> team worry about many forms of isolation.  Many of which do not appear
> in the eventual SLA (even if they do occur in informal discussion).  And
> many of which do not appear as explicit parameters on any of the
> interfaces.
>
> [Luis>>] At first stage, it can be expected some form of isolation
attribute in the slice request at least for 3GPP based services, but this
will be extended to other services in the future. Since all those
communication services are "client" of the transport network, it is
necessary to define isolation in the context of transport slice in order to
provide guidance to operators. Not having it, the consequence is that a
significant gap is created.


> The authors attempted t provide an observable definition of isolation.
> They were not able to do so.  The text they now have tries to claim
> utility, claims relevance to the customer, but is not acutally usable in
> designing a service.
>
> [Luis>>] In my view, expressing isolation intents (whatever the form could
be, which is for further work) precisely provides guidance on the design of
a transport slice. Different degrees of isolation could impose different
constraints on the transport slice. In other words, different customers
requiring a transport slice with similar measurable SLOs (in terms of
throughput, latency, etc) but different isolation needs will be honored
with a distinct transport slice realization, which will take into account
the constraints derived from the specific isolation requirements.

"Isolation" as a network property probably is actually many different
> properties.  For example, a bandwidth commitment (which we do have in
> the definitions) is a form of isolation.  A delay variation commitment
> is a form of isolation.  But as a term on its own, separate from these
> parameters, "isolation" does not add value to this document.
>

[Luis>>] I agree on the fact that isolation can be probably realized in
different manners. But isolation can be not only related to performance
issues, but others such as security, service continuity, service
specialization, etc. Whatever reason why the customer could ask for
isolation is him / her decision. Leaving the operator to infer the service
expectations of the customer in terms of isolation is not the way, I think.
Then processing of explicit isolation needs has value for fulfilling
customer's expectations. Otherwise, how can be ensure a given transport
slice request when the customer has some isolation needs?

>
> Also remember that no document we produce will be or can bee complete.
> We produce useful pieces.  You put them together.  As an operator you
> add your many constraints, your customers goals and constraints, and you
> build and deliver service.
>
> [Luis>>] I agree, but incompleteness can happen because two reasons: (1)
we don't anticipate the problem, and because of that, the problem cannot be
tackle, producing and incomplete document; and (2) we don't cover a certain
issue on purpose, even we recognize it is a key (or at least,
controversial) aspect for the problem. We are in the second case now, and I
think, again from the perspective of an operator, we need to cover it. The
development of isolation implications in transport slices is out of the
scope of definitions draft, but isolation, as an important (and specific)
topic of transport slices, should be in definitions draft.

Yours,
> Joel
>
> On 8/21/2020 4:49 AM, Luis M. Contreras wrote:
> > Hi Jie, Joel, all,
> >
> > Just to share my view. The idea of isolation is intrinsically related to
> > the notion of slice in the industry, and as such it should be covered in
> > the definitions draft when referring to transport slices.
> >
> > The development of what isolation implies, in practical terms, could go
> > to the framework draft or to any other specific document, and for sure
> > we can expect references to degrees of isolation achieved in the mapping
> > of slicing mechanisms to distinct transport technologies through the SBI
> > of the TSC.
> >
> > Not covering isolation at all, basically makes the work on transport
> > slicing incomplete from an operator’s perspective.
> >
> > In that sense I support keeping the text on isolation (as an annex or in
> > the main part of the document). For sure the text can be always
> > improved, but as it is now is a sufficiently generic definition to
> > facilitate the development of its scope when applied to transport
> > slicing in any other document.
> >
> > Best regards,
> >
> > Luis
> >
> >
> > El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy) (<[e-mail]
> > <mailto:[e-mail]>>) escribió:
> >
> >     Hi Joel,
> >
> >     Thanks for your clarification about the procedure.
> >
> >     What I meant is to provide some background about the design team's
> >     discussion, which may help the WG to review and give comments on
> >     this draft. Of course the decision will be made by the WG.
> >
> >     One of the reasons of keeping the isolation discussion in this draft
> >     is that isolation has been considered as one of the characteristics
> >     of network slicing in most of the related standards and
> >     publications, and it would be incomplete if the definition draft
> >     does not touch this. And in IETF history isolation has been
> >     considered as one requirement of VPNs, the discussion is necessary
> >     for explaining the relationship and difference between network slice
> >     and VPNs. Also note that in the last paragraph of the appendix, it
> >     tries to separate the requirements on isolation from several
> >     possible realization mechanism, which makes this description
> >     reasonably generic.
> >
> >     Best regards,
> >     Jie
> >
> >
> >      > -----Original Message-----
> >      > From: Joel Halpern Direct [mailto:[e-mail]
> >     <mailto:[e-mail]>]
> >      > Sent: Friday, August 21, 2020 11:28 AM
> >      > To: Dongjie (Jimmy) <[e-mail]
> >     <mailto:[e-mail]>>; Kiran Makhijani
> >      > <[e-mail] <mailto:[e-mail]>>; Vishnu
> >     Pavan Beeram
> >      > <[e-mail] <mailto:[e-mail]>>; TEAS WG
> >     <[e-mail] <mailto:[e-mail]>>
> >      > Subject: Re: [Teas] WG adoption -
> >     draft-nsdt-teas-transport-slice-definition -
> >      > Appendix
> >      >
> >      > The consensus of the design team is relevant as a recommendation
> >     to the
> >      > WG, but otherwise is not relevant for whether the WG should
> >     agree.  In
> >      > terms of WG adoption, the design team draft has the same status
> >     as any
> >      > other individual draft. The WG comes to its conclusion.
> >      >
> >      > There is no obligation for the WG to retain the text from the
> >     appendix
> >      > anywhere.  In particular, the WG is under no obligation to retain
> >     the last
> >      > paragraph of teh appendix anywhere.
> >      >
> >      > I have not seen any good argument for retaining the text.  It
> >     does not seem
> >      > to add to or even fit with the purpose of the definitions draft.
> >      > If anything, it is confusing at it seems to say "this is not a
> >     parameter / this is
> >      > a parameter"
> >      >
> >      > Yours,
> >      > Joel
> >      >
> >      > On 8/20/2020 11:17 PM, Dongjie (Jimmy) wrote:
> >      > > Hi Joel,
> >      > >
> >      > > In the design team there were several rounds of discussion
> >     about the
> >      > content in the appendix and where it should be placed. The
> >     current text in
> >      > the appendix reflects the consensus of the design team, although
> some
> >      > minor edits were not included yet.
> >      > >
> >      > > As for whether some of the text in appendix will be moved to the
> >      > framework document, currently the design team has no specific
> opinion
> >      > about this, and feedbacks from WG are appreciated. While as Kiran
> >      > mentioned, description and discussion about isolation is needed
> >     in the NS-DT
> >      > documents.
> >      > >
> >      > > Best regards,
> >      > > Jie
> >      > >
> >      > >> -----Original Message-----
> >      > >> From: Teas [mailto:[e-mail]
> >     <mailto:[e-mail]>] On Behalf Of Joel M.
> >      > >> Halpern
> >      > >> Sent: Friday, August 21, 2020 7:00 AM
> >      > >> To: Kiran Makhijani <[e-mail]
> >     <mailto:[e-mail]>>; Vishnu Pavan Beeram
> >      > >> <[e-mail] <mailto:[e-mail]>>; TEAS
> >     WG <[e-mail] <mailto:[e-mail]>>
> >      > >> Subject: Re: [Teas] WG adoption -
> >      > >> draft-nsdt-teas-transport-slice-definition - Appendix
> >      > >>
> >      > >> Since I do not think that the material in the appendix is
> >     useful, I
> >      > >> for one will not push for adding it to the Framework.  You are
> >      > >> welcome to dabate adding it to the framework with the rest of
> >     the WG.
> >      > >> But it does not belong in the definitions draft.
> >      > >>
> >      > >> Yours,
> >      > >> Joel
> >      > >>
> >      > >> On 8/20/2020 5:20 PM, Kiran Makhijani wrote:
> >      > >>> Hi Joel,
> >      > >>> I am ok to remove some part from Appendix only if it is
> >     included in
> >      > >>> the
> >      > >> framework first.
> >      > >>>
> >      > >>> But for the TSRE, I have proposed clearer and shorter text
> >     that they
> >      > >>> are not
> >      > >> visible to the consumer of a transport slices. One of the
> >     purpose of
> >      > >> definitions document is 'define' common terminology in the
> >     scope of
> >      > >> transport slices, and all we are saying is that when realizing
> a
> >      > >> transport slice, things TSEs will map to are called TSREs.
> >      > >>> I am not able to see the drawback of saying so.
> >      > >>>
> >      > >>> Thanks
> >      > >>> Kiran
> >      > >>>
> >      > >>>> -----Original Message-----
> >      > >>>> From: Joel Halpern Direct <[e-mail]
> >     <mailto:[e-mail]>>
> >      > >>>> Sent: Thursday, August 20, 2020 1:19 PM
> >      > >>>> To: Kiran Makhijani <[e-mail]
> >     <mailto:[e-mail]>>; Vishnu Pavan Beeram
> >      > >>>> <[e-mail] <mailto:[e-mail]>>; TEAS
> >     WG <[e-mail] <mailto:[e-mail]>>
> >      > >>>> Subject: Re: [Teas] WG adoption -
> >      > >>>> draft-nsdt-teas-transport-slice-definition
> >      > >>>>
> >      > >>>> No, your replies did not in any way address my concerns.
> >      > >>>>
> >      > >>>> I would suggest removing the references to TSRE and more
> >      > >>>> importantly removing appendix A.1, or at least the last part
> >     of the
> >      > appendix.
> >      > >>>>
> >      > >>>> Yours,
> >      > >>>> Joel
> >      > >>>>
> >      > >>>> On 8/20/2020 2:54 PM, Kiran Makhijani wrote:
> >      > >>>>> Hi Joel,
> >      > >>>>> After having replied to your comments, we have not heard
> >     further
> >      > >>>>> if they
> >      > >>>> were convincing.
> >      > >>>>> Please let us know.
> >      > >>>>> Thanks
> >      > >>>>> Kiran
> >      > >>>>>
> >      > >>>>>> -----Original Message-----
> >      > >>>>>> From: Teas <[e-mail]
> >     <mailto:[e-mail]>> On Behalf Of Joel M. Halpern
> >      > >>>>>> Sent: Wednesday, August 19, 2020 9:04 AM
> >      > >>>>>> To: Vishnu Pavan Beeram <[e-mail]
> >     <mailto:[e-mail]>>; TEAS WG
> >      > >>>>>> <[e-mail] <mailto:[e-mail]>>
> >      > >>>>>> Subject: Re: [Teas] WG adoption -
> >      > >>>>>> draft-nsdt-teas-transport-slice-definition
> >      > >>>>>>
> >      > >>>>>> Without repairs to the issues I have raised on the email
> >     list, I
> >      > >>>>>> do not think this document should be adopted as a WG
> document.
> >      > >>>>>> We are close, but not quite there.
> >      > >>>>>>
> >      > >>>>>> Yours,
> >      > >>>>>> Joel
> >      > >>>>>>
> >      > >>>>>> On 8/19/2020 11:50 AM, Vishnu Pavan Beeram wrote:
> >      > >>>>>>> All,
> >      > >>>>>>>
> >      > >>>>>>> This is start of a *three* week poll on making
> >      > >>>>>>> draft-nsdt-teas-transport-slice-definition-03 a TEAS
> working
> >      > >>>>>>> group
> >      > >>>>>> document.
> >      > >>>>>>> Please send email to the list indicating "yes/support" or
> >     "no/do
> >      > >>>>>>> not support". If indicating no, please state your
> >     reservations
> >      > >>>>>>> with the document. If yes, please also feel free to
> provide
> >      > >>>>>>> comments you'd like to see addressed once the document is
> >     a WG
> >      > >> document.
> >      > >>>>>>>
> >      > >>>>>>> The poll ends September 9th (extra week to account for
> >     vacation
> >      > >> season).
> >      > >>>>>>>
> >      > >>>>>>> Thanks,
> >      > >>>>>>> Pavan and Lou
> >      > >>>>>>>
> >      > >>>>>>> _______________________________________________
> >      > >>>>>>> Teas mailing list
> >      > >>>>>>> [e-mail] <mailto:[e-mail]>
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >      > w.
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > ietf.org
> >     <http://ietf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>>>> utur
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >     <http://ewei.com
> >%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>>>> c753a1d
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
> >      > 2B
> >      > >>>>>> RAlZTXBv5
> >      > >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>>> _______________________________________________
> >      > >>>>>> Teas mailing list
> >      > >>>>>> [e-mail] <mailto:[e-mail]>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >      > w
> >      > >>>>>> .i
> >      > >>>>
> >      > >>
> >      > etf.org
> >     <http://etf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> >      > u
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > turewei.com
> >     <http://turewei.com
> >%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
> >      > 01
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
> >      > G
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
> >      > 0
> >      > >>>>>
> >      > >>>>> _______________________________________________
> >      > >>>>> Teas mailing list
> >      > >>>>> [e-mail] <mailto:[e-mail]>
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >      > w.
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      > ietf.org
> >     <http://ietf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>> utur
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >     <http://ewei.com
> >%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>> c753a1d
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      > 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
> >      > BL
> >      > >>>> sLRq9T9a
> >      > >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
> >      > >>>>>
> >      > >>
> >      > >> _______________________________________________
> >      > >> Teas mailing list
> >      > >> [e-mail] <mailto:[e-mail]>
> >      > >> https://www.ietf.org/mailman/listinfo/teas
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
> >
> > --
> > ___________________________________________
> > Luis M. Contreras
> > [e-mail] <mailto:[e-mail]>
> > [e-mail]
> > <mailto:[e-mail]>
> > Global CTIO unit / Telefonica
>


-- 
___________________________________________
Luis M. Contreras
[e-mail]
[e-mail]
Global CTIO unit / Telefonica