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

[John E Drake <[e-mail]>]

Precisely

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Sunday, August 30, 2020 11:31 PM
> To: Gengxuesong (Geng Xuesong) <[e-mail]>
> Cc: TEAS WG <[e-mail]>
> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition -
> Appendix
> 
> [External Email. Be cautious of content]
> 
> 
> Assuming the description you give below, I have two related questions.
> If the performance is great, why would the transport user care whether it is not
> actually isolated?
> Conversely, if the performance does not meet the needs, then why would the
> transport user care that isolation has been preserved?
> 
> Yours,
> Joel
> 
> On 8/30/2020 11:11 PM, Gengxuesong (Geng Xuesong) wrote:
> > Hi Greg,
> >
> > Thank you for directing the discussion to the technical nature of
> > isolation. Please find comments below:
> >
> > I assume that the term "isolation" is not simply a replacement for
> > "dedicated" and is intended to apply to cases when transport slices
> > share underlying infrastructure.
> >
> > I agree about your description of isolation. Although there may be
> > other kinds of understanding which will broaden the scope of this
> > concept. I will leave it to the authors and WG. The discussions below
> > based on the assumption that “isolation is intended to apply to cases
> > when transport slices share underlying infrastructure ”.
> >
> > There is a number of performance metrics that may indicate the lack of
> > isolation but that, in my view, can be attributed to under-isolation
> > (for the lack of better term at the moment) between slices as the
> > result of root cause analysis of increased latency and/or packet loss.
> >
> > I think here hides some basic logic behind the debate: if the
> > isolation could be described indirectly by other SLO attribute,
> > whether we still need it as an independent concept. My answer is: the
> > hypothetical part of the question is incorrect, because *isolation
> > can’t be described by other attributes, although it influences other
> > attributes.* A further conclusion is that : *Deterioration of other
> > SLO metrics is neither sufficient nor necessary for isolation
> > absence*. Two simple examples to defense this:
> >
> > 1.When isolation is perfectly executed that there is no interfere
> > among different slices, the performance could still be very terrible
> > if the resource inside the slice is exhausted.
> >
> > 2.When there is no isolation among slices and all the resource is
> > shared, the performance could still be very great if the resource is
> > sufficient for all the slices.
> >
> > So the trick here is: other SLO attributes (delay, jitter, loss…)
> > depend on whether there is enough cake to make everybody happy, and
> > isolation prevents other guys to touch my cake. They're relevant, but
> > they're different, and not interchangeable.
> >
> > That is why I agree that isolation should be clearly defined in
> > draft-nsdt-teas-transport-slice-definition, not in Appendix.
> >
> > Regards,
> >
> > Xuesong
> >
> > *From:*Greg Mirsky [mailto:[e-mail]]
> > *Sent:* Sunday, August 30, 2020 5:38 AM
> > *To:* Gengxuesong (Geng Xuesong) <[e-mail]>
> > *Cc:* Jeff Tantsura <[e-mail]>; TEAS WG
> > <[e-mail]>; Jari Arkko <[e-mail]>; Vishnu Pavan
> > Beeram <[e-mail]>
> > *Subject:* Re: [Teas] WG adoption -
> > draft-nsdt-teas-transport-slice-definition - Appendix
> >
> > Hi Xuesong,
> >
> > I assume that the term "isolation" is not simply a replacement for
> > "dedicated" and is intended to apply to cases when transport slices
> > share underlying infrastructure. If that is the case,  I think there's
> > a sort of contradiction between statements "isolation is SLO" and
> > "isolation is not directly measurable [calculable GIM]". I wonder,
> > What is the opposite of isolation as a TS characteristic? I imagine
> > that one example of that would be a case when the flow from one slice
> > is using resources from another, i.e., interference between slices.
> > There is a number of performance metrics that may indicate the lack of
> > isolation but that, in my view, can be attributed to under-isolation
> > (for the lack of better term at the moment) between slices as the
> > result of root cause analysis of increased latency and/or packet loss.
> > And even if interference from another slice doesn't result in
> > observable quality degradation, an operator can compare the offered
> > load from the customer with the available BW. And that information
> > doesn't have to be measured by the client but reported by the operator
> > in the agreed intervals and aggregated on an hourly and daily basis.
> > Certainly, we can have more cases that constitute the un-isolationism
> > of slices but that, I suspect, still will be observable, measurable,
> > calculable through other SLOs and only the analysis will point to the
> inadequate isolation of resources.
> >
> > But back to the isolation. I believe that the proposal from WG Chairs
> > is the best way forward. Let us explore our interpretations of the
> > term and work on formulating one we can build consensus (rough)
> > around. And if so happens that there is none, then we all get a better
> > understanding of the problem and may get it in the new document.
> >
> > Regards,
> >
> > Greg
> >
> > On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong)
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     +1
> >
> >     And one more supplementary comment about “Isolation is not a
> >     directly measurable SLO”. Maybe here is some fog about what is
> >     measurable. Isolation could not described by number/value. But it
> >     doesn’t mean that it is an abstract concept that could not be
> >     defined precisely. People are asking whether TE link is isolated or
> >     not. It could be clarified by some deep analysis, good discussions
> >     and clear text. There is no conclusion yet just because we don’t
> >     even allow it to be existing in an WG document. And I don’t think
> >     the definition of other SDOs really matter. Because isolation in
> >     mobile network is different from isolation in IETF. If there is
> >     requirement in IETF, define it in IETF. We can’t say we could not
> >     get to somewhere because there is no path. Build the path by ourselves.
> >
> >     Xuesong
> >
> >     *From:*Teas [mailto:[e-mail]
> >     <mailto:[e-mail]>] *On Behalf Of *Jeff Tantsura
> >     *Sent:* Wednesday, August 26, 2020 6:32 AM
> >     *To:* TEAS WG <[e-mail] <mailto:[e-mail]>>; Jari Arkko
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Cc:* Vishnu Pavan Beeram <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Subject:* Re: [Teas] WG adoption -
> >     draft-nsdt-teas-transport-slice-definition - Appendix
> >
> >     I find Pavan and Lou proposal reasonable and a good/working way forward.
> >     While isolation is not a directly measurable SLO, it is often a
> >     legally binding requirement wrt service provided, could be expressed
> >     as a physical SRLG or disjointness.
> >     It is also a viable constrain to be used in  a path computation logic.
> >     There are connectivity RFIs that explciteily require full physical
> >     separation/isolation - finance for security reasons,  DCI for
> >     resiliency, etc.
> >
> >     We could pretend it doesn’t exist (which is the complete removal) or
> >     find an appropriate and acceptable to the WG description as the
> >     document evolves.
> >
> >     Cheers,
> >
> >     Jeff
> >
> >     On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <[e-mail]
> >     <mailto:[e-mail]>>, wrote:
> >
> >         High-level bit: I would like to see the document adopted. With
> >         changes if needed. Let the WG decide. Design teams are there
> >         just for preparing proposals. Authority to do stuff is entirely
> >         in the WG now.
> >
> >         When it comes to the isolation topic, however, FWIW, I wanted to
> >         provide both a context from design team discussions and my
> >         personal perspective on this.
> >
> >         Design team discussions:
> >
> >         We’ve had variants of this discussion on almost all of the calls
> >         we’ve had for the last year. One one side there was our shared
> >         observation that industry uses the term isolation, and (perhaps
> >         less widely shared conclusion) that it is important to be able
> >         to relate to this. On the other side, there was our shared
> >         agreement that what matters from a requirement perspective is
> >         the bandwidth and other requirements, and that there are several
> >         techniques that can provide the desired characteristic of not
> >         having your neighbour affect the bandwidth the service provider
> >         has agreed to give you.
> >
> >         The text that we had was in an appendix precisely because we
> >         felt that the top-level SLOs should be the requirement and are
> >         sufficient by themselves. The appendix only attempts to say that
> >         “there’s multiple ways to achieve this, and by the way, this
> >         term in the industry relates to our work in this indirect way”..
> >
> >         I can appreciate that we may have failed in the task of writing
> >         that. Delete and move on, no biggie :-)
> >
> >         Personal perspective:
> >
> >         My impression of customer requirements and how they get
> >         represented matches with what Joel has been saying in this thread.
> >
> >         I’m fine removing the appendix.
> >
> >         If I had my way, I would write the document based entirely on
> >         the primary characteristics — such as that we promise you n
> >         GB/s. Then I would write a footnote or appendix somewhere that
> >         explains that this notion isolation has also been discussed
> >         elsewhere, and that it can be represented using the primary
> >         characteristics, and hence need not be discussed further in this
> >         document. One could perhaps also point out that there are
> >         multiple ways to implement the primary characteristics promises,
> >         so that those promises can be kept despite what’s happening with
> >         your neighbour’s traffic. And leave it at that. But I understand
> >         from this thread that people are reluctant to do that, and may
> >         even be reluctant to write anything about isolation. I’m fine
> >         with that, too.
> >
> >         Jari
> >
> >         _______________________________________________
> >         Teas mailing list
> >         [e-mail] <mailto:[e-mail]>
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail] <mailto:[e-mail]>
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1kPJeT478yjU$