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

Liang GENG <liang.geng@hotmail.com> Tue, 09 January 2018 15:31 UTC

Return-Path: <liang.geng@hotmail.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 B4D3212D86A for <netslices@ietfa.amsl.com>; Tue, 9 Jan 2018 07:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level:
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 yLItzsyDrMCt for <netslices@ietfa.amsl.com>; Tue, 9 Jan 2018 07:31:16 -0800 (PST)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255086.outbound.protection.outlook.com [40.92.255.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBF71205F0 for <NetSlices@ietf.org>; Tue, 9 Jan 2018 07:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4y8ESQMLiRFEAMf5AP4ZzYxXN80DTvHiyCBRVJstyiw=; b=h2cuIkurzCkuJDdXf6ChpcIw4vpDPyMA8efspdtj9lqomh5SEPZJ1tyd2eYq21BJzy64Cz9P/3JDjteWkvLhRHsKuUw3G8+oL7P2EmArsjbnRN2XXk+NadoHqtQUwqr3qEyj8VY7jHzfq6h/PNMtKfL07LtvHjjr3a/NfR+LM9Z+2k2UyNc4/6z8jjmC4urqMWjJqIt301E50ytHtiYlLEzDavRs5YNhk0S1q6qbxlo4jiXJlCKmG1kmnWyvjhMeJ2EOJcKMyf+P4f5BhmTI8zv5cj2If2za+YXWp3WmGvp/S4apqkHvMifCDRK/yulFKZuK89OgDXrCRT+MRh76WA==
Received: from SG2APC01FT042.eop-APC01.prod.protection.outlook.com (10.152.250.58) by SG2APC01HT025.eop-APC01.prod.protection.outlook.com (10.152.251.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Tue, 9 Jan 2018 15:31:10 +0000
Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com (10.152.250.55) by SG2APC01FT042.mail.protection.outlook.com (10.152.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.345.12 via Frontend Transport; Tue, 9 Jan 2018 15:31:10 +0000
Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::ac8f:ab59:fccb:6f1b]) by PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::ac8f:ab59:fccb:6f1b%14]) with mapi id 15.20.0386.009; Tue, 9 Jan 2018 15:31:10 +0000
From: Liang GENG <liang.geng@hotmail.com>
To: "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>, "qiangli (D)" <qiangli3@huawei.com>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Thread-Topic: [Netslices] Open Issue I: SouthBound/Mapping Interface
Thread-Index: AdNz7BaJGrRkEFbTREOfWwbxCLzW+gFshmWwACcM2QAACbDbgAAxOAMAAAGJO2AAiaH5QwBxsKIQApAzmLo=
Date: Tue, 09 Jan 2018 15:31:09 +0000
Message-ID: <PS1PR0601MB1483093FFEB2A067E35AEC8987100@PS1PR0601MB1483.apcprd06.prod.outlook.com>
References: <06C389826B926F48A557D5DB5A54C4ED2A5DEDA1@dggemi509-mbs.china.huawei.com> <VI1PR07MB084846CB3A16AE9691C1C3E09B0C0@VI1PR07MB0848.eurprd07.prod.outlook.com> <06C389826B926F48A557D5DB5A54C4ED2A5DFC7D@dggemi509-mbs.china.huawei.com> <HE1PR07MB0842A5BCA7AD2B3BF7BA739E9B0D0@HE1PR07MB0842.eurprd07.prod.outlook.com> <06C389826B926F48A557D5DB5A54C4ED2A5E048B@dggemi509-mbs.china.huawei.com>, <HE1PR07MB0842290EB5B00C953C7267349B020@HE1PR07MB0842.eurprd07.prod.outlook.com> <PS1PR0601MB148304AE32CC11A58A87F8DE87010@PS1PR0601MB1483.apcprd06.prod.outlook.com>, <HE1PR07MB08427953B5DF4FD5C990A04A9B070@HE1PR07MB0842.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB08427953B5DF4FD5C990A04A9B070@HE1PR07MB0842.eurprd07.prod.outlook.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:2140C9E3277EFC0B5FE88BB490B1F8FCEA12B8CF3372428F8771D7E82BE1B18F; UpperCasedChecksum:8C6060DA683BA3B48C6ED71785121ED03DE9E66024FEA719EB714A98A033B904; SizeAsReceived:7810; Count:45
x-tmn: [BVbeiW984CdX1RkEkGgy8goUilYYzchF]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT025; 6:6oneybgs+jYFed/U+Kxu6wmP/LD8L+Jaoh9wd/6ZXhgxHzbKEOSwfwn7LNf+p7tezgn/2fX0ZQ7lVhJvpNEc3A16QBvysjkpziAqqj0qP8493n1efWI5iczLbsfkSYc7WWYAQXSxFi+sOcoXbc+ryuYf7Ln8DrIcYrQxqo57zVnmMkA5gP5o7QqQcubgMh+NqBJrMZd1TzCKsMkFeY3fVgxQXSUc1RVHcwdq6oo0mIKb1XSnXHEgARKq8VlW6kFq0XH6KiDGb0xdFu1j+LSoTjOc3z+c+vJOMS4mXY+6YvJ+qA3tpYMeTubjt899TkfDqwDVQZ0OpiylzHfam+WbSsHgc/g/E5a3PedzWRoslrY=; 5:61QqPq9ACTyXtVAyMHu7Ku5XZDQDD9gcfVnw7GDOcHjnSAPVStNQIZoXKTxsQSE7km0rOlnQRrQwztORukZMAIJOaFAAt6MgUrZUS85+IAcW+fmDz6N78iGIaCkrchFkM6R1CwIQshYbJsEDbu1tTPTWZj+M6hb4yrk5OjTcjdQ=; 24:ZFn7bwKHRvebOl14VAOYlr351bKPjndaA1TXtpEDxXZYdmXktyZ3Sb3DowMEOshyAJt4uf2yoxKUmOwGWSFX8rDP2jswLET4kpV6BGmUcZY=; 7:uRlMhQs0SYaVce/r1SV7LcDiFObDkoZeqTcBvt+NbjjtX9hgpCnAZGtngkFqXdCFtwAkz4J8SoOqJGapOev+CtZ1MQ0O7RZBqobp8A1cpDl7DNKR1CN/6FIMnXeYbi3xhizU2m7cYwaRvV0uLgkNy1CB769IX/Pv60fsC907CDJ7PwrPy09hQ702NVD0IRKDdEjrNGyvFwvFC5KZyWE6vURilXdqQjv+T7bOvRcPzphbN+a/FZ6AlLbInSz6sLjn
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SG2APC01HT025;
x-ms-traffictypediagnostic: SG2APC01HT025:
x-ms-office365-filtering-correlation-id: fecf692b-ef9f-461d-7e5e-08d55776026f
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT025; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SG2APC01HT025;
x-forefront-prvs: 0547116B72
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT025; H:PS1PR0601MB1483.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_PS1PR0601MB1483093FFEB2A067E35AEC8987100PS1PR0601MB1483_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fecf692b-ef9f-461d-7e5e-08d55776026f
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 15:31:09.4380 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT025
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/gQ3bFV_U-d2QzP48oGN8j_vFteY>
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: Tue, 09 Jan 2018 15:31:21 -0000

