Re: [Rift] [bess] comments on draft-head-rift-auto-evpn-00

[Gyan Mishra <[e-mail]>]

Understood.  Thanks Tony.

The draft is very detailed and well written.

Thanks

Gyan

On Mon, Mar 15, 2021 at 2:29 AM Antoni Przygienda <[e-mail]> 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 <[e-mail]>
> *Date: *Sunday, 14 March 2021 at 19:51
> *To: *Gyan Mishra <[e-mail]>
> *Cc: *Antoni Przygienda <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, Wen Lin <[e-mail]>, Jordan Head <[e-mail]
> >
> *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 <[e-mail]> 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=
> [e-mail]> 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: *"[e-mail]" <[e-mail]>
> *Date: *Friday, 12 March 2021 at 05:01
> *To: *Antoni Przygienda <[e-mail]>, Jordan Head <[e-mail]>,
> Wen Lin <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> *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;
>
> *抄送人：*[e-mail];[e-mail];
>
> *日* *期* *：*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: *"[e-mail]" <[e-mail]>
> *Date: *Wednesday, 10 March 2021 at 16:31
> *To: *Antoni Przygienda <[e-mail]>, Jordan Head <[e-mail]>,
> Wen Lin <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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
> [e-mail]
> 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
> [e-mail]
> 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