Re: [bess] [ALU] Some questions about PBB EVPN (RFC7623)

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

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: "[e-mail]" <[e-mail]>
Date: Friday, April 12, 2019 at 3:22 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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)" <[e-mail]> wrote:



> From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>

> To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>

> 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 <[e-mail]> on behalf of "[e-mail]" <[e-mail]>

> Date: Wednesday, April 10, 2019 at 12:04 PM

> To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>

> 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 <[e-mail]>