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

Joel Halpern <jmh@joelhalpern.com> Tue, 15 August 2023 13:11 UTC

Return-Path: <jmh@joelhalpern.com>
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 B5E71C15199B; Tue, 15 Aug 2023 06:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 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, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=joelhalpern.com
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 cwu7w-MjK7SV; Tue, 15 Aug 2023 06:11:34 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2F3C15170B; Tue, 15 Aug 2023 06:11:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4RQBVZ0ncWz6GLN5; Tue, 15 Aug 2023 06:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1692105094; bh=lhzU99C7eat7wRH00m08I1EZtLZail2jcx8k1tKoJpQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CpAQ+tAI0VL7/JKblI0P/HPCqaSEGnQjqrJoUnqyUGjH5AHh2cK7T8RAUbrxSKXZr IGNcbAl/AbpboV9NSxVCYepFH+Dq7ZCPxfHYJQOT0vjjrLH+eTbq2Y2rE6H9ldi5+w TVVSZZmQtap7hBX97iVaZJPG2DCdULSUHFSxqfSM=
X-Quarantine-ID: <YgZgTAlCCnZ9>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.20.19] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4RQBVW5mx4z6GB0j; Tue, 15 Aug 2023 06:11:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------9hcJw0XzHY7tVf7dd0IaXuYv"
Message-ID: <63ca8e5b-10f4-32ed-88b1-4ee6911075e4@joelhalpern.com>
Date: Tue, 15 Aug 2023 09:11:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0
Content-Language: en-US
To: adrian@olddog.co.uk, "'Eric Vyncke (evyncke)'" <evyncke@cisco.com>, '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> <026501d9cf67$90962380$b1c26a80$@olddog.co.uk> <6E6947E2-39B5-4BAD-A9A6-CFB5E5813DDA@cisco.com> <028a01d9cf76$00726d90$015748b0$@olddog.co.uk>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <028a01d9cf76$00726d90$015748b0$@olddog.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ZG7GlbMWwuCeXfzUFP1I9woe8Kc>
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 13:11:38 -0000

 From where I sit, we had a long discussion in the TEAS group about what 
to call the thing we are describing in this draft.  We concluded that 
while "Transport Network Slice" worked for other bodies, it was quite 
confusing for the IETF.  We settled, as I understand it, on IETF Network 
Slice not because we like it but because it was the least bad term we 
could come up with.  I have not seen useful suggestions on how to 
meaningfully improve that. (I do see problems with the term.  But 
lacking the ability to come up with a better name I support sticking 
with the compromise we forged.)

Yours,

Joel

On 8/15/2023 8:42 AM, Adrian Farrel wrote:
>
> Thank you, and I hope you have a great holiday.
>
> I confess that I missed that part of the Comment as it came in the 
> pre-amble and not in the bit marked #COMMENT
>
> I wonder whether my first mail to Paul helps explain why we used the 
> term “IETF network Slice”. That and the text in the first paragraph of 
> the draft that says…
>     Since the term network slice is rather generic, the qualifying term
>    "IETF" is used in this document to limit the scope of network slice
>    to network technologies described and standardized by the IETF.
> I leave it as a wider discussion whether anything the IETF does is 
> “blessed by the IETF community beyond the consensus on” a specific I-D.
> Calling the document"IETF considerations on network slices" would be a 
> fine thing, and we could make that change if it is what people want. 
> But would it address the naming issue within the document? Would it 
> provide clarity about when “network slice” refers to the generic 
> concept of network slicing and when it applies to slicing of 
> IETF-technology networks? And would it provide a term that other 
> documents could use to make exactly that distinction?
> Cheers,
>
> Adrian
>
> *From:*Eric Vyncke (evyncke) <evyncke@cisco.com>
> *Sent:* 15 August 2023 13:21
> *To:* adrian@olddog.co.uk; 'Paul Wouters' <paul.wouters@aiven.io>
> *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
>
> 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 <iesg-bounces@ietf.org> on behalf of Adrian Farrel 
> <adrian@olddog.co.uk>
> *Organisation: *Old Dog Consulting
> *Reply to: *"adrian@olddog.co.uk" <adrian@olddog.co.uk>
> *Date: *Tuesday, 15 August 2023 at 12:59
> *To: *'Paul Wouters' <paul.wouters@aiven.io>
> *Cc: *'The IESG' <iesg@ietf.org>, "teas@ietf.org" <teas@ietf.org>, 
> "draft-ietf-teas-ietf-network-slices@ietf.org" 
> <draft-ietf-teas-ietf-network-slices@ietf.org>
> *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 <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> 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
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas