[bess] Some questions about PBB EVPN (RFC7623)

<wang.yubao2@zte.com.cn> Wed, 10 April 2019 10:04 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 277861201DB for <bess@ietfa.amsl.com>; Wed, 10 Apr 2019 03:04:27 -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 OeGi4zQdJmJA for <bess@ietfa.amsl.com>; Wed, 10 Apr 2019 03:04:25 -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 27DCC1200E6 for <bess@ietf.org>; Wed, 10 Apr 2019 03:04:24 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 2F7DCF84D87168C06193; Wed, 10 Apr 2019 18:04:23 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id E879C2255BF7FCEB2723; Wed, 10 Apr 2019 18:04:22 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse01.zte.com.cn with SMTP id x3AA3Cnj052125; Wed, 10 Apr 2019 18:03:12 +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 18:03:14 +0800 (CST)
Date: Wed, 10 Apr 2019 18:03:14 +0800
X-Zmail-TransId: 2afb5cadbf6293c15d5f
X-Mailer: Zmail v1.0
Message-ID: <201904101803141598751@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: bess@ietf.org, sajassi@cisco.com, aisaac@juniper.net, wim.henderickx@alcatel-lucent.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse01.zte.com.cn x3AA3Cnj052125
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/BlHjWbPfb-5o1Au-Z42om60A11M>
Subject: [bess] Some questions about PBB EVPN (RFC7623)
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 10:04:27 -0000

Hi all,






I have some questions about PBB EVPN.


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


I need some help to check my understanding.






Question 1:


The ESI and B-MAC is assigned to a LAG interface or physical interface, 


but it's their sub-interfaces that actually attaches a MAC-VRF instance.


So when the sub-interface fails and it's main-interface is still operational,


The B-MAC for ESI is not withdrawn, and remote PE will continue to load-balance traffic to the sub-interface.


So all the packet toward the failed sub-interface is drop?


Is this what the RFC 7623 expects?






Question 2:






RFC 7623 6.2.2.1. says that:





      In the case where per-I-SID load-balancing is desired among the PE

   nodes in a given redundancy group, multiple unicast B-MAC addresses      

   are allocated per multihomed ES: Each PE connected to the multihomed     

   segment is assigned a unique B-MAC.  Every PE then advertises its        

   B-MAC address using the BGP MAC Advertisement route.  






It means that the ESI B-MAC on the ESI's adjacent PEs is different from each other.


So how can we do ESI filter by B-MAC comparison(which is discribed in 6.2.1.3)?






Question 3:






The B-Component of PBB EVPN is assumed to be a MPLS EVPN MAC-VRF in RFC7623,


But technically we can use a VXLAN EVPN MAC-VRF instead, 


Does it make sense? 


Or I don't need to consider this usecase at all?






Question 4:






We have EVPN IRB usecases in MPLS/VXLAN EVPN,


But I don't see there is a EVPN IRB usecase in PBB EVPN from the EVPN IRB drafts.


So, is this usecase useless?  or will it be considered in the future?










I haven't find clear explanation about these questions. 



Is there something important I have missed?






Best Regards


Bob