Hi Ketan, Thank you for raising such an interesting topic.
In fact, there are at least four drafts related to the link bandwidth extended community (see below), AFAIK. 1. https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 2. https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ 3. https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb 4. https://datatracker.ietf.org/doc/draft-li-idr-link-bandwidth-ext/02/ 5. https://datatracker.ietf.org/doc/html/draft-xu-idr-fare-01 The first draft describes how to perform WECMP based on the bandwidth of the EXTERNAL (DMZ) link carried in the link-bandwidth extended community. However, since the link-bandwidth extended community is defined as non-transitive, it can not be propagated further to eBGP peers. In the Deployment Considerations section, the link bandwidth is said to apply to the BGP/MPLS IP VPN scenario as well. The second draft eliminates the restriction that the DMZ link bandwidth extended community could not be sent across AS boundaries. Furthermore, when receiving multiple equal-cost BGP paths towards the external network (e.g., the WAN), the best path among them will be advertised to eBGP peers with the transitive link bandwidth extended community being filled with the cumulative bandwidth of the multiple external links. Since this draft is built on the assumption that "The total BW available towards WAN is significantly lower than the total BW within the fabric”, the internal path bandwidth within the fabric is not considered. In the Operational Considerations section, it said clearly that “these solutions also are applicable to many address families such as L3VPN [RFC4364] , IPv4 with labeled unicast[RFC8277] and EVPN [RFC7432]". The third draft describes an EVPN-dedicated extended community and an EVPN link-bandwidth sub-type of the above EVPN-dedicated extended community for the EVPN WECMP purpose. I’m wondering why the link-bandwidth extended community as already defined in the first draft which applies to BGP/MPLS IP VPN could not apply to EVPN. IMHO, the major contribution of this draft is to define different expression ways of the link bandwidth, and this is also the major contribution of the fourth draft occasionally. IMHO, all of the above drafts describe how to leverage the extended community to carry the bandwidth of the EXTERNAL links to perform WECMP based on the bandwidth of the EXTERNAL links towards the outside of the fabric (e.g., the WAN, the services bound to anycast address, or the multi-homed VPN sites). In contrast, the fifth draft describes how to leverage the extended community to carry the end-to-end PATH bandwidth (within the data center fabric) to perform WECMP. Best regards, Xiaohu 发件人: Ketan Talaulikar <ketant.i...@gmail.com> 日期: 星期四, 2024年7月25日 05:57 收件人: idr@ietf. org <i...@ietf.org>, draft-li-idr-link-bandwidth-...@ietf.org <draft-li-idr-link-bandwidth-...@ietf.org> 抄送: BESS <bess@ietf.org> 主题: [Idr] Do we need yet another link bandwidth community? Hello All, Checking on the need for draft-li-idr-link-bandwidth-ex when we already have the EVPN Link Bandwidth Extended Community (draft-ietf-bess-evpn-unequal-lb). Is it because of the name containing "EVPN" or am I missing something? If it is just the name, I hope we still have the time to change it in draft-ietf-bess-evpn-unequal-lb? We already have 2 types (ignoring the transitive/non-transitive variants) and I hope we can avoid the need for a third one ... Thanks, Ketan
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
