[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

wang.yubao2@zte.com.cn Tue, 27 July 2021 22: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 B38B63A0B62 for <bess@ietfa.amsl.com>; Tue, 27 Jul 2021 15:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 pWg0rsyvN8oP for <bess@ietfa.amsl.com>; Tue, 27 Jul 2021 15:16:00 -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 4248B3A0B59 for <bess@ietf.org>; Tue, 27 Jul 2021 15:14:33 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 72E5646BC4C3FC995B4D for <bess@ietf.org>; Wed, 28 Jul 2021 06:14:30 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 592EF5DAC2AE1BEB3107; Wed, 28 Jul 2021 06:14:30 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 16RMER12030799; Wed, 28 Jul 2021 06:14:27 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Wed, 28 Jul 2021 06:14:27 +0800 (CST)
Date: Wed, 28 Jul 2021 06:14:27 +0800
X-Zmail-TransId: 2af961008543b8c8a535
X-Mailer: Zmail v1.0
Message-ID: <202107280614271841200@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: jorge.rabadan@nokia.com
Cc: bess@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 16RMER12030799
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ARNqX6a_lYSy-4XAfNOv1etc85o>
Subject: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02
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: Tue, 27 Jul 2021 22:16:05 -0000

Hi Jorge,






This is the detailed explanation of the question I asked in the IETF 111 meeting. 


In page 7 of slides-111-bess-sessa-evpn-ip-aliasing, when leaf-5 send traffic to leaf-2,  how does leaf-2 find the corresponding ARP entry for 20.0.0.2 or 20.0.0.1 or 20.1.1.3 ?


I guess the GW-IP 1.1.1.1 will be advertised as overlay index along with the ESI.



But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP Prefix Advertisement Route with both GW-IP and ESI both as overlay index.


I suggest that this should be updated if you want to do so.


And the preference of ESI overlay index should be considered higher than GW-IP overlay index for Leaf-5's sake.


But the preference of ESI overlay index should be considered lower than (or maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake


These are new rules that can't be found in draft-ietf-bess-evpn-prefix-advertisement-11 .






But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay index,


It can support the same protection procedures without any ESI overlay index.


( The details to do such protection using GW-IP overlay index I have described in draft-wang-bess-evpn-arp-nd-synch-without-irb-06. )


So I don't get the point why we need two redundant overlay index?


Can you clearify it?






Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.


And such Route Style is in compliance with  draft-ietf-bess-evpn-prefix-advertisement-11 already.






Another question is that: If the ESI overlay index is advertised, when will the IP A-D per EVI route of Leaf-2 be withdrawn?


When the IRB interface on Leaf-2 fails?


When one of the three ACs fails?


When all of the three ACs fails?


If you want to do so, I suggest that the ESI-1 to be configured onto the IRB interfaces,


But in Figure 2 of  draft-sajassi-bess-evpn-ip-aliasing-02, I see the ESI is configured on the ACs of the BDs.






Is anything I have misunderstood?






Best,


Yubao