Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Adrian Farrel <adrian@olddog.co.uk> Wed, 09 March 2022 17:01 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 63A4E3A0DD1; Wed, 9 Mar 2022 09:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.404
X-Spam-Level:
X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaS1E_1dU6Bw; Wed, 9 Mar 2022 09:01:28 -0800 (PST)
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 8F85D3A0DCD; Wed, 9 Mar 2022 09:01:26 -0800 (PST)
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 229H1MgW027822; Wed, 9 Mar 2022 17:01:22 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE2BE46054; Wed, 9 Mar 2022 17:01:21 +0000 (GMT)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8CE24605D; Wed, 9 Mar 2022 17:01:21 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS; Wed, 9 Mar 2022 17:01:21 +0000 (GMT)
Received: from LAPTOPK7AS653V ([185.69.145.45]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 229H1Klq025828 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Mar 2022 17:01:21 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, 'TEAS WG' <teas@ietf.org>, 'CCAMP' <ccamp@ietf.org>
References: <0eb701d83219$761839e0$6248ada0$@olddog.co.uk> <BY3PR05MB8081B7BA134CC7B0F28C06F8C7089@BY3PR05MB8081.namprd05.prod.outlook.com> <914359236.1014617.1646664962120@mail.yahoo.com> <AM8PR07MB829594F7DCDF0945C9B7F5FCF0089@AM8PR07MB8295.eurprd07.prod.outlook.com> <1488287053.1109535.1646676201734@mail.yahoo.com> <AM8PR07MB82959FEA8DE7D73912DBE506F0099@AM8PR07MB8295.eurprd07.prod.outlook.com> <65997108.168601.1646745010282@mail.yahoo.com> <AS8PR07MB829893432B0756A6FA7485ECF00A9@AS8PR07MB8298.eurprd07.prod.outlook.com>
In-Reply-To: <AS8PR07MB829893432B0756A6FA7485ECF00A9@AS8PR07MB8298.eurprd07.prod.outlook.com>
Date: Wed, 09 Mar 2022 17:01:19 -0000
Organization: Old Dog Consulting
Message-ID: <130901d833d7$4cfdb430$e6f91c90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_130A_01D833D7.4D02BD40"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJoTAP9y1vo1dwGsqmu77xZdE+JkAIu/HZ1AiXmCA8BcQN6NQJCh0dUApI3DaYCaQyOrQKPhJrNqxp6hQA=
Content-Language: en-gb
X-Originating-IP: 185.69.145.45
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26762.001
X-TM-AS-Result: No--24.349-10.0-31-10
X-imss-scan-details: No--24.349-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26762.001
X-TMASE-Result: 10--24.348800-10.000000
X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtuDBXrIsFLH/yBNrXBxNFqQBAvYKX1X5M1Mx eks54Zy0hhVqo3gxO+EX6pCkJZNSOTvH5O5/sxwMNWBYotSYi+QtMYMIvRL1HoOaK7R6v2MMCEF 40kgK1z6McUzJS3sH3QvBTB90+he+yeUl7aCTy8jIgofMgahPrbK6GmKppGdq3pcj1YxM9k1oMd atU9QZZHnJydgcR/Q1zfqlpbtmcWi55hh+svwHUspT3IrSmoVZGicOvTzyq0W/W8Vms3769htgD XGtpBuUqN9SB8J2bqHfqVBdB7I8UQD4keG7QhHm3Hl0OqtoIEooxCDWnyhHjus1VUCnv7V7DFxe fvGMrUpN22CeId2dOSIuZ/6CFMb/4eOkQ7CedputI+DimHQ4gqN7shf385F2Wn//FMObBsIVsU4 zIKmYdRG9Ebi6svChsWltH2OCDLiMUoj7yLheDFHpIy6wt5UwQM1/7PiKoTvhdgvNa1pTTzi1jW 3t8y1vz4wBVW4Yax3vUvp/07kH5uimxgRHwEwmulGrXrvXpSePd1lLIAtF4oPtgEElQrZqtIqkc 3xNwZAIasXPlctLdOY6WKvKEZZTMzbF1gbxlQZmA02nfuZLa696SVn2xrpxvtfXoKp2+slObxcj lhNFNt2fzhfa/JBXZXF1SJUAUOBK/UZnhtRB4mFYhU+i26+rVuTW18rUwU0EXNC0UxRHOZt+1VC W3d+F0iILwdNxhJJs7yIvC2pwGsGU90j67tDodDwP5ItpCOxLVOP6Sq/6G5CJSqC8FQVQPA1qQZ tQo2U5jS4V09dQzmQYj6+BFPEwXxwZhwnDGWqbKItl61J/yZUdXE/WGn0FSlnU38LCY8u7ECHNk fYasys3zPQeiEbe/nnwJ52QYi+pygCGKFPC+BeYl5uS2QAg
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/n4FGxM-76FvqiVANFkpWfUvC5JM>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 09 Mar 2022 17:01:34 -0000

Hi Daniele,

 

I appreciate your call for additional voices.

 

If, as you say, OTN already supports slicing with existing tools, then what is needed is an applicability statement “Addressing Network Slice Service Requests with an OTN” and that will ‘simply’ point up the existing tools and how the YANG modules are mapped. If, during that work, it is found that there are pieces missing (see also draft-ietf-teas-applicability-actn-slicing) then the document will need to contain more work.

 

I suspect that the authors of the ‘OTN slicing’ document believe that they have got ahead of us here by already discovering some missing pieces which they are going on to address. In that case, all that is needed is for them to ‘back-fill’ but describing how it fits together and why those pieces are necessary.

 

In response to Igor’s series of emails:

*	If a 5G RAN is supported over an OTN then the concept of an e2e slice requires that there is something that can be called a transport network slice supported by the OTN.
*	If the IETF Network Slicing Service YANG module is agnostic of the underlay network, then it should be possible for any network technology to have a go at supporting it.
*	If a vendor does not want to implement or an operator does not want to support slicing over an OTN, that is a free choice.
*	If the concept of slicing an OTN is no different from building a VN or a set of LSPs in that network, why is this whole thing a big deal?

 

Cheers,

Adrian

 

From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> 
Sent: 09 March 2022 10:42
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>; jdrake=40juniper.net@dmarc.ietf.org <jdrake@juniper.net>; adrian@olddog.co.uk; 'TEAS WG' <teas@ietf.org>; CCAMP <ccamp@ietf.org>
Subject: RE: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

 

Hi Igor,

 

I believe that OTN already supports network slicing today via existing tools (OTN TE tunnels, OTN ACTN VNs…etc), that why I don’t think we need to label it as OTN slicing (but this is just my personal opinion, CCAMP consensus seems to be different). Hence my answer would be yes to all of your questions.

 

It would be great to hear someone else’s opinion on both lists.

 

Cheers,

Daniele  

 

From: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org> 
Sent: den 8 mars 2022 14:10
To: jdrake=40juniper.net@dmarc.ietf.org <jdrake@juniper.net>; adrian@olddog.co.uk; 'TEAS WG' <teas@ietf.org>; CCAMP <ccamp@ietf.org>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

 

Hi Daniele,

 

As you understand, I suggested to clarify NS framework's position and (ideally) narrow it's scope in two dimensions:

 

1. application-wise (to 5G);

2. network-layer -wise (to IP)

 

Yes, TEAS has clearly rejected my proposal on 1. to be able to not overlook needs of other potential users, such as Enhanced VPNs, on-line gaming, IPTV, etc. I appreciate that. Despite no one so far identified an element in the framework that is not needed for 5G but is needed ,say, for gaming, such things might come up in the future.

 

But I didn't see much rejection or even resistance on 2.  Some (e.g. Gyan) expressed understanding of the concerns and openness to resolve them. Yes, it is unfair to dismiss OTN slicing by limiting framework to 5G, but it is equally unfair to justify it just because the framework intends to be open to other applications, such as gaming.

 

So, I think it is a good time to ask TEAS your questions. My main questions are:

1. Is one or a collection of several OTN TE tunnels is a network slice?

2. Is connection-oriented p2p  connectivity support is sufficient for X to be called network slice?

3. Several days ago Adrian defined NS service (how the NS is seen by a customer)  as a collection of connectivity constructs of various types and complexity levels. Can OTN deliver such a service?

 

 

I appreciate very much the discussions . Thanks a lot to all involved.

 

Cheers,

Igor

 

On Tuesday, March 8, 2022, 04:10:35 AM EST, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org <mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org> > wrote: 

 

 

Hi Igor,

 

(adding CCAMP as this is becoming a cross-wg discussion)

 

I get your point but it doesn’t seem fair to me to limit network slicing to 5G just to deprecate slicing at other layers. If there are other technical reasons to do so (some of which you already brought up) that’s fine, but I don’t think we should limit network slicing to 5G.

Moreover I’ve seen quite a lot of support in TEAS not to limit network slicing to 5G (obviously not my call).

 

Cheers,
Daniele  

 

From: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org <mailto:i_bryskin=40yahoo.com@dmarc.ietf.org> > 
Sent: den 7 mars 2022 19:03
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com <mailto:daniele.ceccarelli@ericsson.com> >; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com <mailto:daniele.ceccarelli@ericsson.com> >; jdrake=40juniper.net@dmarc.ietf.org <mailto:jdrake=40juniper.net@dmarc.ietf.org>  <jdrake@juniper.net <mailto:jdrake@juniper.net> >; adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'TEAS WG' <teas@ietf.org <mailto:teas@ietf.org> >
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

 

Daniele,

 

We all agreed that OTN  does not bring anything new into 5G that, for example,  was not happening  in 4G. OTN slicing work is motivated in some way, at least, because NS framework stipulates that the framework  is not limited to 5G. In fact, it seems to be not limited to anything (application -wise or layering -wise) to a point that it is not really clear what could not be considered a network slice.

 

However,  If the framework was focused on 5G (ideallt going even further and stating  that said 5G style network slicing happenning in IP layer only, which I believe is the case) ,  OTn slicing would have nothing to do with the framework (and the term  slicing) and would have to rely on its own merits ( which,  as you mentioned, you have doubts about yourself) and also  explain why it coincides in time with NS work triggered and inspired entirely by 5G.

 

Cheers,

Igor

Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> 

 

On Mon, Mar 7, 2022 at 12:01 PM, Daniele Ceccarelli

<daniele.ceccarelli=40ericsson.com@dmarc.ietf.org <mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org> > wrote:

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas