[bess] Are data plane connectivity checks required for SRv6 EVPN just like MPLS(RFC9489)?
liu.yao71@zte.com.cn Thu, 21 March 2024 01:30 UTC
Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C1FC14F6BF for <bess@ietfa.amsl.com>; Wed, 20 Mar 2024 18:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 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, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, 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 IDOCsJfGwjQl for <bess@ietfa.amsl.com>; Wed, 20 Mar 2024 18:30:33 -0700 (PDT)
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 AC58EC14F6B5 for <bess@ietf.org>; Wed, 20 Mar 2024 18:30:30 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (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 4V0SZW3ZYQz4xPYZ for <bess@ietf.org>; Thu, 21 Mar 2024 09:30:27 +0800 (CST)
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 mxct.zte.com.cn (FangMail) with ESMTPS id 4V0SYv58z6z4xfxM; Thu, 21 Mar 2024 09:29:55 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 42L1TNqG051707; Thu, 21 Mar 2024 09:29:29 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid203; Thu, 21 Mar 2024 09:29:30 +0800 (CST)
Date: Thu, 21 Mar 2024 09:29:30 +0800
X-Zmail-TransId: 2afd65fb8d7a093-524c4
X-Mailer: Zmail v1.0
Message-ID: <202403210929305696029@zte.com.cn>
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: bess@ietf.org
Cc: matthew.bocci@nokia.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 42L1TNqG051707
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65FB8DB3.000/4V0SZW3ZYQz4xPYZ
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/NTS6OG645NB_hmXHROnm5c2gnPw>
Subject: [bess] Are data plane connectivity checks required for SRv6 EVPN just like MPLS(RFC9489)?
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 01:30:38 -0000
Hi BESS， RFC9489 in BESS proposes the data plane connectivity check mechanism for MPLS EVPN/PBB-EVPN using MPLS lspping. As we know, now there're EVPN services based SRv6 as well. Do you see the requirement for data plane connectivity check in SRv6 EVPN as well? We have a draft (https://datatracker.ietf.org/doc/draft-liu-6man-icmp-verification/) that tends to fulfill such dataplane validation requirements in SRv6 by defining MPLS lspping-like mechanism using ICMPv6. It has been presented in MPLS session on Tuesday, and thanks for Matthew's comments and mentioning the MPLS work in RFC9489 in BESS. So we brings our draft here to see if there's any requirement, and we tend to add the SRv6 EVPN validation part(currently there's only L3 VPN) in the future. Any comments and suggestions are more than welcome! Thanks, Yao