Re: [Teas-ns-dt] Suggestion for "fixing" the tables shared between our DT drafts.

"Wubo (lana)" <lana.wubo@huawei.com> Thu, 09 July 2020 10:09 UTC

Return-Path: <lana.wubo@huawei.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22323A082D for <teas-ns-dt@ietfa.amsl.com>; Thu, 9 Jul 2020 03:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 RDP8ext4dzfd for <teas-ns-dt@ietfa.amsl.com>; Thu, 9 Jul 2020 03:09:10 -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 78D2E3A0847 for <teas-ns-dt@ietf.org>; Thu, 9 Jul 2020 03:09:09 -0700 (PDT)
Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F176E39750BAC7CB8DCE for <teas-ns-dt@ietf.org>; Thu, 9 Jul 2020 11:09:07 +0100 (IST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Thu, 9 Jul 2020 11:09:07 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 9 Jul 2020 18:09:04 +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; Thu, 9 Jul 2020 18:09:04 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>, teas-ns-dt <teas-ns-dt@ietf.org>, teas-wg/teas-ns-dt <teas-ns-dt@noreply.github.com>
Thread-Topic: Suggestion for "fixing" the tables shared between our DT drafts.
Thread-Index: AdZV2ETEWl8etc+YSSqkSobT2+WMMA==
Date: Thu, 9 Jul 2020 10:09:04 +0000
Message-ID: <e7e401530459467d8c856e55d36fafff@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.74.183]
Content-Type: multipart/alternative; boundary="_000_e7e401530459467d8c856e55d36fafffhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/CjxKovKe2W4iwNyEwYykIGK7vBQ>
Subject: Re: [Teas-ns-dt] Suggestion for "fixing" the tables shared between our DT drafts.
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 10:09:20 -0000

Hi all,

I also support the ¡°customer¡± figure modification.

In IETF 107, Susan Hares had many concerns about whether the TS NBI is a customer service model or a network resource model.
It seems quite reasonable for her to think that the interface between the higher level operation system and customer is a kind of customer service model, either from text below the figure or from the figure itself.

In the current TS NSDT drafts, the customer interface of the figure is no direct relationship with TSC NBI, and the TSC NBI is actually a customer intent interface.

This figure is used in both the draft definitions and the framework. As suggested by Eric, I also support that both the documents can be modified.

Thanks,
Bo

·¢¼þÈË: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] ´ú±í Eric Gray
·¢ËÍʱ¼ä: 2020Äê7ÔÂ9ÈÕ 0:00
ÊÕ¼þÈË: teas-ns-dt <teas-ns-dt@ietf.org>rg>; teas-wg/teas-ns-dt <teas-ns-dt@noreply.github.com>
Ö÷Ìâ: [Teas-ns-dt] Suggestion for "fixing" the tables shared between our DT drafts.

Currently, Figure 4 in the definitions draft and Figure 1 in the Framework draft include (at least as a subset) the following ASCII art figure or at least something very like it).


       +---------------------------------------+
       |              Customer                 |
       +---------------------------------------+
                         ^
                         |
                         v
       +---------------------------------------+
       |   A higher level operation system     |
       | (e.g. e2e network slice orchestrator) |
       +---------------------------------------+
                         ^
                         | TSC NBI
                         v
       +---------------------------------------+
       |       Transport Slice Controller      |
       +---------------------------------------+
                         ^
                         | TSC SBI
                         v
       +---------------------------------------+
       |    Transport Network Controller(s)    |
       +---------------------------------------+


As discussed during the last meeting, there is some ambiguity related to exactly what we mean by ¡°Customer¡± and whether or not it even makes sense to have this as a block in those figures.

I suggest ¨C as a ¡°fix¡± ¨C that we consider replacing the above part of both Figures with something along the lines of:

       +---------------------------------------+
       |        Network Slice Consumer         |
       | (e.g. e2e network slice orchestrator) |
       +---------------------------------------+
                         ^
                         | TSC NBI
                         v
       +---------------------------------------+
       |       Transport Slice Controller      |
       +---------------------------------------+
                         ^
                         | TSC SBI
                         v
       +---------------------------------------+
       |    Transport Network Controller(s)    |
       +---------------------------------------+

We do not need to make this change prior to the submission deadline, unless some folks feel that we would have more trouble getting the two drafts adopted in IETF 108.

I would also like to point out that ¨C based on the issues raised with respect to ¡°TSC SBI¡± and TNC (which are actually out of scope in this effort) ¨C we could possibly/eventually change this figure further to look like this:

       +---------------------------------------+
       |   A higher level operation system     |
       | (e.g. e2e network slice orchestrator) |
       +---------------------------------------+
                         ^
                         | TSC NBI
                         v
       +---------------------------------------+
     +-|       Transport Slice Controller      |-+
     | +---------------------------------------+ |
     |                   ^                       |
     |                   | TSC SBI               |
     |                   v                       |
     | +---------------------------------------+ |
     | |    Transport Network Controller(s)    | |
     | +---------------------------------------+ |
     |                                           |
     +-------------------------------------------+

The big block that includes everything in this figure from the TSC down (i.e. ¨C TSC SBI and TNCs) would be described as logical components that would not be visible to a network slice consumer and are therefore out of scope.

--
Eric