Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt
Huzhibo <huzhibo@huawei.com> Thu, 28 April 2022 15:58 UTC
Return-Path: <huzhibo@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA504C15EB2E; Thu, 28 Apr 2022 08:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.33
X-Spam-Level:
X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skuvi9FW4CaA; Thu, 28 Apr 2022 08:58:29 -0700 (PDT)
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 818FEC15E6E0; Thu, 28 Apr 2022 08:58:29 -0700 (PDT)
Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kq0Y76tGDz67NX0; Thu, 28 Apr 2022 23:54:19 +0800 (CST)
Received: from canpemm500010.china.huawei.com (7.192.105.118) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Thu, 28 Apr 2022 17:58:25 +0200
Received: from canpemm500009.china.huawei.com (7.192.105.203) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 28 Apr 2022 23:58:24 +0800
Received: from canpemm500009.china.huawei.com ([7.192.105.203]) by canpemm500009.china.huawei.com ([7.192.105.203]) with mapi id 15.01.2375.024; Thu, 28 Apr 2022 23:58:24 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Tarek Saad <tsaad.net@gmail.com>, TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>, draft-bestbar-teas-ns-packet <draft-bestbar-teas-ns-packet@ietf.org>
Thread-Topic: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt
Thread-Index: AQHYVcq51fZWuM59hU6FFwc/3z5ilqz7Z4gAgAoed2U=
Date: Thu, 28 Apr 2022 15:58:24 +0000
Message-ID: EA885FB4-39ED-4C40-92BA-1CD7CAE86A88
References: <165057815598.9368.7216073171936460040@ietfa.amsl.com>, <DM5PR1901MB21502356D6CCD55BA629F1C0FCF79@DM5PR1901MB2150.namprd19.prod.outlook.com>
In-Reply-To: <DM5PR1901MB21502356D6CCD55BA629F1C0FCF79@DM5PR1901MB2150.namprd19.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_EA885FB439ED4C4092BA1CD7CAE86A88_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CbKum6tywW0IlXDVczXOPuy_54Y>
Subject: Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.34
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, 28 Apr 2022 15:58:31 -0000
Hi all, I've read the update version and think there are still issues which could impede correct understanding of the network slice realization and the required functionality on network nodes. It would be good if these issues can be solved in an update version before the adoption. 1. Slice-Flow Aggregate (SFA) and NRP In my understanding the concept Slice-Flow Aggregate is to describe an optional behavior on the controller or the ingress node which can group multiple network traffic flows together. But the relationship between SFA and NRP is still not clear from the document. During the adoption call discussion, it seems the conclusion is that there is one-to-one mapping of SFA to NRP. If this is the case, it is better to make it explicit in the draft. My greatest concern is that in several places in the document, the description indicates that transit nodes also need to be aware of the mapping of slice flows to SFA, which apparentely is not true. For example, section 4.1 says: "In the data plane NRP mode, the transit nodes within an NRP domain use the FAS to associate packets with a Slice-Flow Aggregate and to determine the Network Resource Partition Per Hop Behavior (NRP-PHB) that is applied to the packet." The transit nodes do not need to know how the packet is mapped to an NRP, thus they are not aware of the SFA. What they need to do is to use some identifier in the packet to determine the corresponding NRP and forward the packet according to the NRP's forwarding behavior. Thus Slice-Flow Aggregate does not need to be mentioned in the text about transit nodes behavior. In the document there are many other occurrence of SFA where it was actually talking about NRP. My suggestion is to only use SFA in the description of the traffic aggregation procedure. 2. Flow Aggregate Selector (FAS) / G-FAS or NRP-ID During the adoption call, there was comment that NRP-ID is essentially the same as FAS and G-FAS, and it was suggested to simplify the mapping between different terms/components. According to the example above, the FAS is used by the transit nodes to determine the NRP, thus it makes more sense to call it NRP-ID or NRP specific IDs directly. thanks zhibo ________________________________ 胡志波 Hu Zhibo Mobile: +86-18618192287 Email: huzhibo@huawei.com 发件人:Tarek Saad <tsaad.net@gmail.com> 收件人:TEAS WG <teas@ietf.org> 抄 送:TEAS WG Chairs <teas-chairs@ietf.org>;draft-bestbar-teas-ns-packet <draft-bestbar-teas-ns-packet@ietf.org> 时 间:2022-04-22 21:27:12 主 题:Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt Dear WG and Chairs, We have made changes to I-D.draft-bestbar-teas-ns-packet to address comments that were received during the working group adoption poll for the revision -08 of this draft. The changes include: * Removing references to work-in-progress drafts * Moving status of the draft to informational * Adding Section 9 to record non-blocking issues raised during the WG adoption poll * Some editorial nits, including fixing RFC2119 language. We welcome further review and feedback. Regards, Tarek (for co-authors) From: Teas <teas-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org> Date: Thursday, April 21, 2022 at 5:56 PM To: i-d-announce@ietf.org <i-d-announce@ietf.org> Cc: teas@ietf.org <teas@ietf.org> Subject: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Realizing Network Slices in IP/MPLS Networks Authors : Tarek Saad Vishnu Pavan Beeram Jie Dong Bin Wen Daniele Ceccarelli Joel Halpern Shaofu Peng Ran Chen Xufeng Liu Luis M. Contreras Reza Rokui Luay Jalil Filename : draft-bestbar-teas-ns-packet-09.txt Pages : 31 Date : 2022-04-21 Abstract: Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- [Teas] I-D Action: draft-bestbar-teas-ns-packet-0… internet-drafts
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Tarek Saad
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Huzhibo
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Wubo (lana)
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Tarek Saad
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Tarek Saad
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Huzhibo
- Re: [Teas] I-D Action: draft-bestbar-teas-ns-pack… Tarek Saad