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

Reply via email to