Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-evpn-unequal-lb-31: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Neeraj, Ali, Jorge, John, Avinash, and Samir, Thank you for the work put into this specification. I’m planning to ballot YES. Thank you for the detailed discussion about overall theory of operation and adequate operational considerations through the document (including in Section 8). Please find below some easy DISCUSS points: # SYSLOG CURRENT: * Implementation SHOULD alert the users via syslog when an Please add a normative reference for syslog. # Monitoring CURRENT: * Operators MAY monitor the traffic flow distribution and DF election distribution across the egress PE set to ensure that the implementation is working as expected. Given the impact on delivered traffic, I don’t think MAY makes sense here. I would change to “are RECOMMENDED”. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Design alternative Special thanks for Appendix A as it answered a comment I had about that exact points. Please add a citation early in the document (Introduction, typically) to refer to that section to help readers like me :-) # Mix of OPS and Protocol considerations I would move text such as the following (and similar) to Section 8: CURRENT: When a generalized weight is used, the operator MUST ensure consistent interpretation of the advertised value across all egress PEs associated with the Ethernet Segment. This requirement applies even when the egress PEs span multiple routing domains or Autonomous Systems. # Real-time Available Bandwidth I appreciate that this is out of scope. However, we need at least to have caution (as OPS considerations) that too frequent/dynamic re-adjustement may lead to instability and that guards should be in place. # Section 7.6: "is recommended" is redundant with "SHOULD" Please consider this change: OLD: It is recommended that an implementation SHOULD provide a way to NEW: Implementations SHOULD provide a way to # Value Unit Checks CURRENT: * In order for the solution specified in this document to function correctly, implementation SHOULD ensure that EVPN Link Bandwidth Extended Comminiuty is being advertised with same "Value-Units" across all PEs. ## I would add that provisioning/monitory at the operator side should track this as well. # Nits ## Section 7.3 OLD: an optional propcedure NEW: an optional procedure ## Section 7.7 OLD: the the EVPN NEW: the EVPN ## Section 8 ## s/Comminiuty/Community Cheers, Med _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
