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

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi all,

I agree with Xuesong in the fact that we cannot leave the idea of isolation open to interpretation. This is precisely the reason why we need to have a definition on it in the context of transport slicing.

Best regards

Luis

De: Teas <[e-mail]> En nombre de Gengxuesong (Geng Xuesong)
Enviado el: jueves, 27 de agosto de 2020 4:28
Para: Daniele Ceccarelli <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; Jeff Tantsura <[e-mail]>; TEAS WG <[e-mail]>; Jari Arkko <[e-mail]>
CC: Vishnu Pavan Beeram <[e-mail]>
Asunto: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Daniele

You have pointed out some technique that may not be necessarily under the concept of isolation. The first one disjointness is used mostly for protection and the second one is a dedicated physical link/network for some service. Isolation, in my understanding, describes the requirement that the traffic of service won't interfere with each other when they are transmitted together. These two cases may not be included.
And, most importantly, these possible different understanding of this concept makes it more necessary to be clearly defined in the document.

Xuesong

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Wednesday, August 26, 2020 9:34 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; 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

Hi,

I see different interpretations of isolation and they make me think we don't need it, let me try to explain why.


  1.  In some cases I see as requirement the fact that a given traffic must not share a path with another type of traffic, or a port, or a link...that's what we commonly call "disjointness", right? We've been speaking about SRLG disjointness for decades.
  2.  In some other cases the requirement is not to have any type of interference from any type of traffic in the network...that's a leased line, or a dedicated network...we can't really speak about network slice there.

If I got the requirements right, I believe we already have all the cases covered.
Am I missing any other requirement?

BR
Daniele

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: den 26 augusti 2020 14:56
To: Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; 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 also agree with the proposal of the chairs, and think it is important to have input from the WG about these terms.

For isolation, there was some discussion in design team about classifying the isolation requirement into different dimensions in the context of IETF, such as: traffic separation, interference avoidance, failure protection, etc., then each can be mapped to corresponding mechanisms defined and developed in IETF.

Perhaps we could follow this way to clarify the meaning of isolation from a transport slice point of view, and may find suitable terms to refer to some specific isolation requirement.

Best regards,
Jie


From: Gengxuesong (Geng Xuesong)
Sent: Wednesday, August 26, 2020 10:40 AM
To: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; 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

+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]] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 26, 2020 6:32 AM
To: TEAS WG <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko@piuha...net<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://www.ietf.org/mailman/listinfo/teas

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o