[Teas] Re: Revisiting NRP Selector
"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 11 February 2025 15:14 UTC
Return-Path: <jie.dong@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 DEEDBC4E351E; Tue, 11 Feb 2025 07:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 hn2CzwQERPdu; Tue, 11 Feb 2025 07:14:24 -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 C8889C4E3510; Tue, 11 Feb 2025 07:14:23 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4YslKT2nbBz6H8Vv; Tue, 11 Feb 2025 23:11:57 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 4A00A1402CB; Tue, 11 Feb 2025 23:14:21 +0800 (CST)
Received: from dggpemf100008.china.huawei.com (7.185.36.138) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 11 Feb 2025 15:14:20 +0000
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 11 Feb 2025 23:14:18 +0800
Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.011; Tue, 11 Feb 2025 23:14:17 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] Re: Revisiting NRP Selector
Thread-Index: AQHbdgKXaStHvrcRuEK3uVrPHeoE4bNCQfOw
Date: Tue, 11 Feb 2025 15:14:17 +0000
Message-ID: <67c19702cd4d44848ac96bfb282e737e@huawei.com>
References: <CA+YzgTu9CKq7wMKkUhhDdZXTqvp+BHLvWeQmXa-PmeknA2VaNw@mail.gmail.com> <CA+YzgTvG9hqKYZeUwQVbcFGox=Z10XatgHcDbHZR8sHXFGvgmQ@mail.gmail.com>
In-Reply-To: <CA+YzgTvG9hqKYZeUwQVbcFGox=Z10XatgHcDbHZR8sHXFGvgmQ@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.85.151.245]
Content-Type: multipart/alternative; boundary="_000_67c19702cd4d44848ac96bfb282e737ehuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: CA2D26LNCSDXEIQRI3LEYS2DVXVGGJ3T
X-Message-ID-Hash: CA2D26LNCSDXEIQRI3LEYS2DVXVGGJ3T
X-MailFrom: jie.dong@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: TEAS WG Chairs <teas-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Teas] Re: Revisiting NRP Selector
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/08YBvm3ZQVe5GprFY263OtQj-zY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
Thanks to the chairs for the effort on this questionnaire. I agree with all these conclusions, and will update the relevant drafts accordingly. Best regards, Jie From: Vishnu Pavan Beeram <vishnupavan@gmail.com> Sent: Monday, February 3, 2025 2:11 PM To: TEAS WG <teas@ietf.org> Cc: TEAS WG Chairs <teas-chairs@ietf.org> Subject: [Teas] Re: Revisiting NRP Selector WG, We have received seven responses to the questionnaire the chairs sent out (Thanks to those who responded!). It is not an overwhelming number, but we can draw some conclusions to progress the work. Please see inline (prefixed [Chairs]) for the conclusions. The authors of draft-ietf-teas-ns-ip-mpls, draft-ietf-teas-nrp-scalability, and draft-ietf-teas-nrp-yang are requested to edit the respective drafts accordingly. Regards, -Pavan and Oscar On Wed, Oct 9, 2024 at 12:45 PM Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>> wrote: We had a virtual interim meeting on May 29th 2024 to discuss the following NRP Selector specific items: * Generic requirements and options for carrying NRP Selector in IP and MPLS packets * The relevant modeling aspects * The data plane specific extensions that come into play when a dedicated identifier is used as the NRP selector. The meeting minutes are captured at: * https://datatracker.ietf.org/meeting/interim-2024-teas-01/materials/minutes-interim-2024-teas-01-202405291400-00 We (the chairs) are starting a thread to close on some of the items specific to having a dedicated identifier that is used as NRP selector (note that NRP selector refers to the marking in the packet’s network layer header that is used to associate the packet with an NRP). * What do we call this dedicated identifier field? * “NRP Selector ID” and “NRP Data Plane ID” have been proposed so far. [Chairs] We received two preferences for "Data Plane NRP ID," two for "NRP Data Plane ID," and three for "NRP Selector ID." It is unlikely that we will converge on a specific term. Any of these terms would work, but it is high time we picked one and rolled with it. Let's go with "NRP Selector ID". * Length of the dedicated identifier field * Is it okay for this to be different for different data-plane types? * A 32-bit field has been proposed for the IPv6 Data-Plane; A couple of options – 8 bits and 13 bits – have been proposed for the MPLS data plane * Please note that the actual data-plane specific encodings are outside the scope of the TEAS WG. [Chairs] The conclusion is that the length of the NRP Selector ID can be different for different data plane types. The recommendation is to have a minimum length of 8 bits. The actual data-plane-specific encodings are outside the scope of the TEAS WG. * “Strict” match indicator * When a dedicated identifier is used as the NRP Selector, is it useful to have an explicit indicator to determine what to do with a packet that cannot be mapped to an NRP? * Drop the packet vs Map it to a default set of network resources * The actual encoding of this “indicator” could be different for different data-plane types and will need to be discussed in the respective WGs (outside the scope of TEAS WG). [Chairs] We received four responses supporting the "strict match indicator" encoding in the data packet. Two responses said this is unnecessary because it should always be a "Strict Match" (the operator can configure local policy to override this if needed). We believe that "strict match" is the default option and that having a local policy to override this behavior would cover most operational scenarios. However, encoding the "strict match indicator" in the data packet provides more granular control and can be deemed a "nice-to-have" feature. We don't see a strong reason not to allow this. The actual encoding of this “indicator” could differ for different data plane types and must be discussed in the respective WGs (outside the scope of TEAS). Please chime in with your thoughts on these items. - Pavan and Oscar ps: @Jie – Thanks for the offline prod. Please feel free to add other open items specific to NRP selector (that we may have missed) to the above list.
- [Teas] Revisiting NRP Selector Vishnu Pavan Beeram
- [Teas] Re: Revisiting NRP Selector Chongfeng Xie
- [Teas] Re: Revisiting NRP Selector Dongjie (Jimmy)
- [Teas] Re: Revisiting NRP Selector Gyan Mishra
- [Teas] Re: Revisiting NRP Selector Wubo (lana)
- [Teas] Re: Revisiting NRP Selector Vishnu Pavan Beeram
- [Teas] Re: Revisiting NRP Selector Ketan Talaulikar
- [Teas] Re: Revisiting NRP Selector Loa Andersson
- [Teas] Re: Revisiting NRP Selector Greg Mirsky
- [Teas] Re: Revisiting NRP Selector Ketan Talaulikar
- [Teas] Re: Revisiting NRP Selector Dongjie (Jimmy)
- [Teas] Re: Revisiting NRP Selector Vishnu Pavan Beeram
- [Teas] Re: Revisiting NRP Selector Dongjie (Jimmy)