Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

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

Hi all,

Apologies for jumping late on this.

Regarding the comment on alignment between draft-srld-teas-5g-slicing and draft-gcdrb-teas-5g-network-slice-application (now draft-ietf-teas-5g-network-slice-application), yes, I confirm we will work on making both drafts consistent as well as avoiding overlaps. Both drafts are running on parallel so this is why there could be some temporal overlaps but the final objective for sure is to remove those overlaps, cross-referencing both when necessary for a complementary reading and understanding. There are common contributors to both documents, so this should be done naturally.

Best regards

Luis

De: Teas <[e-mail]> En nombre de [e-mail]
Enviado el: martes, 25 de abril de 2023 15:57
Para: [e-mail]; 'Krzysztof Szarkowicz' <[e-mail]>
CC: Oscar González de Dios <[e-mail]>; 'TEAS WG' <[e-mail]>
Asunto: Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

Hi Adrian,

Please see inline some comments with a focus on two points from your review.

Cheers,
Med

De : Teas <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel
Envoyé : mercredi 19 avril 2023 23:32
À : 'Krzysztof Szarkowicz' <[e-mail]<mailto:[e-mail]>>
Cc : 'Oscar González de Dios' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

Hi Krzysztof,

Thanks for all of the work.

> We just punished updated (v-07) draft.

Yeah, I know. It deserved it. :-)

I think, given the scale of the changes, the draft deserves a full top-to-bottom reading. I'll put that on my list. I'll cut straight to -08.

In the meantime, thanks for the detailed responses. A few additional comment in line. See [af].

Best,
Adrian

From: Krzysztof Szarkowicz <[e-mail]<mailto:[e-mail]>>
Sent: 19 April 2023 12:25
To: [e-mail]<mailto:[e-mail]>
Cc: Oscar González de Dios <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

[Med] ...

On 2023 -Apr-07, at 10:51, Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:

Hi Oscar, all,

I've read this draft as part of the adoption poll, and I attach some
comments. My current view is that, while the topic covered by the title of
the draft is important and should be worked on within the working group,
this document is not ready for adoption. I set out my reasons below, and
also provide some detailed review comments: most of the detailed minor
comments and nits could wait until after adoption, but the major issues form
part of my reservations about adopting the current revision.

Thanks,
Adrian

===

My take-away from this document is that it does three things:
- Describes 5G end-to-end network slices and their component parts
- Describes the general mapping and connections when 5G slices utilise IETF
transport slices
- Talks about specifics of using existing IP/MPLS (and SR) techniques to
realise IETF transport slices and stitch them into e2e slices

I think a good chunk of the description of 5G slices has been moved to
Appendix B, but there is still a lot of text in the document explaining 5G
slices. I'm wary of us "interpreting" 3gpp specifications and technologies.
I think all of that material does not belong in an IETF document (even an
appendix of an informational one). If the 3gpp documents are lacking then
the place to fix them is in that body, but if they are not deficient then we
can just reference them and move on.

[srld] We did mean to interpret 3GPP specifications and technologies - and we agree that we must minimize the 3GPP stickyness. We're making a few changes (see next comments). However, we want to set the context, so the draft references the 3GPP specification, and discusses how 5G slices could be mapped to slices in transport network (TN) domain. Indeed, our discussions with various stakeholders both from IETF and 3GPP/O-RAN showed that there is a lot of confusion on both sides and we want to bring some clarity (e.g. , an IETF guy will say "network slicing is just a VRF + Traffic Engineering + QoS", while a 3GPP guy will say "network slicing does not involve TN"). In practice,  the Transport domain is out of scope for 3GPP (only RAN and CN domains are in 3GPP scope), and the best place to describe transport aspect of overall 5G slicing architecture (RAN + TN + CN) is IETF. The draft doesn't touch RAN or CN slicing.  Additionally, we can use the principle here for non 5G use cases.

[af] Well, I see where you are coming from. Still not sure I like it. You are, of course, right that the TN and its slicing are out of scope of 3GPP, and that's fine. But the interpretation of e2e slicing is theirs, and we should not put words into their mouths. As a compromise I think we might try to shape the text as "the IETF view of 3GPP slicing" so that we cannot be accused of specifying something that belongs with another SDO.

[Med] I personally don't think that we have to interpret the 3GPP specs, but call out the minimum required details to set the context (basically echo the brief Section 4.4.1 of TS28530). We already shortened the text -07/08 and will be adjusting the content as appropriate. I don't think this is a blocking point for adopting the document.

But at the same time, we might try to reduce the material that is explaining the details of 3gpp stuff: I do agree with you that some of this material is missing and needs to be written up somewhere, but I don't agree that it should be in an Internet-Draft (well, you could try the Independent Submissions Stream). I'll look at this again in my re-review and see if any suggestions jump out.
It seems to me that the general mapping discussion is applicable to any IETF
technology (present or future). We already have a draft that we have just
finished polling for adoption (draft-gcdrb-teas-5g-network-slice-application
with some of the same authors) that covers much of the common ground about
the general mapping. It would be good to contain that material in a single
document, and I would suggest working to move the relevant material to
draft-gcdrb-teas-5g-network-slice-application. That is not to detract from
the text in this document that describes the general mapping, just to say we
don't need it in two places.
[srld] Agree, this is applicable to any IETF technology. We should discuss how to address the potential overlap with gcdrb.

[af] It feels to me like, as I said above, that we can move material into gcdrb. An alternative, as I discussed with Julian at IETF 115, is to create a third draft to contain all the common ground and leave srld and gcdrb to handle the technology-specific parts. Would be happy to hear any firm plans.

[Med] We already have many slicing I-Ds out there. I prefer to handle this point as this draft and gcdrb are getting more stable. One side note: the mapping text in the draft is intended to focus on the realization implications of the mappings, not just enumerating them. For example, we elaborated further in the latest version the need to manage slice migration operations to accommodate the demands. These considerations are important from the realization standpoint. Let's see the details of the realization implications that will be documented in that section before deciding to move it to gcdrb or keeping it here. As you can see in https://github.com/boucadair/5g-slice-realization/issues, I added an issue to track this.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

________________________________

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 confidential and privileged 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
________________________________

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]<mailto:[e-mail]>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]<mailto:[e-mail]>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]<mailto:[e-mail]>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.