Re: [Rift] comments on draft-head-rift-auto-evpn-00

[[e-mail]]

Hi Tony, 


Thank you for your response! It's interesting. 


So in some sense, the BGP auto discovery can be achieved by RIFT own way, in this situration, right? 


Please find more comments below with Sandy>.



Best regards,


Sandy



原始邮件



发件人：AntoniPrzygienda
收件人：张征00007940;Jordan Head;Wen Lin;
抄送人：[e-mail];[e-mail];
日 期 ：2021年03月10日 23:45
主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




Hey Sandy, yes, all sessions come up automatically


 


Yes, all the data is derived automatically just from the today’s RIFT database on the leaf or ToF (no key value necessary or any new TIEs, just topology info we have today already)


Sandy> Most of the info is topology info, but some may not, such as AS number. But I agree with you, it can be a small option to be added in the existed TIE or a new TIE.






There is _NO_ information about ToF in the leaves, e’thing is scaling just like RIFT does today


Sandy> I have a question, If ToF is RR, does it need to establish BGP peering with leaf nodes?


 


KV 😉 will be just optional for telemetry in case that’s desired & will flow northbound only so no change in scaling properties.


Sandy> OK. I understand.


 


In short:


 


RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  assumes a special RR loopback with last byte representing its preference


 


X::[pref]


 


Every leaf tries to connect to


 


X::1


X::2


X::3


 


Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable constant)


 


Each leaf elects own loopback in a well known range


Sandy> It's a reasonable design. For multiple RIFT instances, if multiple EVPN overlays can be built? Will they use the same well know range loopback address?


 


Y/64 :: something


 


On each RR any connection attempt from Y/64:: something is accepted (pretty much all mature implemenations today support that). If you want to be fastidious you could actually on the ToF that is RR (since it sees all node N-TIEs) even specify each leaf as allowed peer


Sandy> Do you mean the RR (ToF) is optional, leaf nodes can build BGP peering straightly?


 


All took a bit to figure out and my first input to the idea when brought to me was “well, of course it’s impossible to ZTP EVPN, even with RIFT” 😉 But, with enough grey matter grease it actually works pretty well from all we see …


 


It will all become more concrete when we flesh the algorithm appendix albeit the description today already gives a pretty good idea but without standardized algorithms for the distributed elections interoperability cannot be guaranteed …


Sandy> Sound great. Looking forward to looking at it.


 


--- tony


 



From: "[e-mail]" <[e-mail]>
 Date: Wednesday, 10 March 2021 at 16:31
 To: Antoni Przygienda <[e-mail]>, Jordan Head <[e-mail]>, Wen Lin <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>
 Subject: [Rift] comments on draft-head-rift-auto-evpn-00



 


[External Email. Be cautious of content]


 

Hi Tony, co-author, 

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the detail. :-P

From the draft, seems like the leaf node will build BGP connection automatically, and exchange the necessary MAC/IP through EVPN advertisement. 

But does the info on leaf for BGP building (AS, router-id, etc.) derived from the leaf node itself? If it is, the BGP auto discovery function is included in (That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has no relationship with BGP auto discovery, IMO necessary sourcebound KVs are needed. But I am not sure because I have not seen explicit description in the draft. 

Best regards,

Sandy

 

 





 
Juniper Business Use Only