Re: [bess] An use-case that RFC 8584 (EVPN DF Framework) works not so well and its solution .

[<[e-mail]>]

Hi Jorge,






Thank you for your helpful response.





I checked the three DF Alg and find it seemed to be not well resolved yet:

the HRW Alg describe in RFC8584 only helps when the new inserted PE will not be the Highest Weight for an specified VLAN.

the Preference based Alg just select the two (the highest and the lowest) of many ES-adjacent-PEs as DF for all Ethernet tags.

the handshake HRW Alg using two new NLRIs to send temporary signalling, and the two new NLRIs is never withdrawn after being used.








I think the NLRI concept would be considered as steady forwarding information by convention rather than temporary throwaway message.


Even if we use an NLRI to send an throwaway message, we should withdraw it after it is no use.


I guess it will remain there if we don't withdraw it.


But if we add the withdrawing procedures in the handshake HRW Alg, I think it will be too complicated.



So I think it is necessary to be clearly described that the DF Request/Response is only kept in the memory for a temporary time before it is throw away.


I think the IGMP Join/Leave route can be taken as an example on the withdrawing procedures. 






Glad to see your view of these issues.







And I think the [DF Fast Recovery] is designed under the principle that we would rather accept a temporary state without any DF than accept a temporary state with two DFs.


Is my understanding correct?







Thanks,


Bob











原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView) <[e-mail]>
收件人：王玉保10045807;[e-mail] <[e-mail]>;
日 期 ：2019年05月02日 19:43
主 题 ：Re: [bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .


_______________________________________________
BESS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bess

  

Hi Bob,


 


Here is my two cents:


 

The FSM in RFC8584 is not new and has many implementations by now. I would recommend to stay with it.

The timer is generic and gives some room to collect ES routes. You may already have the routes in the PE in your case, but if the  node boots and comes up still need to gather them from the RR or the remote PEs.

The issue that you describe about a third PE taking over can be solved in different ways. For instance:

You can check the HRW Alg describe in RFC8584 that helps in many cases.

You can also check the non-revertive capability along with the Preference based Alg in the DF preference draft.

Or the handshake Alg in the fast df recovery draft


 


Thanks.


Jorge


 



From: "[e-mail]" <[e-mail]>
 Date: Tuesday, April 30, 2019 at 5:02 AM
 To: "[e-mail]" <[e-mail]>
 Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>
 Subject:  [bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .



 


 


Hi everyone,


 


I reviewed the draft-09 of RFC 8584 a few days ago, and found that the DF Election FSM can't work well after the ES goes UP for the second time.


I described it in detail in this mail: https://mailarchive.ietf.org/arch/msg/bess/9fK2HHdish3b5Hosa5ZU4NKwX7o


And I think the issue remained in RFC 8584 unchanged. 


So I described the use-case more clearly here so that we can check that whether it is a misunderstanding or it is worth updating.  


 

0) the ES goes up on PE1 for the first time while the same ES has been DF_DONE on PE2/PE3 for a long time, the DF FSM per RFC8584 works well.
1）the ES goes down later, but the PE1 node itself still works well. Because the failure only occurs on the ES interface. 
2）so the remote routes（assumed that they are from PE2 and PE3) for the same ES need not to be collected again.  
3）the ES goes up again, PE1 advertises the ES route immediately after the ES_UP event. 
4）So PE1 makes PE2 and PE3 to re-elect a new DF for VLAN x immediately after its ES_UP event, and the new DF may be PE1 itself.  
5）But PE1 doesn't take itself as the new DF of VLAN x untill the DF_TIMER. so the VLAN x doesn't have a DF untill the DF_TIMER event.

I think the PE1 has to advertise the ES route on the DF_TIMER event from the moment of the second ES_UP on. 
And I think it is better for PE1 to advertise the ES route on the DF_TIMER event even for the first ES_UP.
Because since PE1 don't intend to take a DF responsibility in the collecting time, it is technically not necessary for it to make other PEs select itself as the DF.
So I suggest that the ES route should be advertised on the DF_TIMER event, not the ES_UP event. 

I think both RFC7432 and RFC8584 may need an update on the above use case.
I think the original use case for RFC7432/RFC8584's DF_WAIT state may be that all the adjacent PEs for an specified ESI are restarted on the same time.
In the original use case the ES routes should be advertised immediately after the ES_UP event because the collecting will not happen untill they advertise ES routes to each other.
But I think in the original use case the PEs technically can't be restarted on the exact same time,
and the interval among their restarting time may be more bigger than the transmission time of the ES route.
Note that the original use case will not happen so frequently than my above use case. 
So I think it is not quite fair to focus on the original use case and ignore the above use case. 

How do you think about the above use case and the solution? 
 


Best Regards,


Bob


 


On Wed, 24 Apr 2019 21:12:29 -0700 (PDT)


[e-mail] wrote:


 


> A new Request for Comments is now available in online RFC libraries.


> 


>         


>         RFC 8584


> 


>         Title:      Framework for Ethernet VPN Designated 


>                     Forwarder Election Extensibility 


>         Author:     J. Rabadan, Ed.,


>                     S. Mohanty, Ed.,


>                     A. Sajassi, 


>                     J. Drake,


>                     K. Nagaraj, 


>                     S. Sathappan


>         Status:     Standards Track


>         Stream:     IETF


>         Date:       April 2019


>         Mailbox:    [e-mail], 


>                     [e-mail], 


>                     [e-mail],  


>                     [e-mail], 


>                     [e-mail],  


>                     [e-mail]


>         Pages:      32


>         Characters: 69774


>         Updates:    RFC 7432


> 


>         I-D Tag:    draft-ietf-bess-evpn-df-election-framework-09.txt


> 


>         URL:        https://www.rfc-editor.org/info/rfc8584


> 


>         DOI:        10.17487/RFC8584


> 


> An alternative to the default Designated Forwarder (DF) selection


> algorithm in Ethernet VPNs (EVPNs) is defined.  The DF is the


> Provider Edge (PE) router responsible for sending Broadcast, Unknown


> Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge


> (CE) device on a given VLAN on a particular Ethernet Segment (ES).


> In addition, the ability to influence the DF election result for a


> VLAN based on the state of the associated Attachment Circuit (AC) is


> specified.  This document clarifies the DF election Finite State


> Machine in EVPN services.  Therefore, it updates the EVPN


> specification (RFC 7432).


> 


> This document is a product of the BGP Enabled Services Working Group of the IETF.


> 


> This is now a Proposed Standard.


> 


> STANDARDS TRACK: This document specifies an Internet Standards Track


> protocol for the Internet community, and requests discussion and suggestions


> for improvements.  Please refer to the current edition of the Official


> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 


> standardization state and status of this protocol.  Distribution of this 


> memo is unlimited.


> 


> This announcement is sent to the IETF-Announce and rfc-dist lists.


> To subscribe or unsubscribe, see


>   https://www.ietf.org/mailman/listinfo/ietf-announce


>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist


> 


> For searching the RFC series, see https://www.rfc-editor.org/search


> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk


> 


> Requests for special distribution should be addressed to either the


> author of the RFC in question, or to [e-mail].  Unless


> specifically noted otherwise on the RFC itself, all RFCs are for


> unlimited distribution.


> 


> 


> The RFC Editor Team


> Association Management Solutions, LLC


> 


> 


> 


>