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

Adrian Farrel <adrian@olddog.co.uk> Tue, 15 August 2023 10:59 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4E5C151535; Tue, 15 Aug 2023 03:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZflfBO2ABbMd; Tue, 15 Aug 2023 03:59:37 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5C2C14CF18; Tue, 15 Aug 2023 03:59:33 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 37FAxUKt004920; Tue, 15 Aug 2023 11:59:30 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AA1924604A; Tue, 15 Aug 2023 11:59:30 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8999646043; Tue, 15 Aug 2023 11:59:30 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 15 Aug 2023 11:59:30 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 37FAxTwD010905 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Aug 2023 11:59:29 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Paul Wouters' <paul.wouters@aiven.io>
Cc: 'The IESG' <iesg@ietf.org>, teas@ietf.org, draft-ietf-teas-ietf-network-slices@ietf.org
References: <0e9701d9cbd0$3a76ca80$af645f80$@olddog.co.uk> <CAGL5yWatjnzmpb5vFLkaMc1PXnwdEESVApYjJqByQmRfHdNMYA@mail.gmail.com>
In-Reply-To: <CAGL5yWatjnzmpb5vFLkaMc1PXnwdEESVApYjJqByQmRfHdNMYA@mail.gmail.com>
Date: Tue, 15 Aug 2023 11:59:29 +0100
Organization: Old Dog Consulting
Message-ID: <026501d9cf67$90962380$b1c26a80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0266_01D9CF6F.F25BC400"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGerMJoFmcZD9TV7HLq2HEkmvtgdwHOPn5RsFL70jA=
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=mfCbM0Tg/uf8JPKQQfYWo Se3YiVTDPaVp0iBQBJZZA8=; b=OhPlab9kRye7pIAvJZ050H6B4BtA4SB8n5SqM 3HjlBwMe25V68xRV8JHarr4Sb9IGietfMemsvlN6Yy01tHcFQ8w55pDvAG2HyX6M GMqZRhjfmJWozTe1AAV1fWNU7mbQVGcVFf9nw4uGVkYrr4R09KLVxKKlnyk67x1i g2IJ4+esX3dT7+PGFgecGqunI8PlUt8b1qJLBbXZr5/6lig/NbJYj6KWhV0G90Vl 2vZV+sNgPH5hNQZMWxObGSML6xl5gsoIB9n+F6Q+/+xkgYr7gvIwu/7wjnbMBqlD B08kCaRpJmvp4qrgXaA0ORWIw+2iNFCfPTbpPZMf4ozRHZoDQ==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27814.003
X-TM-AS-Result: No--24.620-10.0-31-10
X-imss-scan-details: No--24.620-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27814.003
X-TMASE-Result: 10--24.620500-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzmicbHRUsaV3FPUrVDm6jtkYC3rjkUXRIUKB9yn24IXM79 PlJmAmXDO5OUpE6rya4NSUo4FZujSV18AE3kscNTiH95tLFH8edIBt8FVKrwCZtIK+20gQ4229I GmYEBMmoi7UzjnfOKr/S8hmHHS12L0hQoRxePIEEAPmNKDWsW0FHB9PagRph0tnbn9SmDi/xY8H mAnvYQ1gZ10VIAHT7i7g6B4WJLTOVmhFh97sSriZqnULil5JqLRealVAhocE+ynk7TnYzMuuWhN KYuM7eNxat+YcaSFC8TbKpiis8rIDLX4GFiNk2R3nHtGkYl/Vpb0MaM9Tusz1c/CedjlcvkhJYd ickmV30vlpQrzljwQjfjUAyFxnM/tpor8DSuIkAzs0egrNCwVzVEnbrqmBw757a1sPm6CSGyuhp iqaRnagL1XzD5oNWkYwRlvQwxSO0zB98Fjsee58TOJ9zxd68xX93p52Kh3th8SACW1urtI8VjLX tavb0rivqzYXucmw1p/iRbJFVGtwKQjoxqav1/lTsGW3DmpUvbzi74MW59YG5LwCaDkPfZoT+7K 9IgTZdVfwOZPHrVF/4QBm60RjvLX+fGOprXA73i3aa5wOREEQstnVpBhbgse3wXTvBMUi5DSRdv C3OxLkyd3KSDUKmxksXV75AyT55PwZftMdoCRtEJQUcCarUjBMdp5178zSPVjNsehGf0vUSwz7i ctu7pV8EtIjTP0MVb4YM4eqVYgRohTDRS/HTes/Hes76OTZCUctRw0zzl2hUHiwnRYYCa/Fm3zi qFqDqAwG2maXQMIEmlX2scVfePszCdMqCRuw5ANB89sV0bJ30tCKdnhB58r10pknZXGJqy5/tFZ u9S3M+9+OQ9U/5fbdTuPa9VRGsgbhiVsIMQKxZ5+8y352uC
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1q53l81XPtfzilCTc4KojMA0g4g>
Subject: Re: [Teas] Paul's Discuss on draft-ietf-teas-ietf-network-slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2023 10:59:41 -0000

Hi Paul,

 

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

 

In line…

 

From: Paul Wouters <paul.wouters@aiven.io> 
Sent: 15 August 2023 02:03
To: adrian@olddog.co.uk
Cc: The IESG <iesg@ietf.org>; teas@ietf.org; draft-ietf-teas-ietf-network-slices@ietf.org
Subject: Re: Paul's Discuss on draft-ietf-teas-ietf-network-slices

 

On Thu, Aug 10, 2023 at 5:18 PM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > 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