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

Reply via email to