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

Jeff Tantsura <jefftant.ietf@gmail.com> Sun, 14 March 2021 18:50 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9A3A1047; Sun, 14 Mar 2021 11:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C8JjV781JlP; Sun, 14 Mar 2021 11:50:50 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626383A1044; Sun, 14 Mar 2021 11:50:50 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id f8so700329plg.10; Sun, 14 Mar 2021 11:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cb3RMcppHaPeJK/M+qHAnkpv0Lxk6sjeOMIZj0lrfe0=; b=LbScToWAA4JR/ERWLGiIO12lABRnOf+YSLrrIBtK6+LPjdqagiyg42cSNdjGW8ifpP y+5MDx5a3MmGb6iR2Y7fGBQiYlazVIagGnDU+yoHbVDjkyNqsdiXKr6MP/F9CPA9iYUJ FSAbeiUKRuykW+1OMCqmJQxFsBVanPe9c4tKnM9/EY+3GxfqlqunZo6NtL+xCdHXEMSY PKYQ2GdfP9IkldCr56MCfWUZVy40ArZLv5Eo4eB/qEAPeRum6RG5aWAq9y9tq5eKnmZU Nnuucuo6FyyUeJTrCZhuGYLjG4dPU18/BScKFgnLdqCwIWr7DdlUiaESXXn6b1GJ8LQa mtTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cb3RMcppHaPeJK/M+qHAnkpv0Lxk6sjeOMIZj0lrfe0=; b=km5F40tNe0u2t4+QsEzaHp4Ro7DVjte9+iyu5HS8lsQNYltzf6NpbNxA94aStDjYaE UBbBF43ARXAjib2ppGmwTxeW824MWGDw1vmLZjDZ0ByrGR645Cf1ubhG+UIyiKZaTgws fDebHc8nNZDlpguAJJsB9BX4sMU00reiYHCZsUXsutGsZi/cpxS6AIdACHG6HyZqrH5S KO3O31NgxDAsVonF86Do0+iJqq8C3BXrjrNoKmjlEtN1UKw6aJbNCpcKAksqrh/8/aAs 4/6Q6G/AbE8ADmg65SsVpZxXt/qXHAM7qvcEgeoxKifSkVSpDBaWi28XWZa5MjjxpSF2 90NQ==
X-Gm-Message-State: AOAM5338axjB9UqByGXFuBTkUCk0Of5BCzCgOsHT2plQLlg/TNVCGKvb 0EZsN+52ryptnT6jB3CqyGA=
X-Google-Smtp-Source: ABdhPJweKfETLjGh4n5qj3CkjRiTWJIhT/03F+u3Z+6tuZjsbHDeBZjoHYmEEOuf+cxGtYb8flpVxQ==
X-Received: by 2002:a17:90a:f98e:: with SMTP id cq14mr8704340pjb.60.1615747848869; Sun, 14 Mar 2021 11:50:48 -0700 (PDT)
Received: from [192.168.1.12] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id fr23sm8208369pjb.22.2021.03.14.11.50.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Mar 2021 11:50:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-DB35052B-6384-4B1D-B97B-BDE138DB71C2"
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 14 Mar 2021 11:50:45 -0700
Message-Id: <AC084BCD-2619-44DF-8E60-B50D14492F5F@gmail.com>
References: <CABNhwV2L9JoEWUK4fVOOCBq8312WvOQJR+sNM=UU_TNbRSnW7w@mail.gmail.com>
Cc: Antoni Przygienda <prz=40juniper.net@dmarc.ietf.org>, rift@ietf.org, zhang.zheng@zte.com.cn, bess@ietf.org, Wen Lin <wlin@juniper.net>, Jordan Head <jhead@juniper.net>
In-Reply-To: <CABNhwV2L9JoEWUK4fVOOCBq8312WvOQJR+sNM=UU_TNbRSnW7w@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/LVTSlZKV3dlam5Y_5H49vTq5jac>
Subject: Re: [Rift] [bess] comments on draft-head-rift-auto-evpn-00
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Mar 2021 18:50:53 -0000

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
> -- 
> 
> 
> 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