É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 _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
