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

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.net@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.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
> *Date: *Friday, 12 March 2021 at 05:01
> *To: *Antoni Przygienda <prz@juniper.net>, Jordan Head <jhead@juniper.net>,
> Wen Lin <wlin@juniper.net>
> *Cc: *"rift@ietf.org" <rift@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;
>
> *抄送人：*rift@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.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
> *Date: *Wednesday, 10 March 2021 at 16:31
> *To: *Antoni Przygienda <prz@juniper.net>, Jordan Head <jhead@juniper.net>,
> Wen Lin <wlin@juniper.net>
> *Cc: *"rift@ietf.org" <rift@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