[bess] Mohamed Boucadair's Discuss on draft-ietf-bess-evpn-unequal-lb-31: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

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