Hi Hannu


Thanks for your email.


Please find my comments in line.



>HFl: Monitoring and ensuring the SLA end to end of a slice is an important aspect. Note that when the slice is crossing a (technology) domain, we might need to stich the end to end slice OAM from different pieces of segments. Can we have such a “technology agnostic” OAM? Is that feasible? Or should we do something what SFC WG is doing?


>>[LG] I was discussing this with Cristina the other day. What you said about e2e OAM is an extremely important concern for COMS. In a cross-technology scenarios,  on one hand, COMS may send OAM requests to different domain controllers. It is distributing and collecting OAM requests and responses rather than directly executing OAM functions. At this level, I think the OAM model can be technology agnostic because the OAM parameters COMS would like to collect from different domains need to be aligned. However, the actual OAM functions each domain is based on may be different. On the other hand, COMS may need to execute OAM functions directly if there are generic resource elements that are directly under COMS control. Also I am not very familiar with SFC OAM, could you share more informaiton on



I personally think COMS itself should not include the southbound mapping because there was an assumption that anything below COMS is not aware of "slice" (although in management perspective, COMS may see some of them "Subnets"). Existing WG/technologies may refer to/map with COMS models if they would like to be part of the managed network slice instance. Eventually, it may be us - the people from COMS community, who will be actively progressing these southbound interfaces in various IETF WGs.



