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;
抄送人：r...@ietf.org;bess@ietf.org;
日 期 ：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: "zhang.zh...@zte.com.cn" <zhang.zh...@zte.com.cn>
Date: Wednesday, 10 March 2021 at 16:31
To: Antoni Przygienda <p...@juniper.net>, Jordan Head <jh...@juniper.net>, Wen
Lin <w...@juniper.net>
Cc: "r...@ietf.org" <r...@ietf.org>
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
