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

[Young Lee <[e-mail]>]

+1

If isolation is not the right term in IETF, I'd think a reasonable
compromise is to use terms like 'sharing property' or a similar term. The
extreme case of the attributes under this property disjointness in
port/node/link/path level. This would be equivalent to private dedicated
network level if you will. Other level of sharing can be enumerated
thereof.

Thanks.
Young


2020년 8월 26일 (수) 오전 7:32, Jeff Tantsura <[e-mail]>님이 작성:

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