Re: [bess] [BESS] Discussions about DF-election FSM.

[<[e-mail]>]

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) <[e-mail]>
收件人：王玉保10045807;
抄送人：[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
日 期 ：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: "[e-mail]" <[e-mail]>
 Date: Friday, April 12, 2019 at 5:19 AM
 To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
 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