Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

["Wubo (lana)" <[e-mail]>]

Hi Kiran,

I agree with your consideration.  I think Reza mentioned at the last DT meeting that the definition draft will describe different SLOs in the same slice to avoid confusion.

I also agree with your thought on the multiple SLO use cases to be described in the framework draft or a new use case draft. Otherwise, this is not intuitive .

Thanks,
Bo
发件人: Teas-ns-dt [mailto:[e-mail]] 代表 Kiran Makhijani
发送时间: 2020年4月15日 4:55
收件人: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Wubo (lana) <[e-mail]>om>; [e-mail]
主题: Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis, Bo,
I just started to follow this thread and found bit concerning.

From some of the text below, it seems we may not be following the definition of slice properly. A slice corresponds to a set of SLO (and a service-vertical perhaps). So how can we have different SLOs with in a slice? This should not be permitted. If such a capability is needed it should be an orchestration on top (or independent) of the transport slice infrastructure. To me, over-generalizing the slices could make them too complex to operate and may also lose isolation characteristics.
Similarly,
some capability for steering the traffic or shaping the traffic or the like.
^^^^^
I think this in fact changes the SLO of the slice and should be treated so. Has augmenting slice SLOs have already been discussed? Sorry I missed Monday’s call.
-Kiran

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, April 14, 2020 12:42 PM
To: Wubo (lana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Bo,

Apologies for my late response.

See my replies also in-line, labeled as [Luis>>].

Thanks

Luis

De: Wubo (lana) <[e-mail]<mailto:[e-mail]>>
Enviado el: martes, 7 de abril de 2020 14:55
Para: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Asunto: Re: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis,

Thanks for the discussions , please see inline[Bo].

Best regards,
Bo

发件人: Teas-ns-dt [mailto:[e-mail]] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2020年4月7日 3:37
收件人: [e-mail]<mailto:[e-mail]>
主题: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi all,

Thanks for the good discussion today.

Let me share two thoughts regarding the discussions of today:


  *   Different SLOs for different TS members on the same slice. According to the discussion today, I think we need to differentiate two situations:
     *   Situation 1 -  a slice customer request a slice for supporting a service that needs different SLOs in different part of the slice.
     *   Situation 2 – two slice customers request a slice to support two different services that need different SLOs.
     *   In situation 1, I think it could be feasible to support the different SLOs on the slice, since those SLOs will apply to different parts of the slice, e.g. different BW in access than in the central point providing content to all the accesses.
     *   In situation 2, however, it is not so intuitive that the two customers could be accommodated on the same slice. For instance, there could be different (not always compatible) SLOs for the same part of the slice (either access, central point, etc), or one of the customers could require some on-the-fly reconfigurations that could impact or interfere the other customer’s service.
     *   Maybe my problem here is the concept of TS member if synonymous of TS customer. Two different customers could share a slice without problem if the SLOs are equivalent, and/or if any action from one customer cannot interfere on the other (either because there are isolation mechanisms in place or simply because the customer is not allowed to perform any re-configuration). But if that is not the case, then it is not so easy to make different customer co-exist (too much complexity, it seems easier to go for different slices). So probably re-defining the idea of TS member the issue of sharing or dividing a slice between parts with different SLOs could be more clear.
[Bo]
I agree that TS-members need to be more clearly defined to avoid these confusion. Please let me confirm with you:

For the situation 1, you mentioned "different SLOs in different parts of the slice".
Taken the figure below as an example, Do you mean that the SLO of EP3-EP4 can be different from that of EP1-EP3 or EP1-EP4, but multiple SLOs between EP1 and EP3 are not allowed?
                 +--------------------------+
                 |                          |
  +-----+  /--\  |                          |  /--\   +-------+
  |     +-+ EP1+-+                          +-+ EP3+--+ Site2 |
  |Site1|  \--/  |                          |  \--/   +-------+
  |     |        |                          |
  |     |  /--\  |                          |  /--\   +-------+
  |     +-+ EP2|-+                          +-+ EP4+--+ Site3 |
  +-----+  \--/  |                          |  \--/   +-------+
                 |        Transport         |
                 |        Network           |
                 +--------------------------+
            |                                    |
            |<-----Transport Slice n------------>|
            |                                    |

[Luis>>] Let me give you an example. You may want to connect a number of gNBs with let’s say 10 Gbps, but support the connection of the UPF where some application is connected with 100 Gbps, allowing this application buffering (i.e., not stringent requirement in terms of latency). So in this case we have different SLOs in terms of guaranteed BW in different parts of the slice, but for the same slice customer.
But could be the case another customer could request a slice to support similar connectivity but needing a extremely low latency (maybe for a V2X service, with critical response). Then, even if both slices are compatible in terms of throughput, they are not compatible in terms of latency. For sure, a slice adapted for customer 2 satisfies the requirements of customer 1 as well, but it is probably more convenient to create two different slices, one adapted to each customer. Think in other attributes such as MTU size, support of group communications, etc. All of these can make difficult to determine the possibility of making services from customers to co-exist.
But things can become either more complex if the customer have some possibility of taking actions on the transport resources allocated to it. I’m thinking on some capability for steering the traffic or shaping the traffic or the like. This “control” capabilities can interfere with the traffic from other customers, making such co-existence impossible, and forcing to have different slices for those customers (and guaranteeing isolation among them).

For the situation 2, based on my understanding of  the nsdt-transport-definition draft, even if two TS customers share one TS, the TS are not aware of the different customer services. Therefore, the TS-member cannot be used to distinguish customer services.

[Luis>>] So this means that similar customers can coexist. That’s fine if the SLO’s are compatible and no (“control”) actions from one customer can impact other customers in that slice. That’s fine.

Assume it’s the case that two customers share the same TS slice by requesting same part uses different SLO, for example, SLO in EP1-EP3, and the two customers do not affect each other.
If the different SLO definition uses the TS-member to distinguish, there may be no clear distinction of TS-member and TS definition.

[Luis>>] I guess that in that case we would require to do the same as we today on non-sliced networks. Basically to take care of the individual customer service on the multi-service network (at the time of planning, operating, etc). I think that in this case the concept of slice is diluted.


  *   Need of topology view in the higher system. Two comments here:
     *   In this respect it could be needed for the higher system to pass some geographical or location related information to the TSC. Having to pass this kind of information not necessarily require to have a topological view of the transport network (i.e., it can be passed without having that view), but probably having the topological view (or some detail of) could simplify the process and assist higher systems in their process.
     *   When thinking on the connection to the end-points, such the case for gNB’s and UPF’s as we saw today, the higher system would benefit from having a consistent topological view that could assist it on properly instructing both the TSC and the other controllers to identify the end points. For that I can agree we can have yet the black box approach internally to the transport part. Again, probably some geographical or location information could assist on the process.
[Bo] To clarify the  question,  do you mean:
Comment 1: Use geographical or location related information  instead of the TS endpoint to define TS abstract topology?
Comment 2: Better to add  geographical or location related information to the TS endpoint?

[Luis>>] I was thinking on the case, for instance, of having to stitch a slice in the RAN with a slice in the CN. The upper systems needs some means of associating and understanding what are the end to stitch from an end-to-end perspective, and maybe some details on topological options. For example, it can be possible to associate a gNB with a UPF in region A and another UPF in region B (e.g., for pooling), and for that maybe it is interesting to have some high level topological detail in the transport part, plus a view of where is the gNB and the two UPFs.


Just to share my thoughts after today’s meeting,

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): [phone]
Mobile: [phone]
[e-mail]<mailto:[e-mail]>



________________________________

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

________________________________

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