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

Italo Busi <Italo.Busi@huawei.com> Fri, 11 March 2022 11:33 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43403A1125; Fri, 11 Mar 2022 03:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 GY_nnNltYQnY; Fri, 11 Mar 2022 03:33:28 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF9A3A1109; Fri, 11 Mar 2022 03:33:27 -0800 (PST)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KFP1b4xKbz6833m; Fri, 11 Mar 2022 19:32:51 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 11 Mar 2022 12:33:24 +0100
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2308.021; Fri, 11 Mar 2022 12:33:24 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: 'Igor Bryskin' <i_bryskin@yahoo.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, 'TEAS WG' <teas@ietf.org>, 'CCAMP' <ccamp@ietf.org>
Thread-Topic: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices
Thread-Index: AQHYNHDlccaNYbsBj0yqJ7A1o2SjHay6DJFg
Date: Fri, 11 Mar 2022 11:33:24 +0000
Message-ID: <bf1827dd1020455db9ecf58be2fc8ae1@huawei.com>
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> <130901d833d7$4cfdb430$e6f91c90$@olddog.co.uk> <556425264.890633.1646873214850@mail.yahoo.com>
In-Reply-To: <556425264.890633.1646873214850@mail.yahoo.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.204.125]
Content-Type: multipart/alternative; boundary="_000_bf1827dd1020455db9ecf58be2fc8ae1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/JrV7SyAy9jEDNMug6pga77wRXbQ>
Subject: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2022 11:33:33 -0000

Hi Igor,

I am not sure I fully understand what do you mean with “top-down” versus “bottom-up”

However, after having read the “creating VNs on the fly”, I have got the feeling that with “bottom-up” you are considering the cases where the connectivity is setup a-priori before receiving any request from the customer while with “top-down” you are considering the cases where the connectivity is setup “on-demand” based on a request received from the consumer

Could you please confirm/correct my understanding?

Thanks, Italo

From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: giovedì 10 marzo 2022 01:47
To: adrian@olddog.co.uk; Adrian Farrel <adrian@olddog.co.uk>; 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>; 'TEAS WG' <teas@ietf.org>; 'CCAMP' <ccamp@ietf.org>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Adrian,


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.
IB:. I think to achieve this it would take basic OTN service delivering non-IP client over p2p links, something OTN has been doing for decades.


  *   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.
IB: This includes not just OTN, of course,  but also flexE. microwave, OCh, physical fiber, lease line, PW and pretty much anything else that can deliver bits from A to B. To paraphrase my favorite Gert's question: what is not a transport slice according to the framework?


  *   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.
IB: of course.


  *   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?
IB: As one Austrian guy said  "sometimes a cigar is just a cigar" and should be called cigar, rather than, say, tobaco slice );
Yes, it is not big deal if we stick to VNs, which normally are bottom up network building constructs. But it could become a rather big deal if one tries to engage OTN directly in the top down netwrk slicing process by, for example, creating VNs on the fly.

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 Wed, Mar 9, 2022 at 12:01 PM, Adrian Farrel
<adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org<mailto:CCAMP@ietf.org>
https://www.ietf.org/mailman/listinfo/ccamp