Re: [bess] VXLAN BGP EVPN Question

[Gyan Mishra <[e-mail]>]

Thanks Acee!!

Gyan

On Sat, Apr 24, 2021 at 2:20 PM Acee Lindem (acee) <[e-mail]> wrote:

> There are a number of drafts that were waiting years on the IDR tunnel
> Encap draft – they will all be published together in this cluster:
>
>
>
> https://www.rfc-editor.org/cluster_info.php?cid=C349
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
>
>
> *Date: *Saturday, April 24, 2021 at 1:14 PM
> *To: *John E Drake <[e-mail]>
> *Cc: *Jeff Tantsura <[e-mail]>, "Ali Sajassi (sajassi)" <
> [e-mail]>, "Rabadan, Jorge (Nokia - US)" <[e-mail]>,
> BESS <[e-mail]>
> *Subject: *Re: [bess] VXLAN BGP EVPN Question
>
>
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Friday, April 23, 2021 6:21 PM
> *To:* Ali Sajassi (sajassi) <[e-mail]>; BESS <[e-mail]>;
> Jeff Tantsura <[e-mail]>; John E Drake <[e-mail]>;
> Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
> *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)* <[e-mail]
> >
> Date: Fri, Apr 24, 2020 at 3:07 AM
> Subject: Re: [bess] VXLAN BGP EVPN Question
> To: Gyan Mishra <[e-mail]>, Jeff Tantsura <
> [e-mail]>
> CC: BESS <[e-mail]>
>
>
>
> 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 <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
> *Date: *Friday, April 24, 2020 at 5:21 AM
> *To: *Jeff Tantsura <[e-mail]>
> *Cc: *BESS <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>,
> 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 <[e-mail]> 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 <[e-mail]> 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: [phone]
>
> Email: [e-mail]
>
>
>
>
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> 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: [phone]
>
> Email: [e-mail]
>
>
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*