Thanks Jeff! Gyan
On Sun, Mar 14, 2021 at 2:50 PM Jeff Tantsura <[email protected]> wrote: > Hi Gyan, > > It doesn’t and has a very different purpose. > BGP work in IDR is meant to facilitate bringing up BGP peering > session(discovery/config/etc). > RIFT work is specifically for fabrics that run RIFT as the underlay > routing protocol and wish to use EVPN for overlay. Auto-evpn facilities > bringing up BGP sessions with EVPN AFI/SAFI as well as auto deriving EVPN > attributes, such as EVIs,VRFs, IRB/SVIs and so forth. > > > Regards, > Jeff > > On Mar 13, 2021, at 16:12, Gyan Mishra <[email protected]> wrote: > > > > > 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= > [email protected]> 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: *"[email protected]" <[email protected]> >> *Date: *Friday, 12 March 2021 at 05:01 >> *To: *Antoni Przygienda <[email protected]>, Jordan Head <[email protected]>, >> Wen Lin <[email protected]> >> *Cc: *"[email protected]" <[email protected]>, "[email protected]" <[email protected]> >> *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; >> >> *抄送人：*[email protected];[email protected]; >> >> *日* *期* *：*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: *"[email protected]" <[email protected]> >> *Date: *Wednesday, 10 March 2021 at 16:31 >> *To: *Antoni Przygienda <[email protected]>, Jordan Head <[email protected]>, >> Wen Lin <[email protected]> >> *Cc: *"[email protected]" <[email protected]> >> *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > *Silver > Spring, MD > > _______________________________________________ > BESS mailing list > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
