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 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]
主题: [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:

o   Situation 1 -  a slice customer request a slice for supporting a service that needs different SLOs in different part of the slice.

o   Situation 2 – two slice customers request a slice to support two different services that need different SLOs.

o   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.

o   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.

o   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------------>|
            |                                    |

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.
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.


·         Need of topology view in the higher system. Two comments here:

o   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.

o   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?


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