>HFl: What you say above would be an ideal situation, but I am afraid that in practice the situation is such that also other WGs are working on slicing. See https://www.ietf.org/id/draft-ietf-teas-actn-framework-11.txt


>>[LG] Yes, you are absolutely correct! What I mean is that whether or not a specific technology domain is working on slice, COMS does not need to know. The SBI of COMS delivers configuration models - the domain control apply this configuration based on their own technology choices.



In principle, COMS itself provides the capability of inter-operation between different domains. This capability is enabled by common information model/service model and related OAM models/mechanisms. The southbound mapping is implementation-specific in the view of COMS and may be more suitable to be carried out in various technology-specific WGs. A good example would be that for a link from node A to node B requiring 100Mbit/s peak bandwidth and maximum of 5ms latency, one can map this using various type of SD-WAN(VPN) controllers with different underlay data planes. COMS sees them as the same.



>HFl:  ok.



And also in terms of the working load of WG, the southbound mapping could be endless, it may not be feasible for COMS WG to deliver a sensible charter on this matter concerning southbound interfaces.



>HFl: right.



Meanwhile, I think it would be good if we can first of all deliver a/several information models so that the southbound technology domain can chose the materials they need to map with. We can do this by categorizing the resources as Cristina suggested as "classifications" - which may make the model more systematic. However, it is not necessary to limit the southbound to one category - it should be able to pick parameters/components whatever are needed.



>HFl: this a bit unclear to me. Maybe you can elaborate your thoughts further.

>>[LG] Here I mean if the information model which defines the template of parameters of various type of resource tends to be to complex, we could split it into several information models based on the categories of resources. A specific technology domain may define their own network configuration model (specific SBI of COMS) based on those information models. Of course, the information model could also be just one as we did now. The other thing I would like to point out for discussion is that we may need to define a generic SBI or network configuration model in cases where resources are directly managed/control by COMS. What do yo think?



Best wishes

Liang



________________________________

From: Netslices <netslices-bounces@ietf.org<mailto:netslices-bounces@ietf.org>> on behalf of Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com<mailto:hannu.flinck@nokia-bell-labs.com>>
Sent: 22 December 2017 22:02:46
To: qiangli (D); NetSlices@ietf.org<mailto:NetSlices@ietf.org>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface



Ok. Think I what you might be after. Probably what you want is to have a set of reference or example mappings for few representative technologies? Such as



-          A slice over the WAN/transport network for a given technology,

-          A slice over VNF infrastructure (SFCs and nvo3),

-          A slice that is a concatenation of the two across different domains (this we know is missing).



Is this what you would like to see? If so, it sounds to me reasonable and motivating work and would be  useful to identify possible gaps and needed additions.



Best regards

Hannu



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



Hi Hannu,



You’re right. Still that question, If there does not exist a uniform mapping interface between COMS and various implementation technologies, I am afraid we are unable to analyze all possibilities.  That’s why I suggested option 3 even I’m also not sure whether we can find out an appropriate classification method.



Best regards,



Cristina QIANG



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



Hello Cristina



I am not sure I understand the option 3 sufficiently. What would be the use of the classification? Should we identify classes of technologies that can be served by same/similar mapping based on the classification?



Best regards

Hannu



From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Thursday, December 21, 2017 11:02 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com<mailto:hannu.flinck@nokia-bell-labs.com>>; NetSlices@ietf.org<mailto:NetSlices@ietf.org>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface



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<mailto:qiangli3@huawei.com>>; NetSlices@ietf.org<mailto: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