[bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-mh-split-horizon-10: No Objection

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-mh-split-horizon/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-mh-split-horizon-10

Thank you for the work put into this document. I found the writing quite
convoluted and not easy to follow, especially about what is modified from RFC
7432 and others.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Jeff Zhang for the shepherd's write-up including the WG
consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Relevance to BESS ?

Wondering whether this work fits well within BESS charter; some EVPN (e.g.,
VXLAN) are deployed without using BGP and still require split-horizon (if not
mistaken).

Strongly suggest to add BGP in the title of this document (and abstract) to
make it clear that this is about BGP and not EVPN.

## Abstract

`to select the appropriate Split Horizon procedure` does it mean that the other
procedure is *not* appropriate or simply *less* appropriate ?

## Section 1

Suggest to clearly define "split horizon" rather than simply burry it in `Split
Horizon procedures employed to prevent looped frames`.

## Section 1.1

s/link-local broadcasts/link-layer broadcasts/ ? what about other
unknown/multicast traffic ?

Several acronyms (e.g., "BUM") keep being expanded in the following sections.

## Section 2.1

Just wondering where the RED bits are defined (they seems to overwrite the
single-active bit of section 2), please add a reference to RFC 7432.

Also, is there a reason why the SHT bits are not adjacent to the RED ones ?

# NITS (non-blocking / cosmetic)

## Section 1.1

s/ethernet/Ethernet/ (possibly in other places)

Be consistent "Segment *R*outing" vs. "Segment *r*outing" ;-)

## Section 2

Please add markers for 10, 20, ... on figure 1