[bess] [BESS] Discussions on modulus-based DF Alg with AC-DF=1

<wang.yubao2@zte.com.cn> Fri, 12 April 2019 06:33 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 ABC1112012B for <bess@ietfa.amsl.com>; Thu, 11 Apr 2019 23:33:20 -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 VHDHuu-SiI07 for <bess@ietfa.amsl.com>; Thu, 11 Apr 2019 23:33:17 -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 4B5B0120043 for <bess@ietf.org>; Thu, 11 Apr 2019 23:33:16 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id E9DCE37AF90F1E70CC2A for <bess@ietf.org>; Fri, 12 Apr 2019 14:33:14 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id D5C49834A8FEBA0B92E7; Fri, 12 Apr 2019 14:33:14 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse02.zte.com.cn with SMTP id x3C6X38b034412; Fri, 12 Apr 2019 14:33:03 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Fri, 12 Apr 2019 14:33:05 +0800 (CST)
Date: Fri, 12 Apr 2019 14:33:05 +0800
X-Zmail-TransId: 2afd5cb031211535f51d
X-Mailer: Zmail v1.0
Message-ID: <201904121433057141340@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: mse02.zte.com.cn x3C6X38b034412
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/8J8KtS3kG4njjb1Ib0Snrr3m-B8>
Subject: [bess] [BESS] Discussions on modulus-based DF Alg with AC-DF=1
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: Fri, 12 Apr 2019 06:33:21 -0000

Hi Jorge,





I am not sure about my understanding about modulus-based DF Alg with AC-DF=1.


I think the modulus is per VLAN basis in the usecase, which means that each VLAN has an independent modulus and an independent candidate list.


Is that right?






It is described in draft-ietf-bess-evpn-df-election-framework-08 section 5 as follows:





   o The candidate list is pruned based upon non-receipt of Ethernet A-D    

     routes: a PE's IP address MUST be removed from the ES candidate

     list if its Ethernet A-D per ES route is withdrawn. A PE's IP

     address MUST NOT be considered as candidate DF for a <ES, Ethernet     

     Tag>, if its Ethernet A-D per EVI route for the <ES, Ethernet Tag>          

     is withdrawn.






I think the phrase "MUST NOT be considered as candidate DF" means that each VLAN has an independent candidate list.


And each PE is given independent ordinal for each VLAN's candidate list.


for example,


An ESI is adjacent to PE1, PE2, PE3, and PE1 has the lowest ORIP, PE3 has the highest ORIP.


The PE3 may be given the ordinal 1 for VLAN 5 , and 2 for VLAN 7,



because the VLAN 5 on PE2 is not UP, but the VLAN 7 on every PE is UP.


So the candidate list for VLAN 5 is {PE1, PE3}, and for VLAN 7 is {PE1, PE2, PE3}.


The DF for VLAN 5 is 5%2(=1=PE3), and for VLAN 7 is 7%3(=1=PE2).






is that true?






If it's true, then why we don't use only EAD-EVI route to form the candidate list in this usecase?


Because I think if the EAD-EVI route from PEx exists, typically we can assume that the EAD-ES route and ES route also exists.


I think we can use OPE TLV in the EAD-EVI route to order that candidate list. 


It seemed simpler than current method.