Understood. Thanks Tony. The draft is very detailed and well written.
Thanks Gyan On Mon, Mar 15, 2021 at 2:29 AM Antoni Przygienda <[email protected]> wrote: > As Jeff pointed out, the scope is very different. The design team is > focused on standardizing a solution given things that have been for a bit > in the wild to “auto-peer” BGP, a useful thing non-withstanding how > contrary to the original BGP design goals it was 😉 > > > > AUTO EVPN targets a different problem where auto-peering is kind of > understood implicitly from the underlay protocol plus lots other things. It > brings original L2 simplicity to L2 over L3 again. Based on RIFT (other > protocols are an open question but there are a lot of things needed for > that that RIFT already does natively) it provides a absolutely zero config > plug-and-play underlay and overlay EVPN bring-up of devices plugged > together to form an IP fabric (well, I’m lying, the top of fabric switches > in RIFT still need the knob for knowing they’re top-of-fabric). > > > > The draft outlines the architecture pretty well, we have the missing > algorithms figured out quite precisly by now and stuff works but we simply > didn’t have time for this IETF to fill them in or include the type-5 IRB > details either. Next rev … > > > > --- tony > > > > *From: *Jeff Tantsura <[email protected]> > *Date: *Sunday, 14 March 2021 at 19:51 > *To: *Gyan Mishra <[email protected]> > *Cc: *Antoni Przygienda <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, Wen Lin <[email protected]>, Jordan Head <[email protected] > > > *Subject: *Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00 > > > > *[External Email. Be cautious of content]* > > > > 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/ > <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!Uw8Yz8Ov5eX7PEcvbfAUiGCWHBYNdsMkmwG10bI0xeDOxYRGYhQD_vHcA0uGeQ$> > > > > 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 > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Uw8Yz8Ov5eX7PEcvbfAUiGCWHBYNdsMkmwG10bI0xeDOxYRGYhQD_vHQ83tH2g$> > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Uw8Yz8Ov5eX7PEcvbfAUiGCWHBYNdsMkmwG10bI0xeDOxYRGYhQD_vFie_t5WA$> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 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 > > > Juniper Business Use Only > -- <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
