Tony In IDR their is an BGP Auto config design team.
Does this auto EVPN used by Rift separate effort from IDR DT below: 1. BGP Autoconf Design Team Report (15 mins) https://tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/ Kind Regards Gyan On Fri, Mar 12, 2021 at 3:06 AM Antoni Przygienda <prz= 40juniper....@dmarc.ietf.org> wrote: > Sandy, if you want to see it that way, yepp, you can think of one of the > things AUTO EVPN does as “BGP peer auto-configuration”. This is however > just a small part of the overall and really just kind of “necessary > byproduct”, especially since the sessions to RR can go multi-hop so even > with bgp single-hop discovery BGP couldn’t figure it out itself. (Yes, > there was work done previously for RR autodiscovery in IGP AFAIR, I don’t > think I ever saw it deployed). > > > > --- tony > > > > > > *From: *"zhang.zh...@zte.com.cn" <zhang.zh...@zte.com.cn> > *Date: *Friday, 12 March 2021 at 05:01 > *To: *Antoni Przygienda <p...@juniper.net>, Jordan Head <jh...@juniper.net>, > Wen Lin <w...@juniper.net> > *Cc: *"r...@ietf.org" <r...@ietf.org>, "bess@ietf.org" <bess@ietf.org> > *Subject: *Re:[Rift] comments on draft-head-rift-auto-evpn-00 > > > > *[External Email. Be cautious of content]* > > > > 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 > > > > Juniper Business Use Only > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
