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

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

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

>

>

>

>