Re: [bess] VXLAN BGP EVPN Question
Gyan Mishra <hayabusagsm@gmail.com> Sat, 24 April 2021 19:04 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D502E3A1B8A for <bess@ietfa.amsl.com>; Sat, 24 Apr 2021 12:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.985
X-Spam-Level:
X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 yt51h8TVwrnN for <bess@ietfa.amsl.com>; Sat, 24 Apr 2021 12:04:04 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 C06E13A1B94 for <bess@ietf.org>; Sat, 24 Apr 2021 12:04:01 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id g1-20020a17090adac1b0290150d07f9402so2888138pjx.5 for <bess@ietf.org>; Sat, 24 Apr 2021 12:04:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zZXiMFlWxLHNtzN11+BfLF49rt+k9K9TeemRSeEM13A=; b=Wabqvjd+YRccLVNhcQvothy5luXpe3T5M1B1q2iOX05Uvm5hJnKoxeGusscqfMrTr5 geVUdAgshgYCHmnTcVwtseJQDx2eDLgGxQSKF1O/DTRzbRBiahj+ZYOyr5zyVeONifoO tVTJjs+9AtRKdkS7jwLZX5qSz/ikCkcYkkPSUnWipganc3MHbXKHoOFzEmFfc9pRxFnV P17e/vE0U9MPUOjx93vC0kNzOzUfeREfY3SGZIsRf60KWMoM8oU20cRAUKEGLcfImqON mtUwPySF1nvduRMVKcsB3IpCydLi8q3ev/s94jP96+Fao3d/I2zXIyPnbRKZey03tmlz +WLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zZXiMFlWxLHNtzN11+BfLF49rt+k9K9TeemRSeEM13A=; b=pR3mkh1KbnFrwTGRIeZsFF2xaRwLoZiJ8TFIaYUnVPtGrAJ5N6dV9ZzrsAZstSb4lB 0gRld1z+hJPTD8+bNxqRb8kZ7qaEkuhJSA1e5Q5n52MW+DteQrKeCG/hph6TVnWeM2tU c331Xm7OcoQYsCDGz5CeN8G6L8jotMEz4oQFpFkFJJQKz/6f0geHysUPYrxpBzAMJ9+M Zzo9KTgm7FQnVcK47qwfJcamxXB6B9IVvn4mosYLX0lHhg23AGyNh9yi4KUCiS8pDL0t EAc2TBbOEMfJ05QnhDyj138ktiVU6ocOwolvBareGgEQRYK3BfRLTOqtg70ujHi80uqY xkLw==
X-Gm-Message-State: AOAM531ivcHR5fCWargDZURFJ+unqK5hjrWv3wgFutcbwNNBz7I56NUc 2BmT/CqC8DLrPHq4bfNI++kIOFoK0x2UCzK6K7o=
X-Google-Smtp-Source: ABdhPJxb21Eu8vX0Ve2pELCEl0IhbDKaEhTVt4C63CYF+RppJ4IetY1WuvKOObaMQV5bMsqKkx4heWyrf0G3aLcfv/4=
X-Received: by 2002:a17:902:8307:b029:ec:86a4:90fa with SMTP id bd7-20020a1709028307b02900ec86a490famr10330894plb.22.1619291040360; Sat, 24 Apr 2021 12:04:00 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV2z==qQziMKLVFFucDfSMPWiT17dQWVmn4xw07DbmnuSg@mail.gmail.com> <A58CC77D-3A77-4ACF-BD86-00C34627CC10@gmail.com>
In-Reply-To: <A58CC77D-3A77-4ACF-BD86-00C34627CC10@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 24 Apr 2021 15:03:49 -0400
Message-ID: <CABNhwV28RG+LLi_CR_Y3cP9i2r8RVKZpiLKyjZonxKYuZBOZVw@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, BESS <bess@ietf.org>, John E Drake <jdrake@juniper.net>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Content-Type: multipart/alternative; boundary="0000000000003faed105c0bc933f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/FA77Jbeqlj-4B4m_jatbtk-KT8U>
Subject: Re: [bess] VXLAN BGP EVPN Question
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2021 19:04:16 -0000
Completely understood for a standards specifications with normative dependencies. I think we are close to seeing light at the end of the tunnel for the encap draft. Kind Regards Gyan On Sat, Apr 24, 2021 at 2:57 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote: > Gyan, > > Normative references have to be at least at the same level of maturity as > the document referring. Just common sense. While it often creates rather > complex dependencies, it is a healthy precaution. > > Regards, > Jeff > > On Apr 24, 2021, at 10:14, Gyan Mishra <hayabusagsm@gmail.com> wrote: > > > > > That’s fabulous news that everyone has implemented!! > > Unfortunate on the red tape with the turn around to RFC. > > Kind Regards > > Gyan > > > On Sat, Apr 24, 2021 at 8:29 AM John E Drake <jdrake@juniper.net> wrote: > > Yes, and everyone has implemented it. Unfortunately, it had an >> inadvertent normative reference to the tunnel encapsulation attribute and >> hence has been in the RFC Editor queue for over three years. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* Gyan Mishra <hayabusagsm@gmail.com> >> *Sent:* Friday, April 23, 2021 6:21 PM >> *To:* Ali Sajassi (sajassi) <sajassi@cisco.com>; BESS <bess@ietf.org>; >> Jeff Tantsura <jefftant.ietf@gmail.com>; John E Drake <jdrake@juniper.net>; >> Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com> >> *Subject:* Fwd: [bess] VXLAN BGP EVPN Question >> >> >> >> *[External Email. Be cautious of content]* >> >> >> >> >> >> Authors >> >> >> >> Do we know if this draft will progress to RFC? >> >> >> >> https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10 >> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvkEMMBHM$> >> >> >> >> >> >> This is a very useful draft for intra DC multi pod NVO3 solutions with >> multiple vendors. >> >> >> >> >> >> Thanks >> >> >> >> Gyan >> >> >> >> >> >> ---------- Forwarded message --------- >> From: *Rabadan, Jorge (Nokia - US/Mountain View)* < >> jorge.rabadan@nokia.com> >> Date: Fri, Apr 24, 2020 at 3:07 AM >> Subject: Re: [bess] VXLAN BGP EVPN Question >> To: Gyan Mishra <hayabusagsm@gmail.com>, Jeff Tantsura < >> jefftant.ietf@gmail.com> >> CC: BESS <bess@ietf.org> >> >> >> >> Hi Gyan, >> >> >> >> If I may, note that: >> >> >> https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10#section-4.6 >> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10*section-4.6__;Iw!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvfKkPzi4$> >> >> >> >> Also provides vxlan segmentation, and while the description is based on >> DCI, you can perfectly use it for inter-pod connectivity. >> >> >> >> Thanks. >> >> Jorge >> >> >> >> *From: *BESS <bess-bounces@ietf.org> on behalf of Gyan Mishra < >> hayabusagsm@gmail.com> >> *Date: *Friday, April 24, 2020 at 5:21 AM >> *To: *Jeff Tantsura <jefftant.ietf@gmail.com> >> *Cc: *BESS <bess@ietf.org> >> *Subject: *Re: [bess] VXLAN BGP EVPN Question >> >> >> >> >> >> Hi Jeff >> >> >> >> Yes - Cisco has a draft for multi site for use cases capability of inter >> pod or inter site segmented path between desperate POD fabrics intra DC or >> as DCI option inter DC without MPLS. The segmentation localizes BUM >> traffic and has border gateway DF election for BUM traffic that is >> segmented stitched between PODs as I mentioned similar to inter-as L3 vpn >> opt b. There is a extra load as you said on the BGW border gateway >> performing the network vtep dencap from leaf and then again encap towards >> the egress border gateway. Due to that extra load on the border gateway >> it’s not recommended to have spine function on BGW thus an extra layer for >> multi site to be scalable. Definitely requires proprietary asic and not >> merchant silicon or white box solution. The BUM traffic is much reduced as >> you stated from multi fabric connected super spine or single fabric spine >> that contains all leafs. That decoupling sounds like incongruent control >> and data plane with Mac only Type 2 routes which would result in more BUM >> traffic but it sounds like that maybe trade off of conversation learning >> only active flows versus entire data center wide Mac VRF being learned >> everywhere. I wonder if their is an option to have that real decoupling of >> EVPN control plane and vxlan data plane overlay that does not impact >> convergence but adds stability and only active flow Type 2 Mac learner >> across the fabric. >> >> >> >> https://datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/ >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvPV5PoSI$> >> >> >> >> Kind regards >> >> >> >> Gyan >> >> >> >> On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <jefftant.ietf@gmail.com> >> wrote: >> >> Gyan, >> >> >> >> "Multi site” is not really an IETF terminology, this is a solution >> implement by NX-OS, there’s a draft though. Its main functionality is to >> localize VxLAN tunnels and provide segmented path vs end2end full mesh of >> VxLAN tunnels (participating in the same EVI). We are talking HER here. >> >> The feature is heavily HW dependent as it requires BUM re-encapsulation >> at the boundaries (leaf1->BGW1-BGW2->leaf2..n). So good luck seeing it soon >> on low end silicon. >> >> It doesn’t eliminate BUM traffic but significantly reduces the span of >> “broadcast domain” and reduces the need for large flood domains (modern HW >> gives you ~512 large flood groups, obviously depending on HW) >> >> >> >> Wrt your question about Mac conversation learning - this is an >> implementation issue, nothing in EVPN specifications precludes you of doing >> so, moreover in the implementation I was designing (in my previous life) we >> indeed decoupled data plane learning from control plane advertisement so >> control plane was aware of “Active” flows. Needless to say - this creates >> an additional layer of complexity and all kinds of funky states in the >> system ;-). >> >> >> >> Hope this helps >> >> >> >> Cheers, >> >> Jeff >> >> On Apr 23, 2020, 8:30 AM -0700, Gyan Mishra <hayabusagsm@gmail.com>, >> wrote: >> >> >> >> >> >> Slight clarification with the arp traffic. What I meant was broadcast >> traffic translated into BUM traffic with the EVPN architecture is there any >> way to reduce the amount of BUM traffic with a data center design >> requirement with vlan anywhere sprawl with 1000s of type 2 Mac mobility >> routes being learned between all the leaf VTEPs. >> >> >> >> The elimination of broadcast is a tremendous gain and with broadcast >> suppression of multicast that does help but it would be nice to not have >> such massive Mac tables type 2 route churn chatter with a conversation >> learning where only active flows are are in the type 2 rib. >> >> >> >> Kind regards >> >> >> >> Gyan >> >> >> >> On Wed, Apr 22, 2020 at 6:47 PM Gyan Mishra <hayabusagsm@gmail.com> >> wrote: >> >> >> >> In the description of the vxlan BGP evpn scenario has a typo on the >> multisite feature segmented LSP inter pod with the RT auto rewrite which is >> similar to MPLS inter-as option b not a. >> >> >> >> Kind regards >> >> >> >> Gyan >> >> >> >> On Wed, Apr 22, 2020 at 5:57 PM Gyan Mishra <hayabusagsm@gmail.com> >> wrote: >> >> >> >> All >> >> >> >> Had a question related to vxlan BGP EVPN architecture specifications >> defined in BGP EVPN NVO3 overlay RFC 8365 and VXLAN data plane RFC 7348. >> >> >> >> In a Data Center environment where you have a multiple PODs individual >> fabrics per POD connected via a super spine extension using a Multi site >> feature doing auto rewrite of RTs to stitch the NVE tunnel between pods >> similar to inter-as option A. >> >> >> >> So in this scenario where you have vlan sprawl everywhere with L2 and L3 >> VNIs everywhere as if it were a a single L2 domain. The topology is a >> typical vxlan spine leaf topology where the L3 leafs are the TOR switch so >> very small physical L2 fault domain. So I was wondering if with the vxlan >> architecture if this feature below is possible or if their is a way to do >> so in the current specification. >> >> >> >> Cisco use to have a DC product called “fabric path” which was based on >> conversation learning. >> >> >> >> Is there any way with existing vxlan BGP evpn specification or maybe >> future enhancement to have a Mac conversation learning capability so that >> only the active mac’s that are part of a conversations flow are the mac >> that are flooded throughout the vxlan fabric. That would really help >> tremendously with arp storms so if new arp entries are generated locally on >> a leaf they are not flooded through the fabric unless their are active >> flows between leafs. >> >> >> >> Also is there a way to filter type 2 Mac mobility routes between leaf >> switches at the control plane level based on remote vtep or maybe other >> parameters.. That would also reduce arp storms BUM traffic. >> >> >> >> Kind regards >> >> >> >> Gyan >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvzScD_hE$> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> >> >> -- >> > >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$> >> <~WRD0000.jpg> >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* >> >> *M 301 502-1347* >> >> >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Jeff Tantsura
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] VXLAN BGP EVPN Question Krzysztof Grzegorz Szarkowicz
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] VXLAN BGP EVPN Question Lukas Krattiger (lkrattig)
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- [bess] Fwd: VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question John E Drake
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Acee Lindem (acee)
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Jeff Tantsura
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra
- Re: [bess] VXLAN BGP EVPN Question Gyan Mishra