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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
