Hi,
Not sure what you are not sure about :-)
In single-active you shouldn’t have bum traffic from the NDF AC to the DF AC,
hence split-horizon filtering is not necessary.
And you can minimize those in-flight packets, depending on the DF Election
implementation and switchover.
Thx
Jorge
From: "wang.yub...@zte.com.cn" <wang.yub...@zte.com.cn>
Date: Friday, April 12, 2019 at 3:22 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] [ALU] Some questions about PBB EVPN (RFC7623)
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.raba...@nokia.com> wrote:
> From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
> To: "wang.yub...@zte.com.cn" <wang.yub...@zte.com.cn>, "bess@ietf.org"
> <bess@ietf.org>, "saja...@cisco.com" <saja...@cisco.com>,
> "ais...@juniper.net" <ais...@juniper.net>, "Henderickx, Wim (Nokia -
> BE/Antwerp)" <wim.henderi...@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-boun...@ietf.org> on behalf of "wang.yub...@zte.com.cn"
> <wang.yub...@zte.com.cn>
> Date: Wednesday, April 10, 2019 at 12:04 PM
> To: "bess@ietf.org" <bess@ietf.org>, "saja...@cisco.com" <saja...@cisco.com>,
> "ais...@juniper.net" <ais...@juniper.net>, "Henderickx, Wim (Nokia -
> BE/Antwerp)" <wim.henderi...@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.yub...@zte.com.cn>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
