IETF Logo Mail Archive

Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

"qiangli (D)" <qiangli3@huawei.com> Thu, 21 December 2017 09:02 UTC

Return-Path: <qiangli3@huawei.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA61273E2 for <netslices@ietfa.amsl.com>; Thu, 21 Dec 2017 01:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level:
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Pvm1NXm3fJ9Q for <netslices@ietfa.amsl.com>; Thu, 21 Dec 2017 01:02:24 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 426201200FC for <NetSlices@ietf.org>; Thu, 21 Dec 2017 01:02:24 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 97F04CF5ACA8E for <NetSlices@ietf.org>; Thu, 21 Dec 2017 09:02:17 +0000 (GMT)
Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 21 Dec 2017 09:02:18 +0000
Received: from DGGEMI509-MBS.china.huawei.com ([169.254.2.152]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 17:02:13 +0800
From: "qiangli (D)" <qiangli3@huawei.com>
To: "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Thread-Topic: [Netslices] Open Issue I: SouthBound/Mapping Interface
Thread-Index: AQHTeZ9kKiooTEHoikOC9L32YMqm1aNNBIwA
Date: Thu, 21 Dec 2017 09:02:12 +0000
Message-ID: <06C389826B926F48A557D5DB5A54C4ED2A5DFC7D@dggemi509-mbs.china.huawei.com>
References: <06C389826B926F48A557D5DB5A54C4ED2A5DEDA1@dggemi509-mbs.china.huawei.com> <VI1PR07MB084846CB3A16AE9691C1C3E09B0C0@VI1PR07MB0848.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB084846CB3A16AE9691C1C3E09B0C0@VI1PR07MB0848.eurprd07.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.163.138]
Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED2A5DFC7Ddggemi509mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/jfEVrKAjAQv-rsVR_DQQyprPO_4>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Dec 2017 09:02:27 -0000

Hi Hannu and  others,


Thank you for your comments. As you and Diego mentioned, the standardization of southbound interface is a sensitive matter, we'd better avoid infringing other WGs/RGs.

To solve this issue, maybe we should figure out "Is it possible to have a uniform/standard mapping interface to adapt to a variety of implementation technologies?" first. If Pedro is right, such uniform interface does exist, then it's not a big deal to standardize it IMHO. Otherwise, I think we may need to consider which option listed below will be better:
Option 1: No standardization work on southbound interface, at least before IETF 101
Option 2: Separately analyze all specific technologies as you have done -- ACTN [un-checked], NFV [checked], then how about SFC, VPN...?
Option 3: Classify technologies (e.g., providing connectivity, provide VNF....) , then discuss for each classification.

I personally prefer 1 or 3, what's your opinion?

Best regards,

Cristina QIANG

From: Flinck, Hannu (Nokia - FI/Espoo) [mailto:hannu.flinck@nokia-bell-labs.com]
Sent: Wednesday, December 20, 2017 10:33 PM
To: qiangli (D) <qiangli3@huawei.com>; NetSlices@ietf.org
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hello Cristina and others,

I would suggest that  COMS/ATCN interface mapping would be developed in the TEAS WG since that is an IETF WG, is also alluding to slicing topics, has related specifications and the expertise of the transport networks.

However, NFVO related work is currently within NVFRG where the slicing work is a minor subset of much larger territory of what the RG is discussing.  Therefore, it would be better to do such focused work in COMS when and if it becomes an IETF WG.


Best regards
Hannu

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Wednesday, December 13, 2017 10:41 AM
To: NetSlices@ietf.org<mailto:NetSlices@ietf.org>
Subject: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi All,

This email is want to collect your opinion on the following issue:

Do we need to standardize the Southbound/Mapping interface of a network slice aware system in COMS? Or do you think this work should be carried out in existing WGs/RGs? (e.g., mapping interface between COMS and ACTN, mapping interface between COMS and NFVO)

Best regards,

Cristina QIANG

v2.23.0 | Report a Bug | By Email