[mpls] Request feedback/comments on draft-liu-6man-icmp-verification

liu.yao71@zte.com.cn Tue, 05 March 2024 03:08 UTC

Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1B1C14F60F for <mpls@ietfa.amsl.com>; Mon, 4 Mar 2024 19:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.727
X-Spam-Level: *
X-Spam-Status: No, score=1.727 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_PHISH=3.629] 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 VpuYjsAEciu1 for <mpls@ietfa.amsl.com>; Mon, 4 Mar 2024 19:08:22 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90EFC14F605 for <mpls@ietf.org>; Mon, 4 Mar 2024 19:08:20 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4TpgVp213zz4xPG4 for <mpls@ietf.org>; Tue, 5 Mar 2024 11:08:18 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 425388QZ038716 for <mpls@ietf.org>; Tue, 5 Mar 2024 11:08:08 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njb2app07[null]) by mapi (Zmail) with MAPI id mid203; Tue, 5 Mar 2024 11:08:09 +0800 (CST)
Date: Tue, 05 Mar 2024 11:08:09 +0800
X-Zmail-TransId: 2aff65e68c995fa-8aa7a
X-Mailer: Zmail v1.0
Message-ID: <202403051108098311462@zte.com.cn>
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: mpls@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 425388QZ038716
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65E68CA2.000/4TpgVp213zz4xPG4
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-YlmE-AdIEfsWSPrV-ks9_j62ps>
Subject: [mpls] Request feedback/comments on draft-liu-6man-icmp-verification
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 03:08:24 -0000

Hi MPLS,

As we know, SR SIDs can be related with more and more extra information, but unlike FEC validation in MPLS lspping, there's no mechanism to verify the data plane against the control plane for SRv6. This draft proposes extensions to ICMPv6 to achieve similar functions in SRv6 like FEC validation in MPLS lspping.

After the draft being presented in SPRING last IETF, we're suggested to look for suggestions and guidance from MPLS experts.
A main concern we've received last time is that, for lspping fec validation, when a new type of FEC information is related with the MPLS label, a new FEC sub-TLV is introduced, and the LSRs need to be upgraded to support the new FEC sub-TLVs if you want to do validation, which makes it not very implementation friendly, and introducing similar mechanisms in SRv6 may lead to similar problems.

And another key point is above the real requirement/usecase. A feedback we got is that although lspping in widely used in MPLS, but FEC validation function is rarely used because the requirement to verify the data plane against the control plane by sending and receiving messages on the data plane is not that strong, and there're other north-south bound mechanisms to achieve the similar function.

The draft can be found at https://datatracker.ietf.org/doc/html/draft-liu-6man-icmp-verification-04
Any interest, feedback or comments on this topic are more than welcome. 

Thanks,
Yao