Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 25 March 2022 13:20 UTC

Return-Path: <jie.dong@huawei.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 E102D3A1222 for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 06:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=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 YQ-XmxJap2fI for <teas@ietfa.amsl.com>; Fri, 25 Mar 2022 06:19:57 -0700 (PDT)
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 96B703A120F for <teas@ietf.org>; Fri, 25 Mar 2022 06:19:57 -0700 (PDT)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KQ2gy3YwVz67Zs0 for <teas@ietf.org>; Fri, 25 Mar 2022 21:17:34 +0800 (CST)
Received: from kwepemi100017.china.huawei.com (7.221.188.163) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 25 Mar 2022 14:19:54 +0100
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi100017.china.huawei.com (7.221.188.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 25 Mar 2022 21:19:52 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2308.021; Fri, 25 Mar 2022 21:19:52 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Slicing Framework Open issue #1 : Service != Realization
Thread-Index: AdhAJerwmP8JgaoPSZm5TdQgGwLtRQAI7seA
Date: Fri, 25 Mar 2022 13:19:52 +0000
Message-ID: <8b6b54199afe42998ff82f4d9dac56ba@huawei.com>
References: <042601d84029$1de567c0$59b03740$@olddog.co.uk>
In-Reply-To: <042601d84029$1de567c0$59b03740$@olddog.co.uk>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.160.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/4TmrDT1qUANrKvtxzzp2WCTARDw>
Subject: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization
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: Fri, 25 Mar 2022 13:20:03 -0000

Hi Adrian, 

Thanks for raising this issue to the list. 

The description about the network slice service and the network slice realization in the last paragraph looks good to me, except the typos pointed out by Med. 

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Friday, March 25, 2022 5:17 PM
> To: teas@ietf.org
> Subject: [Teas] Slicing Framework Open issue #1 : Service != Realization
> 
> Hi,
> 
> First in a series of emails to resolve the open issues mentioned during the TEAS
> meeting.
> 
> We have, for the longest time, suffered from a blurring between the service
> provided to the customer, and how that service is engineered in the network.
> This leads us to talk about VPNs in a way where sometimes a VPN is what the
> customer gets and sometimes it is what the operator engineers. A good example
> is the term "MPLS VPN" as though the customer cares whether the VPN is
> provided using MPLS technology.
> 
> We have, to some extent, clarifies this with recent YANG "Customer Service
> Models" that describe the service offered to the customer, but do not constrain
> the provider's choice of implementation technology or options.
> 
> As the discussion of IETF Network Slices continues, I have repeatedly seen some
> blurring between the topics of the "IETF Network Slice Service" and the "IETF
> Network Slice." It seems to me that this mixing of concepts will continue as future
> readers pick up the document.
> 
> Although I have tried to use the two terms clearly and distinctly, the document is
> missing a clear statement to disambiguate the two.
> 
> Section 3 provides the definitions of the two terms at some length using
> subsections. The clarification would get lost if it was placed at the bottom of the
> section after the subsections, so I propose to include some text near the top of
> section as follows.
> 
> OLD
>    IETF Network Slices are created to meet specific requirements,
>    typically expressed as bandwidth, latency, latency variation, and
>    other desired or required characteristics.  Creation of an IETF
>    Network Slice is initiated by a management system or other
>    application used to specify network-related conditions for particular
>    traffic flows in response to an actual or logical IETF Network Slice
>    service request.
> 
>    Once created, these slices can be monitored, modified, deleted, and
>    otherwise managed.
> 
>    Applications and components will be able to use these IETF Network
>    Slices to move packets between the specified end-points of the
>    service in accordance with specified characteristics.
> NEW
>    IETF Network Slices are created to meet specific requirements,
>    typically expressed as bandwidth, latency, latency variation, and
>    other desired or required characteristics.  Creation of an IETF
>    Network Slice is initiated by a management system or other
>    application used to specify network-related conditions for particular
>    traffic flows in response to an actual or logical IETF Network Slice
>    service request.
> 
>    Once created, these slices can be monitored, modified, deleted, and
>    otherwise managed.
> 
>    Applications and components will be able to use these IETF Network
>    Slices to move packets between the specified end-points of the
>    service in accordance with specified characteristics.
> 
>    A clear distinction should be made between the "IETF Network
>    Slice service" which is the function delivered to the customer
>    (see Section 3.2) and which is agnostic to the technologies and
>    Mechanisms used by the service provider, and the "IETF Network
>    Slice" which is the realization of the service in the provider's
>    network achieved by partitioning network resources and by
>    applying certain tools and techniques within the network (see
>    Section 3.1).
> END
> 
> Any objections?
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas