Hi Neeraj, Thanks for posting the update. I'll clear my DISCUSS ballot shortly.
It seems some of the remaining comments might have gotten missed out and hope you can consider those suggestions. Thanks, Ketan On Thu, Mar 12, 2026 at 3:59 AM Neeraj Malhotra (nmalhotr) < [email protected]> wrote: > > Hi, > > Great, thanks Ketan for reviewing the changes and closing them quickly. I > have incorporated the missing nit in the attached revision to be published. > > Thanks, > Neeraj > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Tuesday, March 10, 2026 at 10:53 PM > *To: *Neeraj Malhotra (nmalhotr) <[email protected]> > *Cc: *The IESG <[email protected]>, Stephane Litkowski < > [email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] < > [email protected]> > *Subject: *Re: Ketan Talaulikar's Discuss on > draft-ietf-bess-evpn-unequal-lb-33: (with DISCUSS and COMMENT) > > Hi Neeraj, > > Thanks for your responses and sharing the proposed update. Please check > inline below for follow-ups and clarifications with KT (consider those > without responses as addressed/closed). Please consider the further > suggestions when you post the next version. > > In summary, the proposed update addresses my comments and I will clear my > DISCUSS ballot once it is posted. > > There is one point (related to discuss-7) that I would like to bring up to > the front since this is perhaps not for the authors of this specific > document but for the BESS WG. I would urge the WG chairs and responsible AD > to please place this for the WG consideration. > > This is related to the normative procedures for propagation of information > between the BGP Link Bandwidth EC and the EVPN Link Bandwidth EC when doing > EVPN-IPVPN interworking. Two of the related documents > (draft-ietf-idr-link-bandwidth and draft-ietf-bess-evpn-ipvpn-interworking) > are with RFC Editor. This document is almost getting there. None of these > documents cover those procedures. My question to the BESS WG is whether > they plan to cover this and if yes, when/where? I can > suggest draft-ietf-bess-ebgp-dmz which is still with the WG (but in WGLC > currently). Please consider. > > > On Wed, Mar 11, 2026 at 2:09 AM Neeraj Malhotra (nmalhotr) < > [email protected]> wrote: > > > > > Hi Ketan, > > > > Many thanks for such a thorough review and significantly improving the > > document. Attached revision incorporates your feedback, barring a couple > > that are answered and explained below. Each of discuss/major/minor > > comments are individually answered below as incorporated or explained. > > > > I am attaching a copy of the proposed rev34 with all of these changes > > along with a diff between rev33 and rev34. Please let us know if you have > > any further comments or questions or if this addresses all of your > feedback. > > > > Thanks, > > Neeraj > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks to the WG and the authors for their work on this document that > > brings in > > weighted load-balancing in EVPN networks. > > > > I have a few points that I would like to discuss. > > > > 661 * Each egress PE MUST advertise an EVPN Link Bandwidth > > Extendetd > > 662 Community along with the ES route to signal the PE–CE link > > 663 bandwidth associated with the ES. > > > > <discuss-1> What if one of the ePEs does not send this EC or if it is > > invalid? > > What does the receiver do? Is the BW Capability ignored and everything > > falls > > back to the default DF election algorithm? > > > > [NM]: That’s correct. This is covered in section 4.1.1 BGP Error Handling > > - Invalid or Missing Extended Community. I have updated the text related > > to RT-4 handling to be clearer. > > > > KT> Thanks. That clarifies. > > > > > > > > 674 As a result, a given PE MAY appear multiple times in the DF > > candidate > > 675 list. Consequently, the value N used in the (V mod N) > operation > > 676 defined in [RFC7432] MUST be interpreted as the total number > of > > 677 ordinals in the weighted candidate list, rather than the total > > number > > 678 of distinct egress PEs in the ES. > > > > <discuss-2> Since the default DF election is being modified, would this > > document > > also not update RFC7432? I am thinking that this document is tagged as > > "updates" > > RFC7432, RFC8584, RFC9785 (but also > > draft-ietf-bess-evpn-per-mcast-flow-df-election?) or none of those. If > > this is > > considered an "extension" or "enhancement" of the DF election rather > than a > > "bugfix", then the "updates" tag is not necessary IMHO. Please see in my > > comments on existing text in section 6.3 that gives me the impression > that > > this > > is an extension. My point is unnecessary "updates" tags on RFCs make it > > harder > > for implementers/operators/readers to differentiate real "fixes" from > > "enhancements/extensions". I am seeking consistency here and will leave > the > > options for the authors/WG to consider. > > > > [NM]: You are correct that in general, this is an extension to the DF > > election methods defined in the four referenced documents. During one of > > the WG reviews, it was specifically suggested to add the “updates” clause > > for RFC8584 because this draft updates the DF Election Capabilities field > > in the DF Election Extended Community. Hence the statement in the > Abstract > > - "The document updates RFC 8584 to enable weighted load balancing across > > different DF election algorithms.” That said, I also see your point with > > respect to other drafts and I see that it may not necessarily constitute > as > > an update to RFC 8584. I prefer to remove the update clause as opposed > > adding it for the other documents and have the made the change in rev34. > > > > I am neutral with respect to what the norm is for such updates to a > > previously defined extended community. Let me know what you see best. I > > don’t think it is correct to add updates clause for all four documents > but > > happy to remove it for RFC8584 if you feel such a change does not qualify > > as an update. > > > > KT> Thanks for making that change. > > > > > > > > 840 7.1. Real-time Available Bandwidth > > > > 842 PE-CE link bandwidth availability may sometimes vary in > > real-time > > 843 disproportionately across PE-CE links within a multi-homed ES > > due to > > 844 various factors such as flow based hashing combined with fat > > flows > > 845 and unbalanced hashing. Reacting to real-time available > > bandwidth is > > 846 at this time outside the scope of this document. > > > > 848 Operators SHOULD be aware, however, that too frequent or > > dynamic re- > > 849 adjustment of advertised bandwidth values may lead to > > instability due > > 850 to repeated weighted path-list recomputation and DF election > > changes. > > 851 Appropriate guards, such as dampening or hysteresis > mechanisms, > > 852 SHOULD be considered when dynamic bandwidth advertisement is > > used. > > > > <discuss-3> Upto this point the document talked about link bandwidth and > > not > > available/free bandwidth. This section is giving the impression that the > > value > > signaled could be something other than the fixed link bandwidth (i.e., > > fixed > > besides scenarios where LAG members go up/down). Why does the document > not > > say > > that the values signaled MUST NOT be something that is varying based on > the > > link usage as doing that would be very problematic. It is not sufficient > to > > say that this is outside the scope. Then the first "SHOULD" is actually a > > "should". And the second SHOULD can give impression that this is dynamic > > when it is really not the case except in the situation of LAG members > going > > up/down. On the whole, this entire section is problematic from the sense > of > > routing stability. Likely I am misunderstanding the intent and, if so, > > please > > clarify. > > > > [NM]: Yes, I can see that the section overall reads contradictory after > > some recent updates. I have updated the section to be very clear as you > > suggested. > > > > KT> The updated text looks great and removes this ambiguity. Thanks. > > > > > > 854 7.2. Weighted Load-balancing to Multi-homed Subnets > > > > 856 EVPN Link bandwidth extended community may also be used to > > achieve > > 857 unequal load-balancing of prefix routed traffic by including > > this > > 858 extended community in EVPN Route Type 5. When included in > EVPN > > RT-5, > > 859 its value is to be interpreted as egress PE's relative weight > > for the > > 860 prefix included in this RT-5. Ingress PE will then compute > the > > 861 forwarding path-list for the prefix route using weighted paths > > 862 received from each egress PE. EVPN Link bandwidth extended > > community > > 863 MUST be encoded with "Value-Units = 0x01" to signal a > > generalized > > 864 weight associated with the advertising PE. > > > > <discuss-4> The MUST here is not clear to me. Is the intent that for RT5 > > only > > the Value-Units =1 MUST be used? If so, why? Also, why is it burried down > > here > > instead of being called out promimently in section 4.1? Or is it that if > > weights are used then the Value-Units MUST be 1. If so, isn't this > covered > > in > > section 4 already. Am I missing something? > > > > [NM]: In an EVPN IRB network use case, a subnet or a prefix is not tied > to > > any specific link or Ethernet Segment. Hence, when a weight is used with > > RT-5 prefix route, units should be 0x01. That said, I see that it’s > better > > to not make this a hard requirement. I have updated the test to specify > the > > recommended usage with “SHOULD”. Section 4.1 only defines the extended > > community. Its usage with different route types for different > applications > > is covered in subsequent sections. This section covers its usage with > > prefix routes. > > > > KT> Very clear now. Thanks for bringing in the SHOULD along with the > context. Just one nit s/lint/link > > > > > > > > 890 7.5. EVPN Link Bandwidth Extended Community in Non-EVPN Networks > > > > 892 While this document does not preclude future applicability to > > non- > > 893 EVPN networks, it considers usage and handling of EVPN Link > > Bandwidth > > 894 Extended Community specified in this document with non-EVPN > > routes > > 895 out of scope. > > > > <discuss-5> I would like to discuss why the use of an EVPN EC is being > left > > "open" for other BGP address families. That too when there is a generic > > Link > > Bandwidth EC in BGP that already exists to provide similar functionality. > > Should this document not explicitly limit the EVPN Link Bandwidth EC to > > EVPN > > only? If so, this needs to be clarified upfront where the EC is defined > and > > this section can then be removed. > > > > [NM]: This document defines the extended community for its usage in EVPN > > networks only. In other words, with respect to this document, EVPN Link > > bandwidth extended community is only meant to be used within EVPN network > > domain. That said, I see that this document does not necessarily need to > > comment on precluding or not precluding this possibility. I have removed > > the text accordingly. > > > > KT> Thanks for sharing that intent. The update in section 4 makes this > clear now. > > > > > > > > 897 7.6. Preference for EVPN Link Bandwidth in EVPN Networks > > > > 899 It is possible that a non-EVPN Link Bandwidth extended > > community such > > 900 as [BGP-LINK-BW] is leaked from an IP or IPVPN route into an > > EVPN > > 901 RT-5 towards an EVPN network. If an EVPN PE receives an EVPN > > route > > 902 with both the EVPN Link Bandwidth extended community specified > > in > > 903 this document and a non-EVPN Link Bandwidth extended community > > such > > 904 as the one specified in [BGP-LINK-BW], it MUST as default > > behavior, > > 905 prefer the EVPN Link Bandwidth extended community and handle > it > > as > > 906 per procedures specified in this document. In other words, > any > > non- > > 907 EVPN Link Bandwidth extended community is to be ignored if an > > EVPN > > 908 route is received with the EVPN Link Bandwidth extended > > community > > 909 specified in this document. > > > > <discuss-6> What if some routes to a destination have both and some have > > only > > the Link Bandwidth EC? Would a mix of the two ECs for different paths for > > the > > same destination route be acceptable? > > > > [NM]: BGP error handling in section 4.1.1 applies if EVPN Link BW is not > > received with all the paths. I added a reference to section 4.1.1. and > have > > also updated the text in this section to be clearer that a mix of EVPN > and > > non-EVPN Link BW cannot be used. > > > > KT> Thanks for the updates to clarify. > > > > > > > > 914 7.7. Interworking with Non-EVPN networks > > > > 916 In EVPN routing interworking use cases with IPVPN and > IPv4/IPv6 > > 917 routing, it is not beneficial to preserve the EVPN Link > > Bandwidth > > 918 extended community from EVPN routes to non-EVPN routes as the > > next- > > 919 hop is rewritten when a prefix learnt via EVPN RT-5 is > > advertised > > 920 into IPVPN or IP routing networks. Interworking procedures, > > 921 including preservation, cummulation or translation of EVPN > Link > > 922 Bandwidth extended community to address current or future use > > cases > > 923 are however considered beyond the scope of this document. > > Readers > > 924 are encouraged to refer to [EVPN-IPVPN] for interworking > > 925 specification. > > > > <discuss-7> There is no discussion in > > draft-ietf-bess-evpn-ipvpn-interworking > > that is related to handling of this EC propagation. On the contrary, that > > draft > > explicitly prohibits the propagation of all EVPN-specific ECs. I agree > with > > what is specified by the interworking document and I wonder why this > > document > > is not normatively prohibit propagation of EVPN-specific Link Bandwidth > EC > > into > > any other address-family. Also, I would have expected that this > > specification > > instead cover how the conversion is done between this and the > > BGP Link Bandwith ECs - if not in this document then where else does the > > WG plan > > to do it? Having introduced two ECs for practically the same thing (and I > > am not > > debating how we got to this stage), isn't the onus on this document to > > cover > > this aspect? Then, about the cumulation aspect as the NH changes across > the > > gateway PE but also for inter-AS option B, the document says out of scope >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
