Re: [Teas-ns-dt] Figure in the ACTN Applicability section

Zhenghaomian <zhenghaomian@huawei.com> Wed, 13 May 2020 02:13 UTC

Return-Path: <zhenghaomian@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 1B1633A0CD2 for <teas-ns-dt@ietfa.amsl.com>; Tue, 12 May 2020 19:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 Zr6odYJOn40V for <teas-ns-dt@ietfa.amsl.com>; Tue, 12 May 2020 19:13:25 -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 E836F3A0CD1 for <teas-ns-dt@ietf.org>; Tue, 12 May 2020 19:13:24 -0700 (PDT)
Received: from lhreml711-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 249BE703E4AF89442810; Wed, 13 May 2020 03:13:23 +0100 (IST)
Received: from lhreml711-chm.china.huawei.com (10.201.108.62) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 13 May 2020 03:13:22 +0100
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 13 May 2020 03:13:22 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.132]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Wed, 13 May 2020 10:13:15 +0800
From: Zhenghaomian <zhenghaomian@huawei.com>
To: "Luis M. Contreras" <contreras.ietf@gmail.com>, Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>
CC: "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: [Teas-ns-dt] Figure in the ACTN Applicability section
Thread-Index: AdYozA3rqd4CYb0xSBWvavcvuKUlpA==
Date: Wed, 13 May 2020 02:13:14 +0000
Message-ID: <E0C26CAA2504C84093A49B2CAC3261A43F8547A0@dggeml531-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.176.178]
Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A43F8547A0dggeml531mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/7wr86S-iwK3lEPrmWS_IoezaMI0>
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section
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, 13 May 2020 02:13:28 -0000

Hi, Luis, Eric, All,

Thanks for the effort on making the mapping more complete. Actually I think both the updated proposal from {Eric, Dhruv, John} and the one from Luis are applicable in some cases, and how to deploy is fully dependent on the choice of implementation. Compared with the previous version in section 4 of draft-nsdt-teas-ns-framework-03, the main improvement is ‘TS-NBI is using technology-agnostic models’, as said by Eric.

According to our experience in ACTN deployment, there are flexibilities on how many hierarchies of MDSC is needed, depending on the functionality of each hierarchy and the scalability of the network. I believe none of us are trying to exclude any implementation, neither the proposal from Eric nor Luis. So a more generic proposal is shown as follow, thoughts?

Service Model in                                              ACTN
 Transport Slice        Transport Slice Framework           Terminology
Framework [RFC8309]                                         and Concepts
-------------          -------------------------           ------------
                 +------------------------------------+
                 |             Customer               |  |
                 +------------------------------------+
   Customer                        A                     |
   Service                         |
   Model                           V                     |
                 +------------------------------------+
                 |      A highter level system        |  |   +-----+
                 |(e.g e2e network slice orchestrator)| ===> | CNC |
                 +------------------------------------+  |   +-----+
   Service                         A                            A
   Delivery                        | TSC NBI             |      | CMI
   Model                           V                            V (LxSM)
                 +------------------------------------+  |   +-------+
                 |      Transport Slice Controller    | ===> | MDSC-H|
                 +------------------------------------+  |   +-------+
   Network                         A                            A
   Configuration                   | TSC SBI             |      |
   Model                           V                            V
                 +-----------------------------------+   |   +-------+
                 |                                   |  ===> |MDSC-L |
                 |                                   |   |   +-------+
                 |                                   |           A
                 |        Network Controller(s)      |   |       | MPI
                 |                                   |           V
                 |                                   |   |   +-----+
                 |                                   |  ===> | PNC |
                 +-----------------------------------+   |   +-----+

My 2 cents,
Haomian

发件人: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] 代表 Luis M. Contreras
发送时间: 2020年5月13日 0:03
收件人: Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>
抄送: teas-ns-dt@ietf.org
主题: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

(My apologies for the mail before, with the Confidential Notes by default. Please, ignore it. Repeating mail here).

Hi Eric, all,

Thanks for addressing this point.

I have some few comments and suggestions.

1/ Regarding the figure, I think that as it is now mix things a bit. In my personal subjective view I think it provides a view of how to fit TSC into ACTN rather in the other way around. My suggestion would be to depict the comparison as in the figure below (ignore the service model naming by now for this point). I think it becomes more clear, but again this is subjective, of course.

