Gyan, Normative references have to be at least at the same level of maturity as the document referring. Just common sense. While it often creates rather complex dependencies, it is a healthy precaution.
Regards, Jeff > On Apr 24, 2021, at 10:14, Gyan Mishra <[email protected]> wrote: > > > > 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 <[email protected]> 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 <[email protected]> >> Sent: Friday, April 23, 2021 6:21 PM >> To: Ali Sajassi (sajassi) <[email protected]>; BESS <[email protected]>; Jeff >> Tantsura <[email protected]>; John E Drake <[email protected]>; >> Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]> >> 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 >> >> >> >> >> >> 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) <[email protected]> >> Date: Fri, Apr 24, 2020 at 3:07 AM >> Subject: Re: [bess] VXLAN BGP EVPN Question >> To: Gyan Mishra <[email protected]>, Jeff Tantsura >> <[email protected]> >> CC: BESS <[email protected]> >> >> >> >> Hi Gyan, >> >> >> >> If I may, note that: >> >> 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 <[email protected]> on behalf of Gyan Mishra >> <[email protected]> >> Date: Friday, April 24, 2020 at 5:21 AM >> To: Jeff Tantsura <[email protected]> >> Cc: BESS <[email protected]> >> 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/ >> >> >> >> Kind regards >> >> >> >> Gyan >> >> >> >> On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <[email protected]> >> 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 <[email protected]>, 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 <[email protected]> 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 <[email protected]> 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: [email protected] >> >> >> >> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: [email protected] >> >> >> >> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: [email protected] >> >> >> >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: [email protected] >> >> >> >> >> >> -- >> >> <~WRD0000.jpg> >> >> Gyan Mishra >> Network Solutions Architect >> Email [email protected] >> M 301 502-1347 >> >> >> > -- > > > Gyan Mishra > Network Solutions Architect > Email [email protected] > M 301 502-1347 > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
