I agree with you with that it is literally clear in RFC7432.
So the DF timer in RFC7432 and draft-ietf-bess-evpn-df-election-framework is
the same timer,
And it's only used to collect the remote routes for the same ES (but delay the
usage of them) ,
So the timer is not used in the following usecase:
1）the ES goes down on PE1, but the PE1 node itself works well.
2）so the remote routes（assumed that they are from PE2,PE3) for the same ES need
not to be collected again.
3）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, and the new DF may
be PE1 itself.
5）But PE1 doesn't take itself as the new DF of VLAN x. so the VLAN x doesn't
has a DF untill the DF_TIMER event.
But I think it will be better to use a timer in above usecase to delay the
advertisment of ES route after ES_UP event.
Now I think may be they are different timers.
If they are different timers I think it should be clearly described
that the RFC7432 DF timer is used only on the first ES UP (the ES UP on PE
UP),
not used on the ordinary ES_UP (the ES UP after first ES UP).
I think the first ES UP is not quite the same as the ordinary ES UP.
May be they have different requirements on the DF election FSM.
Thx
Bob
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView) <jorge.raba...@nokia.com>
收件人：王玉保10045807;
抄送人：bess@ietf.org <bess@ietf.org>;saja...@cisco.com
<saja...@cisco.com>;jdr...@juniper.net <jdr...@juniper.net>;
日 期 ：2019年04月14日 05:58
主 题 ：Re: [BESS] Discussions about DF-election FSM.
The DF Election framework draft does not change that aspect of RFC7432. The ES
route is advertised when the ES goes up, and the timer allows some time to
collect the other routes for the same ES. IMHO RFC7432 is pretty clear about
that...
Thx
Jorge
From: "wang.yub...@zte.com.cn" <wang.yub...@zte.com.cn>
Date: Friday, April 12, 2019 at 5:19 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
Cc: "bess@ietf.org" <bess@ietf.org>, "saja...@cisco.com" <saja...@cisco.com>,
"jdr...@juniper.net" <jdr...@juniper.net>
Subject: [BESS] Discussions about DF-election FSM.
Hi Jorge,
I read the draft-ietf-bess-evpn-df-election-framework-08 and find it seemed not
clear in the DF election FSM .
I didn't find clear explanation about when to advertise the ES route(RT-4)
according to the FSM.
I think it is the DF_TIMER (not ES_UP) event that triggers the advertising of
ES route.
Because if not the remote PEs will re-elect a new DF immediately after the
advertisment, and the new DF may be the PE in DF_WAIT state itself.
but I didn't find clear explanation in the relevant event transmissions.
The description in draft-ietf-bess-evpn-df-election-framework-08 section 3.1 as
follows:
2. INIT on ES_UP: transition to DF_WAIT.
... ...
6. DF_WAIT on DF_TIMER: transition to DF_CALC.
7. DF_CALC on entering or re-entering the state: (i) rebuild
candidate list, hash and perform election (ii) Afterwards FSM
generates CALCULATED event against itself.
And I find in RFC7432 Section 8.5 that the advertising of ES route is not
influenced by the DF_TIMER.
1. When a PE discovers the ESI of the attached Ethernet segment, it
advertises an Ethernet Segment route with the associated ES-Import
extended community attribute.
2. The PE then starts a timer (default value = 3 seconds) to allow
the reception of Ethernet Segment routes from other PE nodes
connected to the same Ethernet segment. This timer value should
be the same across all PEs connected to the same Ethernet segment.
So I think there is an update of RFC7432 and it needs to be clear described in
the draft.
or the DF timer in RFC7432 is not the same with the DF timer in that draft?
Is my understanding right?
Best Regards
Bob_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
