Re: [bess] [ALU] Some questions about PBB EVPN (RFC7623)
<wang.yubao2@zte.com.cn> Fri, 12 April 2019 01:22 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 6268F1200A0 for <bess@ietfa.amsl.com>; Thu, 11 Apr 2019 18:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 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, 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 Pww-BKOhASOc for <bess@ietfa.amsl.com>; Thu, 11 Apr 2019 18:22:22 -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 80B2012006E for <bess@ietf.org>; Thu, 11 Apr 2019 18:22:22 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 542DBEDD28A515F87081 for <bess@ietf.org>; Fri, 12 Apr 2019 09:22:20 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 3C2A1AE52914E62AA154; Fri, 12 Apr 2019 09:22:20 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse01.zte.com.cn with SMTP id x3C1MIxs016867; Fri, 12 Apr 2019 09:22:18 +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 09:22:18 +0800 (CST)
Date: Fri, 12 Apr 2019 09:22:18 +0800
X-Zmail-TransId: 2afd5cafe84ab2337015
X-Mailer: Zmail v1.0
Message-ID: <201904120922188283722@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: mse01.zte.com.cn x3C1MIxs016867
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/_UKBar9dZjeWqWTdzrxIVnB_bjI>
Subject: Re: [bess] [ALU] 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: Fri, 12 Apr 2019 01:22:26 -0000
Hi Jorge, Thank you very much for your help. I am still not sure about my understanding about Question 2. Please see if my understanding is correct. > 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)? > > ------------------ > [JORGE] Per-ISID load balancing means single-active MH. And for single-active Split-horizon filtering is not strictly necessary (it only helps for in-flight packets upon switchover). For all-active MH you rely on the same source BMAC on the PEs attached to the same ES. > ------------------ [Bob] In single-active mode, DF filtering is applied to both segment-to-core and core-to-segment directions. So the ESI filtering is not necessary except for the temporary period upon DF switchover. And the in-flight packets upon DF switchover will do little harm to the EVPN service, So the temporary loop in a ESI upon DF switchover can be ignored in practice. And it is typically ignored in the industry indeed. Is it right? Best Regards Bob On Thu, 11 Apr 2019 07:47:21 +0000 "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> wrote: > From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> > To: "wang.yubao2@zte.com.cn" <wang.yubao2@zte.com.cn>, "bess@ietf.org" <bess@ietf.org>, "sajassi@cisco.com" <sajassi@cisco.com>, "aisaac@juniper.net" <aisaac@juniper.net>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> > Subject: Re: [bess] [ALU] Some questions about PBB EVPN (RFC7623) > Date: Thu, 11 Apr 2019 07:47:21 +0000 > > Hi Bob, > > Please see in-line with [JORGE]. > Hope it helps. > > Thx > Jorge > > > From: BESS <bess-bounces@ietf.org> on behalf of "wang.yubao2@zte.com.cn" <wang.yubao2@zte.com.cn> > Date: Wednesday, April 10, 2019 at 12:04 PM > To: "bess@ietf.org" <bess@ietf.org>, "sajassi@cisco.com" <sajassi@cisco.com>, "aisaac@juniper.net" <aisaac@juniper.net>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> > Subject: [ALU] [bess] Some questions about PBB EVPN (RFC7623) > > > 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? > > ------------------ > [JORGE] Yes. Note that it's not only the fact that you can't withdraw the BMAC, but also you can't withdraw the ES route, which means there is no DF reelection for the ISID assigned to the sub-interface. The solution to this is to use a virtual ES (draft-ietf-bess-evpn-virtual-eth-segment) per sub-interface. > Yet, if you have multiple sub-interfaces in the same ES, and an individual one fails, you will have those two issues: no DF reelection and no notification to the remote PEs. > NOTE: back in 2015 we introduced the concept of A-D per-ISID routes (draft-rabadan-bess-evpn-ac-df-02) to solve this, but had not much support in the WG and we gave up, focusing only on solving the AC-influenced DF election issue for EVPN. > NOTE2: for single-active, you can use different ESes and draft-snr-bess-pbb-evpn-isid-cmacflush. That would also solve the individual AC failure. > ------------------ > > 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)? > > ------------------ > [JORGE] Per-ISID load balancing means single-active MH. And for single-active Split-horizon filtering is not strictly necessary (it only helps for in-flight packets upon switchover). For all-active MH you rely on the same source BMAC on the PEs attached to the same ES. > ------------------ > > 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? > ------------------ > [JORGE] Technically is possible, however I haven't seen the need for that use-case yet. If you need IP tunnels in the B-component you can use MPLSoGRE or MPLSoUDP, and you are still compliant with RFC7623. > ------------------ > > > 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? > ------------------ > [JORGE] Note that in PBB-EVPN only the BMACs are involved in the control plane, and all the customer frames are encapsulated in PBB, so you lose the IP "visibility" that you have in EVPN. If you need IRB, I would say use EVPN and not PBB-EVPN. EVPN IRB solves pretty much all the use-cases we see in the industry today IMHO. > ------------------ > > I haven't find clear explanation about these questions. > Is there something important I have missed? > > Best Regards > Bob > > > > > -- Wang Yubao <wang.yubao2@zte.com.cn>
- [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)