Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt

"Wubo (lana)" <lana.wubo@huawei.com> Fri, 29 April 2022 09:08 UTC

Return-Path: <lana.wubo@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 71F6BC15ED4F; Fri, 29 Apr 2022 02:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 nGEPAxlGH83m; Fri, 29 Apr 2022 02:08:44 -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 85523C157B47; Fri, 29 Apr 2022 02:08:44 -0700 (PDT)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KqRPq42fTz67gPH; Fri, 29 Apr 2022 17:04:31 +0800 (CST)
Received: from kwepemi100012.china.huawei.com (7.221.188.202) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Fri, 29 Apr 2022 11:08:39 +0200
Received: from kwepemi500014.china.huawei.com (7.221.188.232) by kwepemi100012.china.huawei.com (7.221.188.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 29 Apr 2022 17:08:38 +0800
Received: from kwepemi500014.china.huawei.com ([7.221.188.232]) by kwepemi500014.china.huawei.com ([7.221.188.232]) with mapi id 15.01.2375.024; Fri, 29 Apr 2022 17:08:38 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Tarek Saad <tsaad.net@gmail.com>, "teas@ietf.org" <teas@ietf.org>
CC: "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>
Thread-Topic: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt
Thread-Index: AQHYVcq5+Dh1eV0JmkSam33Wx6wuNKz7Z4gAgAs62vA=
Date: Fri, 29 Apr 2022 09:08:37 +0000
Message-ID: <617013ce169d417f808f85fef153e103@huawei.com>
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:
x-originating-ip: [10.136.98.73]
Content-Type: multipart/alternative; boundary="_000_617013ce169d417f808f85fef153e103huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VW2A961FMPe4TYp9cV_1I7y4-VI>
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: Fri, 29 Apr 2022 09:08:46 -0000

Hi Tarek, all,

Thanks for update. I have read the new revision and here are my comments:

"Section 4 Network Resource Partition Modes":

-          Suggest to add definition of IP/MPLS based NRP. Otherwise, it's not clear why the three modes are defined.

-          Suggest to add descriptions of which technologies can guarantee the SLO/SLE of the types of connection constructs, including P2P, P2MP, and A2A and the various combinations. NS framework draft says NRP support mapping connection constructs from slice services to ensure SLO/SLE.

-          Will this section provide all candidate NRP realization technologies? I see the reference to "SR Policy with or without Flexible Algorithm" in chapter 7 and not sure if Flexible Algorithm is also a Control Plane Network Resource Partition?

Terms alignment:
-        "NRP" or "NRP that supports a Slice-Flow Aggregate": In the draft, "NRP that supports a Slice-Flow Aggregate" are often used. Can it simply say NRP? Or can you clarify which technologies belong to NRP that does not support slice flow aggregation?
-        NRP filter topology: As described in the NS framework draft, filter topology is just one optional approach to define the NRP topology. The generic term should be NRP topology.
-        Topology Filter and filter topology are mixed up. Topology filter is just one specific realization and not generic, need to remove it or make this clear. And this is also related to the figure 4 in the NS framework draft. My understanding is the "topology filter" in the Figure 1 and the title of section 3.2 should be removed, as there is no description about topology filter in the text of section 3.2.

Thanks,
Bo

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Tarek Saad
Sent: Friday, April 22, 2022 9:27 PM
To: teas@ietf.org
Cc: teas-chairs@ietf.org; draft-bestbar-teas-ns-packet@ietf.org
Subject: 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<mailto:teas-bounces@ietf.org>> on behalf of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Thursday, April 21, 2022 at 5:56 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Cc: teas@ietf.org<mailto:teas@ietf.org> <teas@ietf.org<mailto: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<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas