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: "wang.yub...@zte.com.cn" <wang.yub...@zte.com.cn>
Date: Tuesday, April 30, 2019 at 5:02 AM
To: "bess@ietf.org" <bess@ietf.org>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
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)
rfc-edi...@rfc-editor.org 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: jorge.raba...@nokia.com,
> satya...@cisco.com,
> saja...@cisco.com,
> jdr...@juniper.net,
> kiran.naga...@nokia.com,
> senthil.sathap...@nokia.com
> 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 rfc-edi...@rfc-editor.org. Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
