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

Thanks Jeff!

Gyan

On Sun, Mar 14, 2021 at 2:50 PM Jeff Tantsura <jefftant.ietf@gmail.com>
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 <hayabusagsm@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/
>
> 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
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
> Spring, MD
>
> _______________________________________________
> 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