Re: [Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft

"Wubo (lana)" <lana.wubo@huawei.com> Wed, 22 April 2020 06:36 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 0A0483A0793 for <teas-ns-dt@ietfa.amsl.com>; Tue, 21 Apr 2020 23:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 qBb3QN-0zpMr for <teas-ns-dt@ietfa.amsl.com>; Tue, 21 Apr 2020 23:36:43 -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 3E6E13A0791 for <teas-ns-dt@ietf.org>; Tue, 21 Apr 2020 23:36:43 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EF1C725E9CA52885BD7C for <teas-ns-dt@ietf.org>; Wed, 22 Apr 2020 07:36:40 +0100 (IST)
Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 22 Apr 2020 07:36:40 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme753-chm.china.huawei.com (10.3.19.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 22 Apr 2020 14:36:38 +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; Wed, 22 Apr 2020 14:36:38 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: Models Discussion - specifically, SLO groups, in the current model draft
Thread-Index: AdYYbU6Kl2JUHyJOQ9+h2Nev2gYGvQ==
Date: Wed, 22 Apr 2020 06:36:38 +0000
Message-ID: <454ae0b8007e4cb4a8dcc72118b54ece@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.83]
Content-Type: multipart/alternative; boundary="_000_454ae0b8007e4cb4a8dcc72118b54ecehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/-AbvCRnDqYZbivD_MLMBuUkoFM0>
Subject: Re: [Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft
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: Wed, 22 Apr 2020 06:36:46 -0000

Hi Eric,

I agree what I said at the meeting is confusing and there is no agreement on the definition of the TS End point yet.
Thank you for setting up the thread for the discussion. I think endpoint definition is a key part of the NBI model.

Please see the reply inline below.

Thanks,
Bo

·¢¼þÈË: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] ´ú±í Eric Gray
·¢ËÍʱ¼ä: 2020Äê4ÔÂ21ÈÕ 0:55
ÊÕ¼þÈË: teas-ns-dt@ietf.org
Ö÷Ìâ: [Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft

Fellow design team members, et al:

I have a number of issues with both the draft, and the discussions we¡¯ve had about it, but I would prefer to use this thread to focus on the issues with Transport Slice ¡°End-Points¡± (or, perhaps, Transport Slice Members.  I have already tried to start a discussion about the issues with ¡°SLO Group¡± as discussed in today¡¯s meeting and in the draft.

Again, AFAICT, we¡¯ve had very little discussion about Modeling work on the mailing list ¨C beyond simple announcements about new versions of Bo¡¯s draft, and a few (mostly unanswered) comments about the draft.

And, again, I have looked at the latest version of the model draft, and I was present during the discussion of this draft today, and the discussion of the previous draft last Thursday.

In today¡¯s discussion, we talked briefly about TS end-points.  A number of examples were given, and Bo said that we had likely reached some agreement of what we mean by a transport slice end-point.  I would like to have a better understanding of what that agreement is, because I did not see any such agreement.

Speaking as someone who has been to this rodeo a few times, I think what we really need to do is define an abstract interface that exists between a transport slice realization and a transport slice user..

It is not clear to me that we have even agreed whether or not we want to define that abstract interface in a way that would mean it exists ¡°on the wire¡± (the link between a TS and its user) or on a node at one end of the ¡°wire¡± or the other (or both ends).
[Bo] The TS Endpoint definition in the draft is a logical identifier, which could be existed on either end of the ¡°wire¡±. So it means both ends, and ¡®node-id, tp-id and ts-traffic-criteria¡¯
are used to specify, e.g. node-id could be CE node or PE node, the higher system and TSC need to agree.
If you think that the figure, EP ¡°on the wire¡±, is misleading, we will correct it in the next revision.

If we do think we have such an agreement, I would prefer to see it very clearly spelled out, before  signing off on it.

--
Eric

--
Eric