Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Huzhibo <huzhibo@huawei.com> Sat, 26 February 2022 01:02 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 20A693A0D31; Fri, 25 Feb 2022 17:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_HELO_NONE=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 UOQfAayMNFgQ; Fri, 25 Feb 2022 17:02:43 -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 CCBE43A0D2A; Fri, 25 Feb 2022 17:02:34 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4K57Xc0CPnz67M6M; Sat, 26 Feb 2022 08:57:36 +0800 (CST)
Received: from canpemm500009.china.huawei.com (7.192.105.203) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 26 Feb 2022 02:02:30 +0100
Received: from canpemm500009.china.huawei.com (7.192.105.203) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 26 Feb 2022 09:02:28 +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.2308.021; Sat, 26 Feb 2022 09:02:28 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, "Ogaki, Kenichi" <ke-oogaki@kddi.com>
CC: Lou Berger <lberger@labn.net>, TEAS WG Chairs <teas-chairs@ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Thread-Index: AQHYJMuRH06ICbEKGUqo+b7lF0EdA6yh61KAgABkXQCAAr6oEA==
Date: Sat, 26 Feb 2022 01:02:27 +0000
Message-ID: <93f01a1b53d944278fe3b3c1dc483733@huawei.com>
References: <54263b17-4c97-8fcc-672c-146bed709b01@labn.net> <TY2PR01MB3562D0221712D45F1D6AB949903D9@TY2PR01MB3562.jpnprd01.prod.outlook.com> <CA+YzgTsmpyewHD0K8DdnVYmnyeoE4jB_F1_yTgMo+wQBe1T0WQ@mail.gmail.com>
In-Reply-To: <CA+YzgTsmpyewHD0K8DdnVYmnyeoE4jB_F1_yTgMo+wQBe1T0WQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.232.179]
Content-Type: multipart/alternative; boundary="_000_93f01a1b53d944278fe3b3c1dc483733huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6xeNd5JvkOduVseUPqp5n9RNjYQ>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
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: Sat, 26 Feb 2022 01:02:50 -0000

Hi:

I would appreciate it if the authors can clarify the following questions:

1.   Essentially the identifier in data packet is used to identify the NRP which the packet is mapped to, and the set of resource for processing and forwarding the packet. Calling it a flow aggregate selector would confuse the boundary between service flows and the underlay network construct (which is called NRP). In my understanding, the network devices only maintain the NRP specific resource states, they (except the ingress nodes) do not need to know whether and how service flows are mapped to the NRP.

2.   I’m a little confused about the case which multiple VPN labels are used to identify a Slice Flow Aggregate. The VPN service label are usually called service label, it is not clear how a service label can be used to identify a flow aggregate. And since this data plane ID need to be processed by intermediate nodes, can the VPN labels be parsed and processed by the intermediate nodes? BTW, the text in section 5.1.1 describes several options of encapsulating the identifier in MPLS packet header, which does not belong to a TEAS document, better to move them to an MPLS draft.

Thanks

Zhibo
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, February 24, 2022 11:04 PM
To: Ogaki, Kenichi <ke-oogaki@kddi.com>
Cc: Lou Berger <lberger@labn.net>; TEAS WG Chairs <teas-chairs@ietf.org>; draft-bestbar-teas-ns-packet@ietf.org; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Kenichi, Hi!

Thanks for the review! This draft discusses the use of Network Resource Partition (NRP) to support a Slice-Flow Aggregate. The NRP identifier is unique within an NRP domain and is meant for use in the control/management plane to identify the resources associated with the NRP (this should be the identifier used in any relevant control-plane protocol extensions).

The NRP-ID is not the same as Flow-Aggregate Selector (FAS). The FAS is quite simply the marking in the data plane packet that identifies a Slice-Flow Aggregate. The same Slice-Flow Aggregate may be identified by multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 where a range of VPN service labels – each acting as a FAS – select the same Slice-Flow Aggregate). The solution architecture leaves room for an implementation to overload the NRP-ID and use it as a FAS – but that is strictly an implementation choice.

And yes, we do expect all other related work to eventually align and adhere to what is specified in this document.

Regards,
-Pavan (as co-author)

On Thu, Feb 24, 2022 at 3:14 AM Ogaki, Kenichi <ke-oogaki@kddi.com<mailto:ke-oogaki@kddi.com>> wrote:
Hi Authors,

I'd just like to clarify.
Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig. 1 in this draft, I understand that this draft also describes one of solutions realizing Network Resource Partition(NRP).
If my understanding is correct, NRP-ID is essentially same as FASL and "Slice Aggregate ID" described at Fig.5 in draft-bestbar-lsr-slice-aware-te-00.
>From an operational perspective, it's burden to manage many slice related components and the mappings of these components, e.g. connectivity matrix <-> IETF network slice <-> Slice-flow Aggregate <-> FAS <-> NRP.
Do authors have any thought to at least unify these identifiers in a series of bestbar drafts. Or, is there any reason not able to unify these?

Thanks,
Kenichi
-----Original Message-----
From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Lou Berger
Sent: Friday, February 18, 2022 10:28 PM
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>
Subject: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hello,

This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/

Please note that IPR has been disclosed on this document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet

Please voice your support or objections to adoption on the list by the end of the day (any time zone) March 4.

Thank you,
Lou (as Co-chair)

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas