Completely understood for a standards specifications with normative dependencies.
I think we are close to seeing light at the end of the tunnel for the encap draft. Kind Regards Gyan On Sat, Apr 24, 2021 at 2:57 PM Jeff Tantsura <[email protected]> wrote: > 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 >> <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)* < >> [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 >> <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 <[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/ >> <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 <[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 >> <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: 301 502-1347 >> >> Email: [email protected] >> >> >> >> >> >> -- >> > >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$> >> <~WRD0000.jpg> >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
