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 <jefftant.i...@gmail.com> Date: Sunday, 14 March 2021 at 19:51 To: Gyan Mishra <hayabusa...@gmail.com> Cc: Antoni Przygienda <p...@juniper.net>, "r...@ietf.org" <r...@ietf.org>, "ext-zhang.zh...@zte.com.cn" <zhang.zh...@zte.com.cn>, "bess@ietf.org" <bess@ietf.org>, Wen Lin <w...@juniper.net>, Jordan Head <jh...@juniper.net> 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 <hayabusa...@gmail.com> 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=40juniper....@dmarc.ietf.org<mailto: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<mailto:zhang.zh...@zte.com.cn>" <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>> Date: Friday, 12 March 2021 at 05:01 To: Antoni Przygienda <p...@juniper.net<mailto:p...@juniper.net>>, Jordan Head <jh...@juniper.net<mailto:jh...@juniper.net>>, Wen Lin <w...@juniper.net<mailto:w...@juniper.net>> Cc: "r...@ietf.org<mailto:r...@ietf.org>" <r...@ietf.org<mailto:r...@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto: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<mailto:r...@ietf.org>;bess@ietf.org<mailto: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<mailto:zhang.zh...@zte.com.cn>" <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>> Date: Wednesday, 10 March 2021 at 16:31 To: Antoni Przygienda <p...@juniper.net<mailto:p...@juniper.net>>, Jordan Head <jh...@juniper.net<mailto:jh...@juniper.net>>, Wen Lin <w...@juniper.net<mailto:w...@juniper.net>> Cc: "r...@ietf.org<mailto:r...@ietf.org>" <r...@ietf.org<mailto: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<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Uw8Yz8Ov5eX7PEcvbfAUiGCWHBYNdsMkmwG10bI0xeDOxYRGYhQD_vHQ83tH2g$> -- [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 Silver Spring, MD _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
