[Teas] Re: Revisiting NRP Selector
"Wubo (lana)" <lana.wubo@huawei.com> Sun, 03 November 2024 10:52 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 7F7B0C1D4A92; Sun, 3 Nov 2024 02:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 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_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 4SDfee3Zr0rC; Sun, 3 Nov 2024 02:52:47 -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 28B02C1CAF34; Sun, 3 Nov 2024 02:52:47 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XhBGp6C5gz6K8rl; Sun, 3 Nov 2024 18:51:14 +0800 (CST)
Received: from lhrpeml100010.china.huawei.com (unknown [7.191.174.197]) by mail.maildlp.com (Postfix) with ESMTPS id 6B3491404F5; Sun, 3 Nov 2024 18:52:43 +0800 (CST)
Received: from kwepemd100010.china.huawei.com (7.221.188.107) by lhrpeml100010.china.huawei.com (7.191.174.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 3 Nov 2024 10:52:42 +0000
Received: from kwepemd500012.china.huawei.com (7.221.188.25) by kwepemd100010.china.huawei.com (7.221.188.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Sun, 3 Nov 2024 18:52:40 +0800
Received: from kwepemd500012.china.huawei.com ([7.221.188.25]) by kwepemd500012.china.huawei.com ([7.221.188.25]) with mapi id 15.02.1258.034; Sun, 3 Nov 2024 18:52:37 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] Revisiting NRP Selector
Thread-Index: AQHbGoPgGvaYlk4TE02d27L8xVi5krKgR0dQ
Date: Sun, 03 Nov 2024 10:52:37 +0000
Message-ID: <20f488b326c443ee825abc5280fde22f@huawei.com>
References: <CA+YzgTu9CKq7wMKkUhhDdZXTqvp+BHLvWeQmXa-PmeknA2VaNw@mail.gmail.com>
In-Reply-To: <CA+YzgTu9CKq7wMKkUhhDdZXTqvp+BHLvWeQmXa-PmeknA2VaNw@mail.gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.173.122]
Content-Type: multipart/alternative; boundary="_000_20f488b326c443ee825abc5280fde22fhuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: MYYWE7AZJWUKXVGX6N4XZGZQCDC35PKP
X-Message-ID-Hash: MYYWE7AZJWUKXVGX6N4XZGZQCDC35PKP
X-MailFrom: lana.wubo@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/1LiqkqZ24tPa8zhdkBdAK2SjXCw>
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>
Hi Pavan, Oscar, WG, I support the dedicated identifier field “NRP Data Plane ID”, and hope the WG consensus can be also reflected in the data plane sections of draft-ietf-teas-ns-ip-mpls-04 and draft-ietf-teas-nrp-scalability after an agreement is reached, so that the sections can be referenced in the draft of NRP YANG model. Here are my responses on the questions: · What do we call this dedicated identifier field? o “NRP Selector ID” and “NRP Data Plane ID” have been proposed so far. My preference is “NRP Data Plane ID”, because in the current NRP model, NRP selectors can be overloaded id (e.g. IP address, label, SID, ACL policy id, or dedicated identifier), then NRP selector id can refer to any of them, while “NRP Data Plane ID” can avoid confusion with the “NRP selector IDs”. · Length of the dedicated identifier field o Is it okay for this to be different for different data-plane types? o 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 Yes, as long as it fits the scenarios of NRP. § Please note that the actual data-plane specific encodings are outside the scope of the TEAS WG. · “Strict” match indicator o 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 Yes, it is useful to define a “Strict” match indicator to support a flexible per NRP forwarding policy that can be also consistent across all nodes of an NRP. o 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). Thanks, Bo From: Vishnu Pavan Beeram <vishnupavan@gmail.com> Sent: Thursday, October 10, 2024 3:45 AM To: TEAS WG <teas@ietf.org> Cc: TEAS WG Chairs <teas-chairs@ietf.org> Subject: [Teas] Revisiting NRP Selector 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? o “NRP Selector ID” and “NRP Data Plane ID” have been proposed so far. · Length of the dedicated identifier field o Is it okay for this to be different for different data-plane types? o 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. · “Strict” match indicator o 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 o 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). 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)