Also, Some preliminary interop tests were conducted recently for segmentation (thought it was VXLAN <-> MPLS <-> VXLAN, not VXLAN <-> VXLAN <-> VXLAN):
http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf <http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf> -> Page 11 Thanks, Krzysztof > On 2020 -Apr-24, at 09:07, Rabadan, Jorge (Nokia - US/Mountain View) > <jorge.raba...@nokia.com> wrote: > > Hi Gyan, > > If I may, note that: > https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10#section-4.6 > <https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10#section-4..6> > > 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 <mailto:bess-boun...@ietf.org>> on behalf > of Gyan Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>> > Date: Friday, April 24, 2020 at 5:21 AM > To: Jeff Tantsura <jefftant.i...@gmail.com <mailto:jefftant.i...@gmail.com>> > Cc: BESS <bess@ietf.org <mailto: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://datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/> > > Kind regards > > Gyan > > On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <jefftant.i...@gmail.com > <mailto: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 >> <mailto: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 >>> <mailto: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 >>>> <mailto: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 <mailto: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 <mailto: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 <mailto:gyan.s.mis...@verizon.com> >>> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org <mailto:BESS@ietf.org> >>> https://www.ietf.org/mailman/listinfo/bess >>> <https://www.ietf.org/mailman/listinfo/bess> > -- > Gyan Mishra > Network Engineering & Technology > Verizon > Silver Spring, MD 20904 > Phone: 301 502-1347 > Email: gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> > > > _______________________________________________ > BESS mailing list > BESS@ietf.org <mailto:BESS@ietf.org> > https://www.ietf.org/mailman/listinfo/bess > <https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
