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 <jdr...@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 <hayabusa...@gmail.com> > *Sent:* Friday, April 23, 2021 6:21 PM > *To:* Ali Sajassi (sajassi) <saja...@cisco.com>; BESS <bess@ietf.org>; > Jeff Tantsura <jefftant.i...@gmail.com>; John E Drake <jdr...@juniper.net>; > Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@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.raba...@nokia.com > > > Date: Fri, Apr 24, 2020 at 3:07 AM > Subject: Re: [bess] VXLAN BGP EVPN Question > To: Gyan Mishra <hayabusa...@gmail.com>, Jeff Tantsura < > jefftant.i...@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-boun...@ietf.org> on behalf of Gyan Mishra < > hayabusa...@gmail.com> > *Date: *Friday, April 24, 2020 at 5:21 AM > *To: *Jeff Tantsura <jefftant.i...@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.i...@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 <hayabusa...@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 <hayabusa...@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 <hayabusa...@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.mis...@verizon.com > > > > > > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mis...@verizon.com > > > > > > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mis...@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.mis...@verizon.com > > > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
