[bess] Discussions on ARP sync by RT-2 in pure L3 EVPN usecases

<wang.yubao2@zte.com.cn> Wed, 10 April 2019 09:16 UTC

Return-Path: <wang.yubao2@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 AED8B1200A3 for <bess@ietfa.amsl.com>; Wed, 10 Apr 2019 02:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AdyI1cMSjQoX for <bess@ietfa.amsl.com>; Wed, 10 Apr 2019 02:16:08 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C5D12004D for <bess@ietf.org>; Wed, 10 Apr 2019 02:16:07 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id D5BC7251D10E1CC9EFC2 for <bess@ietf.org>; Wed, 10 Apr 2019 17:16:05 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id C13D3CF009616742DC4B; Wed, 10 Apr 2019 17:16:05 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse01.zte.com.cn with SMTP id x3A9Fg3G075585; Wed, 10 Apr 2019 17:15:42 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 10 Apr 2019 17:15:43 +0800 (CST)
Date: Wed, 10 Apr 2019 17:15:43 +0800
X-Zmail-TransId: 2afb5cadb43fafed3f62
X-Mailer: Zmail v1.0
Message-ID: <201904101715436907148@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: bess@ietf.org, sajassi@cisco.com, spasupula@cisco.com, gbadoni@cisco.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse01.zte.com.cn x3A9Fg3G075585
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/v8Umn5gcrZ_hZXJjGMVRWPG6Q18>
Subject: [bess] Discussions on ARP sync by RT-2 in pure L3 EVPN usecases
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Apr 2019 09:16:11 -0000

Hi all,


I have some questions about using RT-2 in pure L3 EVPN usecases.


I haven't find clear explanation in current EVPN RFCs or drafts on these usecases.


I need some help to check my understanding.


Can you help me to check whether this usecase is supported by current EVPN control-plane or not ?


The phrase "pure L3 EVPN usecases" means that there is no IRB or MAC-VRF.





   /---- PE1----\

CE1(ES1)        PE3----CE2

   \---- PE2----/

   


CE1 attaches to IP-VRF x via sub-interface a/b on PE1/PE2.


And I think we can use RT-2 to sync ARP entries between sub-interface a and b.


In order to do this, I configured ESI1 on the main-interface of a and b.


Then I let the EVPN control-plane advertise the ARP entries on a/b to all EVPN PEs using EVPN Route-type 2.


I think the format of such RT-2 routes can be the following:


1) the MPLS label1 field is null (may be implicit-null or explicit-null),because there is no MAC-VRF.


2) the MPLS label2 field is the label of IP-VRF x


3) the RD field is the RD of IP-VRF x


4) the ESI is ESI1, the ETI is 0 


5) the RTs is the export RTs of IP-VRF x 






I also think we can advertise the subnet of sub-interface a/b together with ESI1 in EVPN RT-5 route.


And I haven't find clear explanation about the detailed usage of EVPN RT-5 route with ESI field as active forwarding information. 






Is my understanding right? or Is there something important I have missed?






Best Regards


Bob