Re: [Teas] Paul's Discuss on draft-ietf-teas-ietf-network-slices

["Eric Vyncke (evyncke)" <[e-mail]>]

Adrian

Please allow me to top post and be brief (as I am on holidays) about the point that no other AD has raised the same issue as Paul: my comment includes the very same issue (and I hesitated to raise a DISCUSS), see
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/ballot/#draft-ietf-teas-ietf-network-slices_eric-vyncke

Regards

-éric

From: iesg <[e-mail]> on behalf of Adrian Farrel <[e-mail]>
Organisation: Old Dog Consulting
Reply to: "[e-mail]" <[e-mail]>
Date: Tuesday, 15 August 2023 at 12:59
To: 'Paul Wouters' <[e-mail]>
Cc: 'The IESG' <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Paul's Discuss on draft-ietf-teas-ietf-network-slices

Hi Paul,

Thanks for taking the time, and for keeping TEAS and the authors in the loop.

In line…

From: Paul Wouters <[e-mail]>
Sent: 15 August 2023 02:03
To: [e-mail]
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Paul's Discuss on draft-ietf-teas-ietf-network-slices

On Thu, Aug 10, 2023 at 5:18 PM Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:
Hi Paul,

I'm sorry that I seem to have missed your Discuss until too late for the
telechat. It probably wasn't intended for comments by tte authors, but I
think I can provide you with some background.

It was intended for the authors as well! A number of ADs chatted and got a bit worried about the use of the prefix "IETF"
in a term within the IETF. Since a few of us had concerns, i raised my COMMENT to a DISCUSS but unfortunately John,
the responsible AD couldn't make the telechat.

To summarize our thoughts, imagine someone comes and starts a draft using the term "IETF Email Transport". It would
suggest that this is a new IETF wide protocol, that would even obsolete SMTP, just by implication of the name.

Well, thankfully, no one has done that. But, I suppose (and this is definitely a red herring) if the IETF chose to publish such a document after due consideration, then they would mean what they said.

What is more:

  *   There is no prior work on network slicing in the IETF
  *   This document isn’t a protocol spec

The context here is that network slicing is a term widely used by the 3GPP
in the context of 5G. Part of that scenery is a component that the 3GPP
calls the Transport Network Slice.

I understand.

The motivation for this work is to describe slicing the transport network.
But (of course?) we at the IETF are:
- limited to discussing IETF technologies
- open to wider uses than just 5G connectivity
- not limited to being a "transport network"

So we needed a term. Initially, we simply used "network slice" because,
well, duh, we are the IETF so obviously we are slicing IETF technology
networks. But it rapidly became apparent that there was too much confusion
with 3GPP uses of the term. So we carefully defined "IETF network slice" in
the document and use the term consistently.

I understand that using "network slice" would be confusing.

OK. So we are looking for a term that means “network slice as applied within the IETF using IETF technology”

The choice of "IETF network slice" is just suboptimal for the above mentioned reasons.

Well, there may be some good reasons lurking here, but I don’t think you’ve voiced them. You gave an example of what might be a concern if a different document was presented for publication. Can you say more clearly what the concern is in this case?


It was also my understanding from listening
to other ADs that within the IETF, "network slicing" wasn't something everyone wanted, and that
makes the term even worse - it is as if the whole IETF things network slices are therefor the defacto
new IETF wide standard - despite there being people who clearly do not think so.

OK. This is alarming!
Why has no one mentioned this concern during the whole process? I don’t even see the concern in anyone’s Comments. Would it be possible for those ADs to speak up so we know what the issue is?

But, look, it is not like this document is forcing people to do network slicing. It is saying that if you decide to do network slicing, this is how it hangs together.

As to, there being people who clearly do not think this is an IETF wide standard, should we involve them in the discussion? We went through the working group process, we had Directorate reviews, we had the IETF last call process, and we have the opportunity for ADs to speak up, yet no one has said that they have concerns up until your reported speech. It is absolutely not clear *to*me* that anyone does not think so, so you need to substantiate your “clearly” either by citing the people, or if they are concerned to remain anonymous, by articulating their worries for them.)

As to what other documents do. Hmmm, I don't know that it is fair to hold
this document to the standard of other documents that are less advanced
through the system. But I will say (as editor) it got frightfully painful
typing "IETF network slice" every time especially when text was supplied to
me using just "network slice" or even "slice". I could quite understand why
a document (remaining internally consistent) would say, "We are going to use
the term foo in order to mean IETF network slice."

Does this help?

Having an understandable reason does not really help address the concern unfortunately.

So, trying to avoid the impasse, knowing that there exists a concern does not help address the concern until we share an understanding of what that concern is. Can we dig a little more into exactly what the concern is?

I don't have any good answers here. I'm sure everyone would hate new terms we could come up
with like "network sliver", "network waver", "network shaving", "network portion", "network allotment",
"network chop", "network allowance", "internet network slice", "IP network slice", "upstream network slice", etc.

Yes. Changing the part of the term that is ‘slice’ would be a mistake because this *is* a network slice. And network slices are already well defined in other SDOs. We are inheriting the concept.
The qualification is that this document talks about a network slice that uses an IETF forwarding plane or (corner cases) a non-IETF forwarding plane with an IETF control plane.

Honestly, if people wanted to distinguish better from the 3gpp network slice, they shouldn't have started out
with "network slice" and come to "IETF network slice" either, since I'm pretty sure "IETF network slice" AND the
3gpp "Transport Network Slice" will all commonly get called "network slice". The question is, did you already dug too
deep to stop?

I am also sure that in time, people will relax to use “network slice” in all cases and work out from the context what is meant. But we are not there today. It would be wrong to fall back to “network slice” at this point.

So we would be looking for a new term, “foo network slice.”

It would certainly be inconvenient to make this change: there are lots of I-Ds out there hanging on the term “IETF network slice”. But it is only text, and text can be changed.

As I told John, if we cannot find a reasonable better name/solution in the next few days (eg within this email thread)
then I will drop my DISCUSS. It would be good to hear from the other ADs that were part of this discussion in slack
and during the telechat as I raised the DISCUSS to capture some other AD worries from before the telechat as well.

Thanks for taking that stance. Discussion is what a Discuss should be about.

And, yes, it would be nice to hear from other ADs what their concerns are. Although you hold the Discuss, it is clear you are doing that to facilitate the wider discussion, so it would be good to bring them in.

But as I said, I'm sure none of my proposals above would be liked by anyone.

For my part, I also think that other solutions that have been whizzing around are not close to being right. The best I have managed to come up with so far is “Generalized Network Slicing”.

Cheers,
Adrian