[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
- [bess] Some questions about PBB EVPN (RFC7623) wang.yubao2
- Re: [bess] [ALU] Some questions about PBB EVPN (R… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] [ALU] Some questions about PBB EVPN (R… wang.yubao2
- Re: [bess] [ALU] Some questions about PBB EVPN (R… Rabadan, Jorge (Nokia - US/Mountain View)