[Teas] FW: New Version Notification for draft-geng-teas-network-slice-mapping-01.txt

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Fri, 24 April 2020 03:48 UTC

Return-Path: <gengxuesong@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 8376E3A0F47 for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 20:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 LoyDMbipob4N for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 20:48:23 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 729A93A0F45 for <teas@ietf.org>; Thu, 23 Apr 2020 20:48:22 -0700 (PDT)
Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E4D521245672BE66E20E; Fri, 24 Apr 2020 04:48:18 +0100 (IST)
Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Fri, 24 Apr 2020 04:48:18 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 24 Apr 2020 11:48:16 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Fri, 24 Apr 2020 11:48:16 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Zhenghaomian <zhenghaomian@huawei.com>, "eric.gray=40ericsson.com@dmarc.ietf.org" <eric.gray=40ericsson.com@dmarc.ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New Version Notification for draft-geng-teas-network-slice-mapping-01.txt
Thread-Index: AQHWGVcHBp8u/G0i90mk2EgfzN0jiaiHn00A
Date: Fri, 24 Apr 2020 03:48:15 +0000
Message-ID: <9422965a68c14d3d9c564224fe798f86@huawei.com>
References: <158763645127.8043.11271850618135752383@ietfa.amsl.com>
In-Reply-To: <158763645127.8043.11271850618135752383@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.93]
Content-Type: multipart/alternative; boundary="_000_9422965a68c14d3d9c564224fe798f86huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/J9K4SVT8UBBrGXy8N9YxKQEsV0Q>
Subject: [Teas] FW: New Version Notification for draft-geng-teas-network-slice-mapping-01.txt
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, 24 Apr 2020 03:48:26 -0000

Hi Reza, Haomian and Eric,



There are some questions left unsettled in the interim meeting because of the time. Thank you for the comments and please find the response below:



1. Question from Reza: "The draft is talking about the data path and how the traffic relates to transport slices. I don't think TEAS is the best WG for this - it relates more to DMM"

The draft is intended to give the whole picture of network slice mapping procedure, from management plane to control plane and data plane. So the "data path" is only one part of the document. Considering that 5G is the most important scenario of network slice, and currently the work of network slice definition/framework is mainly happening in TEAS, we think it is reasonable to have the network slice mapping topic discussed in TEAS as wel. That said, it may be helpful to let DMM be aware this work.



2. Question from Haomian: "Since there are multiple technologies in the DP there may be multiple mapping solutions so we have to be careful about how we organize this. The example on slide 4 only applies to packet. So more work is needed."

There are a lot of alternative technologies for network slice, especially in lower layer. This document is intended to focus on the procedure of network slice mapping without technical limitation. If more considerations should be included in the case of optical network or other types of transport network, we are happy to add more contents to cover it.



3. Question from Eric: "I think we need to discuss on list. The slice identifier - are you talking about putting an identifier into encapsulation? If so we'd have to define the encapsulation."

Yes, some kind of identifier in the encapsulation may be necessary for e2e network slice mapping (in some cases, the physical interface could be used directly as the distinguisher). But in this document, we just describe the role of the identifier for interworking/mapping in general, and the options in the data plane encapsulation. It is not our purpose to define new encapsulation in this document.



It will be great if more people could review the draft and get involved in this topic. More discussions welcome.



Best Regards

Xuesong



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, April 23, 2020 6:08 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Jaehwan Jin <daenamu1@lguplus.co.kr>; Tomonobu Niwa <to-niwa@kddi.com>; Jaewhan Jin <daenamu1@lguplus.co.kr>; Ran Pang <pangran@chinaunicom.cn>; Liuyan Han <hanliuyan@chinamobile.com>; Chang Liu <liuc131@chinaunicom.cn>; Nikesh Nageshar <nikesh.nageshar@gmail.com>; Dongjie (Jimmy) <jie.dong@huawei.com>
Subject: New Version Notification for draft-geng-teas-network-slice-mapping-01.txt





A new version of I-D, draft-geng-teas-network-slice-mapping-01.txt

has been successfully submitted by Xuesong Geng and posted to the IETF repository.



Name:               draft-geng-teas-network-slice-mapping

Revision:  01

Title:                  5G End-to-end Network Slice Mapping from the view of Transport Network

Document date:       2020-04-23

Group:               Individual Submission

Pages:               17

URL:            https://www.ietf.org/internet-drafts/draft-geng-teas-network-slice-mapping-01.txt

Status:         https://datatracker.ietf.org/doc/draft-geng-teas-network-slice-mapping/

Htmlized:       https://tools.ietf.org/html/draft-geng-teas-network-slice-mapping-01

Htmlized:       https://datatracker.ietf.org/doc/html/draft-geng-teas-network-slice-mapping

Diff:           https://www.ietf.org/rfcdiff?url2=draft-geng-teas-network-slice-mapping-01



Abstract:

   Network Slicing is one of the core featrures in 5G.  End-to-end

   network slice consists of 3 major types of network segments: Access

   Network (AN), Mobile Core Network (CN) and Transport Network (TN).

   This draft describes the procedure of mapping relationship between 5G

   end-to-end network slice and transport network slice defined in IETF.

   This draft also intends to expose some gaps in the existing network

   management plane and data plane to support inter-domain network slice

   mapping.  Further work may require cooperation between IETF and 3GPP

   (or other standard organizations).  The definition of data model,

   signaling protocol extension and new encapsulation are out of the

   scope of this draft.











Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat