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

[[e-mail]]

Hi Adrian,

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

Cheers,
Med

De : Teas <[e-mail]> De la part de Adrian Farrel
Envoyé : mercredi 19 avril 2023 23:32
À : 'Krzysztof Szarkowicz' <[e-mail]>
Cc : 'Oscar González de Dios' <[e-mail]>; 'TEAS WG' <[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.