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

Adrian Farrel <adrian@olddog.co.uk> Tue, 15 August 2023 12:43 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 F25A8C15155B; Tue, 15 Aug 2023 05:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.804
X-Spam-Level:
X-Spam-Status: No, score=-2.804 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 vmDSgqsESPyM; Tue, 15 Aug 2023 05:43:21 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 0702FC14CE45; Tue, 15 Aug 2023 05:42:58 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 37FCgpGS018900; Tue, 15 Aug 2023 13:42:51 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4EEC946048; Tue, 15 Aug 2023 13:42:51 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E9D74604C; Tue, 15 Aug 2023 13:42:51 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 15 Aug 2023 13:42:51 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 37FCgnpX009885 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Aug 2023 13:42:49 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'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>
In-Reply-To: <6E6947E2-39B5-4BAD-A9A6-CFB5E5813DDA@cisco.com>
Date: Tue, 15 Aug 2023 13:42:49 +0100
Organization: Old Dog Consulting
Message-ID: <028a01d9cf76$00726d90$015748b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01D9CF7E.6238AA50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGerMJoFmcZD9TV7HLq2HEkmvtgdwHOPn5RArOaYN0B/MI6N7Atm6Ig
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=LTt1P9+uW0e3CRItO+hAw iPFfethJaDAh4rRiReXeag=; b=1TvJCgrfoETvCzEvC5noFJWt7hGG+Y4Zir4Vm U3rFyevknUdfM+UEtmNnN4Dsefq5JacfcwcVAfX4eXBv7C3WXrFRDgNLY4w4tkCf Yk5H3ILYgDLFLyA3HeIW2KJwbD82prSNppjdWeYhsWIQpp5QCit2Ek+k3YbrAAUA PdKHzo3R65RKKrrq5C+j0F2DN4rwu8H5xAdgusZhD23vy1ND52ZIxpz8eSb6/Tmj 8m2BF2bNvNS0I0ZS9ETLjNWqsafRZpG92nyYbq2r42TPmf+aU+11djpvhsP2OAfB gq+lWqZCNDzyUsQjuxoZCW9AP5a2roggF5A0YFP9JZdFYsHkA==
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--34.509-10.0-31-10
X-imss-scan-details: No--34.509-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27814.003
X-TMASE-Result: 10--34.508700-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/micbHRUsaV3FPUrVDm6jtpR+m8tBi6ZKCCtUaLksF8Fem QtpKzZIzM90yViNIbDVgrVxsOgQvhckBpNm5KKNwF3wQ0cu1bTMBmf/gD11vZEBvNrVUgchlWg8 AHk5NUlam6QekOVgqa9ez40ONsDlRx3+7pm7e7TE8+i/lP6Xo8T7BhvpELLyo/gMNehoKqTt1hP /soOwJDlSCPP/i2yiQpNFWE3n1fVDvnOSC+jk4DjZoNXJMbH+nHd2D6d5rhKrkMnUVL5d0E/EqC MNk4PLq2ewWYx0R5bWNNS0jJidRka4PSwdLs3CErmLeMrcoM6j4h+uI7dxXxGtaNN5IoqQRj3dZ SyALReL0jzXpFfd/di+pDoI1xD+uVQ6uC0unrTzfqVBdB7I8UU0s9CXRACW0JwONCfZCxNovu1l VcZKEoAZ10VIAHT7i7g6B4WJLTOVmhFh97sSriZqnULil5JqLRealVAhocE+ynk7TnYzMuuWhNK YuM7eNxat+YcaSFC9KSVk1A+fWwgqU4tmmg3HI/sUSFaCjTLzJ5SXtoJPLyJF2kRRKjUQ9wNhVN LRAQcDJl5bCFuzuyZFbAdImsdznbC1OSKQEkYhFl9A34VWpsJzipwKe4Je1mbc4hVJ/g/kZ9yTN rM5a+zHVWI3tJOaR5zyDwiE+qjSwcHwzEtk5yVgXNZMUqXg/V2y0V2O63Z7KxHkj9AJeqm8Hfko h8tomfH5sww+32JPBlU8KFeeE9TYAr1Vu5gNP93bduyx/IZwZQ1MqX/9hyZjXBsYVtQn052kNUg ZDm7Ss4vX/mn+LVjipYcWAUIGDmt1ST7v5bbJANB89sV0bJ30tCKdnhB58r10pknZXGJqNwWY+K mOUG4GKRgK4Akny33fj+sMArfNRzX47Vf0DMQ==
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/S9GVic3tWDsWYkxMvtCQnpm2yco>
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 12:43:25 -0000

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 <mailto:iesg-bounces@ietf.org> > on behalf of Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Organisation: Old Dog Consulting
Reply to: "adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> " <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Date: Tuesday, 15 August 2023 at 12:59
To: 'Paul Wouters' <paul.wouters@aiven.io <mailto:paul.wouters@aiven.io> >
Cc: 'The IESG' <iesg@ietf.org <mailto:iesg@ietf.org> >, "teas@ietf.org <mailto:teas@ietf.org> " <teas@ietf.org <mailto:teas@ietf.org> >, "draft-ietf-teas-ietf-network-slices@ietf.org <mailto:draft-ietf-teas-ietf-network-slices@ietf.org> " <draft-ietf-teas-ietf-network-slices@ietf.org <mailto: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 <mailto:paul.wouters@aiven.io> > 
Sent: 15 August 2023 02:03
To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> 
Cc: The IESG <iesg@ietf.org <mailto:iesg@ietf.org> >; teas@ietf.org <mailto:teas@ietf.org> ; draft-ietf-teas-ietf-network-slices@ietf.org <mailto: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