Looks like it has been submitted for publication!! https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/22/
Ready to drain the queue of drafts with normative references!! Kind Regards Gyan On Sat, Apr 24, 2021 at 3:03 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > 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 <jefftant.i...@gmail.com> > 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 <hayabusa...@gmail.com> 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 <jdr...@juniper.net> 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 <hayabusa...@gmail.com> >>> *Sent:* Friday, April 23, 2021 6:21 PM >>> *To:* Ali Sajassi (sajassi) <saja...@cisco.com>; BESS <bess@ietf.org>; >>> Jeff Tantsura <jefftant.i...@gmail.com>; John E Drake < >>> jdr...@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain View) < >>> jorge.raba...@nokia.com> >>> *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)* < >>> jorge.raba...@nokia.com> >>> Date: Fri, Apr 24, 2020 at 3:07 AM >>> Subject: Re: [bess] VXLAN BGP EVPN Question >>> To: Gyan Mishra <hayabusa...@gmail.com>, Jeff Tantsura < >>> jefftant.i...@gmail.com> >>> CC: BESS <bess@ietf.org> >>> >>> >>> >>> 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 <bess-boun...@ietf.org> on behalf of Gyan Mishra < >>> hayabusa...@gmail.com> >>> *Date: *Friday, April 24, 2020 at 5:21 AM >>> *To: *Jeff Tantsura <jefftant.i...@gmail.com> >>> *Cc: *BESS <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://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 <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>, >>> 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> >>> 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 >>> <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: gyan.s.mis...@verizon.com >>> >>> >>> >>> >>> >>> -- >>> >> >>> <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 gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>> >>> *M 301 502-1347* >>> >>> >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >> >> >> >> *M 301 502-1347* >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
