Thanks Jeff for the clarification. Thanks
Gyan On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote: > Gyan, > > you are mixing use of BW community as such with cumulative propagation > (the theme of the draft). > The original community is defined in "Non-Transitive Two-Octet AS-Specific > Extended Community Sub-Types" IANA section and that has to be changed to > allow eBGP use cases. > Aggregation is a very useful feature when the prefix with the > community attached is traversing the fabric and is being regenerated and > potentially transformed at every hop traversed. > > The alternative with add-path and potentially path explosion (not to talk > about operational complexity of add-path and bugs in the implementations) > is a rather unattractive solution for DC fabrics. > > Cheers, > Jeff > > On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > >> Hi Satya >> >> For EBGP DCs with multi-stage clos I understand this can be used, however >> with Cisco & Juniper & Nokia & Arista and maybe other vendor >> implementations seem to combine the non transitive link bw extended >> community and transitive cumulative link bw extended community into a >> single feature that works for UCMP intra AS and inter AS. Please confirm. >> >> These two drafts seem to be combined by implementations into a single >> UCMP feature for both eBGP and iBGP. >> >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 >> >> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03 >> >> Cisco: >> >> >> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html >> >> >> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853 >> >> Juniper: >> >> >> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html >> >> Nokia: >> >> >> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html >> >> >> Arista: >> >> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621 >> >> Kind Regards >> >> Gyan >> >> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) < >> satya...@cisco.com> wrote: >> >>> Hi Jim, >>> >>> >>> >>> No, they do not. >>> >>> >>> >>> This draft under discussion is a way to aggregate the link bandwidth in >>> EBGP DCs and advertise it upstream. >>> >>> It works well in multi-stage clos topology fabrics. >>> >>> Traffic is demultiplexed (multi-path load balanced) when it arrives at a >>> node of each stage (unless the sink). >>> >>> >>> >>> The draft you are mentioning, >>> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is >>> really a way to communicate the link-bandwidth across EBGP boundaries. >>> >>> It is mostly geared from an Inter-AS Option C viewpoint (next-hop >>> unchanged) although it also applies to Option B deployments (next-hop-self). >>> >>> There is no notion of aggregating bandwidth here. >>> >>> >>> >>> HTH. >>> >>> >>> >>> Best Regards, >>> >>> --Satya >>> >>> >>> >>> >>> >>> *From: *"UTTARO, JAMES" <ju1...@att.com> >>> *Date: *Wednesday, May 26, 2021 at 5:38 AM >>> *To: *Gyan Mishra <hayabusa...@gmail.com>, Robert Raszuk < >>> rob...@raszuk.net> >>> *Cc: *Jeff Tantsura <jefftant.i...@gmail.com>, Arie Vayner < >>> ar...@vayner.net>, "bess@ietf.org" <bess@ietf.org>, "Satya Mohanty >>> (satyamoh)" <satya...@cisco.com> >>> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth >>> Draft >>> >>> >>> >>> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing >>> address the same field of use? * >>> >>> >>> >>> *Thanks,* >>> >>> * Jim Uttaro * >>> >>> >>> >>> *From:* BESS <bess-boun...@ietf.org> *On Behalf Of * Gyan Mishra >>> *Sent:* Wednesday, May 26, 2021 12:57 AM >>> *To:* Robert Raszuk <rob...@raszuk.net> >>> *Cc:* Jeff Tantsura <jefftant.i...@gmail.com>; Arie Vayner < >>> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh) <satyamoh= >>> 40cisco....@dmarc.ietf.org> >>> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth >>> Draft >>> >>> >>> >>> Across the DC space in general most providers use NVO3 and vxlan source >>> port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load >>> balancing at the L2 VNI overlay layer, which translates into underlay load >>> balancing of flows and thus no polarization. >>> >>> >>> >>> Across the DC space speaking from an operators perspective as under the >>> floor fiber is not at a premium compare to 100G facilities costs the net >>> addition of bandwidth can be done fairly quickly so you are ahead of the >>> congestion curve and can be proactive versus reactively upgrading bandwidth >>> piecemeal here and there ad hoc. >>> >>> >>> >>> There still maybe cases that still arise as even if you have the fiber >>> infrastructure available, it’s not easy to upgrade and flash every link >>> simultaneously in the DC in one or multiple maintenance windows, so you >>> could still be left with some uneven bandwidth across the DC that could >>> utilize this feature. >>> >>> >>> >>> DC comes into play for PE-CE “wan links”as well use case for unequal >>> cost load balancing use of the cumulative link bandwidth community >>> regenerated. >>> >>> >>> >>> >>> >>> I think the use case where both the iBGP P core P-P links or eBGP PE - >>> PE inter-as are all wan links where link upgrades tend to not get done in >>> unison uniformly, and in those cases both iBGP link bandwidth community can >>> be heavily utilized as well as eBGP cumulative regenerated link bandwidth >>> community for unequal cost load balancing. Across the core as well it is >>> hard to flash all links even under floor fiber to the same bandwidth all at >>> once you are left with the requirement for unequal coat load balancing. >>> >>> >>> >>> As operators upgrade their DC as well as core infrastructure to IPv6 >>> forwarding plane in the move towards SRv6, they can now take advantage of >>> flow label entropy stateless uniform load balancing and elimination of >>> polarization. However, the wan link upgrades of core and DC PE-CE still >>> exists and thus may be done piecemeal, so then both of the drafts are an >>> extremely helpful tool for operators that much need the unequal cost load >>> balancing capability. >>> >>> >>> >>> I support both drafts. >>> >>> >>> >>> Have most vendors implemented this to support both 2 byte and 4 byte AS >>> extended community. The drafts state 2 byte AS support. >>> >>> >>> >>> Thanks >>> >>> >>> >>> Gyan >>> >>> >>> >>> On Tue, May 25, 2021 at 7:00 PM Robert Raszuk <rob...@raszuk.net> wrote: >>> >>> Hi Arie, >>> >>> >>> >>> Draft draft-ietf-idr-link-bandwidth talks about advertising towards >>> IBGP. It does not talk about advertising over EBGP. >>> >>> >>> >>> While I do support your use case I think it would be much cleaner to >>> just ask for new ext. community type. >>> >>> >>> >>> Reason being that as you illustrate you may want to accumulate BGP >>> path's bw across few EBGP hops in the DC. Today there is no way to do so >>> unless you want to completely hijack current lb ext community. >>> >>> >>> >>> Also I see an analogy here to AIGP RFC although it clearly fits rather >>> poorly for those who use BGP as IGP :). >>> >>> >>> >>> Best, R. >>> >>> >>> >>> On Wed, May 26, 2021 at 12:22 AM Arie Vayner <ar...@vayner.net> wrote: >>> >>> Jeff, >>> >>> >>> >>> Actually, the way this draft is written, and how the implementations I'm >>> aware of are implemented, this is not really a transitive community. It is >>> a new community that is being generated on the AS boundary. >>> >>> The community value is not carried over, but is calculated based on an >>> cumulative value of other received communities, and then advertised as a >>> new value across the AS boundary. >>> >>> >>> >>> Tnx, >>> >>> Arie >>> >>> >>> >>> On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura <jefftant.i...@gmail.com> >>> wrote: >>> >>> Hi, >>> >>> I support adoption of the draft as Informational, please note, that >>> request to change transitivity characteristics of the community is >>> requested in another draft. >>> Gyan - please note, while pretty much every vendor has implemented the >>> community and relevant data-plane constructs, initial draft defines the >>> community as non transititive, some vendors have followed that while some >>> other have implemented it a transitive (to support obvious use case - eBGP >>> in DC). >>> >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) <satyamoh= >>> 40cisco....@dmarc.ietf.org>, wrote: >>> >>> >>> Hi all, >>> >>> >>> >>> On behalf of all the authors, we request a discussion of the draft >>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03 >>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWOnm6zLkY$> >>> and subsequent WG adoption. >>> >>> This draft extends the usage of the DMZ link bandwidth to scenarios >>> where the cumulative link bandwidth needs to be advertised to a BGP speaker. >>> >>> Additionally, there is provision to send the link bandwidth extended >>> community to EBGP speakers via configurable knobs. Please refer to section >>> 3 and 4 for the use cases. >>> >>> >>> >>> This feature has multiple-vendor implementations and has been deployed >>> by several customers in their networks. >>> >>> >>> >>> Best Regards, >>> >>> --Satya >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWO_sLM9KM$> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWO_sLM9KM$> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWO_sLM9KM$> >>> >>> -- >>> >>> [image: Image removed by sender.] >>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWORYETg1w$> >>> >>> *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*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
