[Lsr] Regarding the scalable network slicing solutions
Lizhenbin <lizhenbin@huawei.com> Mon, 08 March 2021 17:24 UTC
Return-Path: <lizhenbin@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ADF3A119A for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 09:24:31 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 tglWRE96walb for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 09:24:29 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791C23A1191 for <lsr@ietf.org>; Mon, 8 Mar 2021 09:24:29 -0800 (PST)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvQ6K6sY3z67wXD for <lsr@ietf.org>; Tue, 9 Mar 2021 01:18:33 +0800 (CST)
Received: from fraeml797-chm.china.huawei.com (10.206.15.18) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 18:24:27 +0100
Received: from fraeml797-chm.china.huawei.com (10.206.15.18) by fraeml797-chm.china.huawei.com (10.206.15.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 18:24:27 +0100
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by fraeml797-chm.china.huawei.com (10.206.15.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Mon, 8 Mar 2021 18:24:26 +0100
Received: from DGGEMM512-MBS.china.huawei.com ([169.254.4.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0513.000; Tue, 9 Mar 2021 01:24:20 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Regarding the scalable network slicing solutions
Thread-Index: AdcUQG2mBeChOpKSRtGZ9VR3CKmrOA==
Date: Mon, 08 Mar 2021 17:24:19 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D93A2552A@dggemm512-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.45.180.61]
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D93A2552Adggemm512mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zaJkgwaTnIIbqtxF5H9qWS8KOrE>
Subject: [Lsr] Regarding the scalable network slicing solutions
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 17:24:32 -0000
Hi Tarek, The draft draft-dong-teas-enhanced-vpn-vtn-scalability describes the more scalable solutions for network slicing. It is apparent that it has to introduce the new encapsulation using MPLS and/or IPv6 as the data plane which propose challenges for the hardware implementation. It has been discussed for a long time how many network slices the customer may need for a specific network. It seems now tens of slices can satisfy many requirements and the SR-based VTN solution is available quickly reusing the SR data plane. There should be trade-off. Best Regards, Zhenbin (Robin)