2/ Regarding the service model naming. I have revisited RFC8309 and I think that the proper mapping to service models in the case of TSC would be the one proposed in the figure below on the left-hand side (please, check Figure 3 in RFC8309).

Here is the figure I propose.

Service Model in                                              ACTN
 Transport Slice        Transport Slice Framework           Terminology
Framework [RFC8309]                                         and Concepts
-------------          -------------------------           ------------
                 +------------------------------------+
                 |             Customer               |  |
                 +------------------------------------+
   Customer                        A                     |
   Service                         |
   Model                           V                     |
                 +------------------------------------+
                 |      A highter level system        |  |   +-----+
                 |(e.g e2e network slice orchestrator)| ===> | CNC |
                 +------------------------------------+  |   +-----+
   Service                         A                            A
   Delivery                        | TSC NBI             |      | CMI
   Model                           V                            V (LxSM)
                 +------------------------------------+  |   +-------+
                 |      Transport Slice Controller    | ===> | MDSC-H|
                 +------------------------------------+  |   +-------+
                                   A                            A
                                   |                     |      |
                                   |                            V
   Network                         |                     |   +-------+
   Configuration                   | TSC SBI                 |MDSC-L |
   Model                           |                     |   +-------+
                                  |                            A
                                   |                     |      | MPI
                                   V                            V (LxNM)
                 +------------------------------------+  |   +-----+
                 |        Network Controller(s)       | ===> | PNC |
                 +------------------------------------+  |   +-----+


The text you propose depends totally on the final figure and the consideration of the service models that apply, so I would prefer to discuss first about the figure and once it is closed to discuss the text, to ensure consistency.

Thanks

Luis

El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>>) escribió:

John and I had a discussion with Dhruv about some ambiguity in the relationship between some of the entities in the ACTN architecture and the related concepts in our NS-DT work in the Framework draft.



The upshot is that there is a bit of a slushy relationship between some of the terms that we (the NS design team) have defined (see the definitions draft) and loosely corresponding concepts defined in ACTN.  In particular, there are currently issues with the positioning of the TSC as directly analogous to MDSC, impacting interfaces between these logical components as well.



After a few iterations in discussion, Dhruv, John and I agreed to propose a replacement figure and text as shown immediately below.



       +------------------------------------+

       |             Customer               |  |

       +------------------------------------+

                         A                     |     ACTN

                         |                        Terminology

                         V                     |  and Concepts

       +------------------------------------+

       |      A highter level system        |  |   +-----+

       |(e.g e2e network slice orchestrator)| ===> | CNC |

       +------------------------------------+  |   +-----+

                         A                            A

                         | TSC NBI             |      | CMI

                         V                            V (LxSM)

       +------------------------------------+  |   +-------+

       |      Transport Slice Controller    | ===> | MDSC-H|

       +------------------------------------+  |   +-------+

                         A                            A

                         | TSC SBI (LxNM)      |      |

                         V                            V

       +------------------------------------+  |   +-------+

       |        Network Controller(s)       | ===> |MDSC-L |

       +------------------------------------+  |   +-------+

                                                      A

                Terminology/Concepts           |      | MPI

               Used in this Document                  V

                                               |   +-----+

                                                   | PNC |

                                               |   +-----+





We would also add further clarifying text along the lines of:



The TS-NBI would be at the same level as the customer service models (LxSM), except that it uses a technology agnostic service model where as LxSM does not.



We add hierarchy to the MDSC concept in this figure so that the mapping with LxNM might be easier to see.  But the TSC could also directly interact with multiple domain controllers in which case we have a single MDSC.



If nobody objects, or has additional input they would like to provide, we would like to go ahead and make this change to the Framework draft.



If necessary, we can discuss this at the meeting on Thursday (14 May).



--

Eric
--
Teas-ns-dt mailing list
Teas-ns-dt@ietf.org<mailto:Teas-ns-dt@ietf.org>
https://www.ietf.org/mailman/listinfo/teas-ns-dt


--
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com<mailto:contreras.ietf@gmail.com>
luismiguel.contrerasmurillo@telefonica.com<mailto:luismiguel.contrerasmurillo@telefonica.com>
Global CTIO unit / Telefonica