Hi Authors, Please find my review of the document.
Nits to be fixed: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-03.txt Section 1.1: * s/it MUST add a link to both PE1/it must add a link to both PE1/ => this is not a normative statement * Also, avoid upper case for ANY or ONLY. It doesn't bring anything. * ECMP usually does not take care of flow bandwidth but rather than uses static hashing. ECMP is more a goal rather than a strong reality. I think the text should try to bring more shades between theory and reality. As an example, I found the statement "This traffic loss is due to the fact that PE1 and PE2 will continue to attract equal amount of CE1 destined traffic from remote PEs" too strong as remote PEs will drive the flow loadbalancing based on their hashing config and will try to provide equal cost loadbalancing without any guarantee, at least they will distribute flows equally, not traffic. * s/remote hosts MUST also/remote hosts must also/ => I agree this is the goal, but we are not really specifying anything here. Section 1.2: * You should mention that people usually implement "min-link" on LAGs to overcome this issue. However this creates an overall loose of BW . Section 3.1: s/a additional/an additional/ s/EXT-COMM/extended community/ => please do it across the document. There is one instance of [BGP-LINK-BW] that is not displayed as an hyperlink, should be an issue with source file. Is the goal to have LINK-BW doc being modified ? If yes, we will not progress this doc until LINK-BW is ready. Today the doc is expired. This is a major issue that you should solve before moving forward. Section 3.2: s/A receiving PE should use/A receiving PE SHOULD use/ Do we need to standardize how we compute normalized weight ? Can't this be a local behavior as long as computation achieves the goal ? Why using "receiving PE MUST compute" while first statement was a "SHOULD" ? Again, please avoid using upper case words, it brings confusion. Can we rephrase the last paragraph: "Normalized weights for a particular ESI MUST NOT be computed until a link bandwidth attribute is received on all BGP paths of the associated Route Type 1. When one or more BGP paths of the route type 1 does not have the link bandwidth attribute, regular ECMP procedures MUST be used." Can't we consider an advertisement without community as W=1 instead of moving everything back to ECMP ? What would be the side effect ? Section 4: s/BW may/BW MAY/ Section 4.1: [RFC8584] miss its hypertext link. Did you get an early allocation for your bit number ? If not, please make it TBD. Section 4.2: You should better describe the modifications done in RFC7432 and mention clearly that you modify RFC7432 behavior. Using similar wording and sentences will help. Basically, you should explain that a PE may have multiple ordinals and mod is performed against a new N value. Section 4.3: [RFC8584] miss its hypertext link. [EVPN-PER-MCAST-FLOW- DF] miss its hypertext link Section 4.3.1: [EVPN-PER-MCAST-FLOW- DF] miss its hypertext link s/bandwidth increment must/bandwidth increment MUST/ s/compute a random/computes a random/ Section 4.3.2: Section uses "affinity" while RFC8584 does not have this vocabulary. As you are modifying RFC8584, please use same vocabulary. What is changed is not fully clear. Section 4.3.3: "Same also applies to use"... would be good to mention this in 4.2 in that case Section 4.4: This document is still an individual draft. Your doc will be blocked until the WHRW becomes RFC... I don't think it is a good idea. You should probably remove this section and covers it in WHRW or another draft. Same remark will apply to MCAST-FLOW-DF. Section 4.5: Is there any reason to prefer the highest BW link ? This is not the goal of the draft. If you want to keep UCMP, you should make Pref-DF not compatible with LBW which means that if it is advertised, PEs don't care about LBW community. Section 6: I can't parse: "A host MAC... control plane o Host" Is there an indentation issue ? IANA: You should have an IANA section for your bit allocation. SECURITY: Should have a security section.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
