[Teas] Comments on draft-bestbar-teas-ns-packet-00

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 12 November 2020 07:52 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A0D1D3A14D3; Wed, 11 Nov 2020 23:52:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h-qChSJmVW0B; Wed, 11 Nov 2020 23:52:14 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56CD3A14D2; Wed, 11 Nov 2020 23:52:13 -0800 (PST)
Received: from fraeml740-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CWv085c08z67KkF; Thu, 12 Nov 2020 15:50:16 +0800 (CST)
Received: from dggeme754-chm.china.huawei.com ( by fraeml740-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Thu, 12 Nov 2020 08:52:11 +0100
Received: from dggeme754-chm.china.huawei.com ( by dggeme754-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 12 Nov 2020 15:52:09 +0800
Received: from dggeme754-chm.china.huawei.com ([]) by dggeme754-chm.china.huawei.com ([]) with mapi id 15.01.1913.007; Thu, 12 Nov 2020 15:52:09 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>
CC: "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>
Thread-Topic: Comments on draft-bestbar-teas-ns-packet-00
Thread-Index: Ada4yFzQlsTL3WHCS6W4IaR+h6AiDQ==
Date: Thu, 12 Nov 2020 07:52:09 +0000
Message-ID: <add31ffa20f543ca8b851088ab561013@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_add31ffa20f543ca8b851088ab561013huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dGr7dt0xnVpIyYyNE9QwlEJ5Dmg>
Subject: [Teas] Comments on draft-bestbar-teas-ns-packet-00
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 07:52:16 -0000

Hi authors,

I've read draft-bestbar-teas-ns-packet-00, please find some review comments from my side:

To my understanding, the mechanism described in this document aligns with the VPN+ framework described in draft-ietf-teas-enhanced-vpn. More specifically, this document describes different approaches of reserving dedicated or shared network resources for logical (or virtual) networks to provide network slicing. It also describes the mechanisms to steer traffic on the specific network resources allocated for the network slices. Thus it would be reasonable to reference draft-ietf-teas-enhanced-vpn in this document.

Section 4 describes three approaches for resource partitioning. First please note that the list a), b) and c) is not in the same order as sections 4.1, 4.2 and 4.3. Then I'm a little confused with this classification. If my understanding is correct, The difference is whether the resource is reserved in data plane or not (i.e. hard or soft isolation). While no matter which approach is used, the resource reservation state needs to be maintained in control plane (either in a central controller or in the control plane of devices). And the resource sharing described in 4.2 between multiple slices within a group is also possible with the data plane based resource partitioning. Thus I'm not sure "data plane only" and "control plane only" are the appropriate terms here. How about using "data plane resource partitioning" and "control plane resource reservation" instead?

After reading section 4.3, my understanding is this subsection actually talks about two things of a network slice: resource reservation and topology customization. Then perhaps it should not be listed as the third approach for resource partitioning/reservation. The combination of the resource and topology attributes may be described in a separate section.

In section 5.1, it mentions a network slice may be realized using a network slice service Layer, and a device/resource Layer. In management plane, this separation of functionality can be seen in the context of RFC 8309 by considering that the NBI described here is a customer service interface, which is mapped down to network and device configuration interfaces. The term network slice service layer aligns with the NS-DT documents that a network slice is a service provided to a consumer. Then one question is: can the device/resource layer also be called a network slice? Using the same term for both the service layer and the resource layer may cause ambiguity. Maybe it is better to provide a dedicated term for the resource layer in the network slice context? For example, in draft-ietf-teas-enhanced-vpn, the virtual underlay network is called a VTN.

Section 5.2.1 describes two options for Slice data plane selector, and analyzed the scalability challenges with the first approach. This section is relevant to draft-dong-spring-sr-for-enhanced-vpn, which describes the mechanism of using different SR SIDs or SRv6 Locators to identify the nodes/links and the resources allocated to different VTNs. And the scalability considerations for VPN+ are described in draft-dong-teas-enhanced-vpn-vtn-scalability, which provides the scalability analysis and optimizations in both the control plane and the data plane. For IPv6 data plane, one approach to carry the VTN identifier in data packet is described in draft-dong-6man-enhanced-vpn-vtn-id. My understanding to this section is it may aim to cover the native IP and legacy MPLS cases? Anyway, some coordination between these drafts would be helpful.

Section 6 provide some general considerations about routing protocol extensions. For this part you may refer to the VTN and VPN+ drafts in LSR and IDR WG, which provides the control plane solutions with different scalability and flexibility characteristics. Comments are always welcomed.

Hope this helps.

Best regards,