Re: [Teas-ns-dt] Notes from the 2nd call

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

Hi Kiran, all,

Some thoughts from my side on your comments, in-line

Best regards

Luis

De: Teas-ns-dt <[e-mail]> En nombre de Kiran Makhijani
Enviado el: martes, 8 de octubre de 2019 18:45
Para: Eric Gray <eric.gray=[e-mail]>; [e-mail]
CC: Jari Arkko <jari.arkko=[e-mail]>
Asunto: Re: [Teas-ns-dt] Notes from the 2nd call

Hello ns-dt,

-          It’s a good suggestion to support the presented use case. In addition, it should be possible run this use case through a couple of anticipated applications such as (maybe) high-bandwidth media distribution, something with low-latency or a plain traffic-engineered VPN.  This use case is also interesting in defining e2e, which is the entry/exit to the network (at access level) that an operator will orchestrate i.e. not from the end-user/subscriber.
[Luis>>] I think that for the two first applications, the high-bandwidth or low latency one, we can derive the requirements to be supported from the exercise on the generic slice template, since we can assume that the customer of such slice (at least in short term) will be some 3GPP-based solution. For the third one, the traffic engineered VPN (slice) we would need to identify a prototypical request for such kind of service in a manner that we can do the same exercise of understanding what could be requested to the transport network. This can be maybe perceived as trivial, but probably we can find various similarities with the other two cases meaning that the same kind of parameters can be used for all of them. Existing models for L2 or L3 VPN could assist us on this exercise. By the way, it could be the case that a high-bandwidth or low latency service became finally mapped (maybe partially) to some form of L2 or L3 VPN.
-          From the scope or requirements I am not sure how the ns-dt feels about these 3 items:
1.       Isolations: To consider what kind of isolations will be offered to the user of a network-slice? E.g. in terms of address-space, FIB and other such capabilities.
[Luis>>] If we understand isolation as service guarantee, so no impacts among services, then the kind of isolation to be considered could be the ones assisting on providing such a guarantee: QoS mechanisms, traffic engineering, etc. In some extreme cases this could require dedication of resources with a sacrifice of resource optimization.
2.       Routing/Policies: whether the user should be able to specify its own routing and policies with in a slice.
[Luis>>] I think this can be related to the previous point. The capabilities of the user for performing actions in the network would depend on the level of isolation. Full control probably imply resource dedication for such user.
3.       Slice stitching: mechanisms to bind 2 sub-slices together (maybe by end to end tunnel or simply by translations) – model or southbound interface to describe this at domain boundaries?
[Luis>>] Thinking on initial deployments, where there would not be full slice awareness in a deployed network, stitching would probably result in the mere interconnection of end points (serving as entry points to the slices) with some service guarantees. Maybe this model could be kept in the future.
--
Regards,
Kiran



From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> on behalf of Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>
Date: Tuesday, October 8, 2019 at 10:34 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>
Subject: Re: [Teas-ns-dt] Notes from the 2nd call

Some comments about the notes below:

1)      On the Use Case presented by Reza:
a.      This should be considered an example use case, as opposed to a generic one – though it is a more inclusive use case than many I have seen
b.      The term “midhaul” has yet to be defined consistently in the industry; MEF tried proposing a definition to ITU-T that was rejected and ITU-T has been working to come up with something better.  Consequently, MEF is using the 3GPP concepts of functional splits, specifically including higher layer split (HLS – split between DU & CU) and Lower Layer Split (LLS – interfaces C1 and C2, corresponding to CPRI and eCPRI respectively).
c.       At least some in the IETF are likely to view this use case illustration as some sort of invitation to work on the overall orchestration model for “e2e” network slices; there are many that would not support any such effort, most likely including 3GPP.
d.      There are other ways to do “e2e” network slices – not to mention that there are other interpretations for what “e2e” means.
2)      Using the above as a segue, in the current minutes, the following statement is present -
“For back-haul, there needs to be a mapping from RAN slices & bearers & QoS into how it is transported, and carried onto core.”
a.      There does need to be such a mapping, but different mobile operators are likely to want to do this in different ways.
b.      It is extremely unlikely that the IETF will be the group to document even the alternatives.
c.       What I strongly suspect the IETF needs to do is provide models and protocol support for the “plumbing” needed by mobile operators to implement their choices of techniques for mapping network slices to bearers, QoS, etc. (there was an operator representative [Century Link] that made this point in the BBF quite a while ago).
3)      The version of GSMA network slice template I have seen (dated 23 May, 2019) is explicitly a work in progress, and has a number of editorial issues (particularly with references) that make it hard to read and understand; I am curious if this is the same version that Luis indicated he has used in analysis.

--
Eric



From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Monday, October 7, 2019 10:17 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] Notes from the 2nd call


Are here:

https://etherpad.net/p/teas-ns-dt-call2<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Furl%3Fk%3D96d2d341-ca06de33-96d293da-86859b2931b3-c715649a60e2b086%26q%3D1%26u%3Dhttps%253A%252F%252Fetherpad.net%252Fp%252Fteas-ns-dt-call2&data=02%7C01%7Ckiranm%40futurewei.com%7C1619d0504a174badd29c08d74c050216%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637061456722974354&sdata=uhWOD4Tfu3HeXTdai0dzmt0SCwB%2F5kGfeP6c3%2BDv6Kw%3D&reserved=0>

Feel free to edit/add as needed.

jari


________________________________

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