Skip to main content

BGP EVPN Multi-Homing Extensions for Split Horizon Filtering
draft-ietf-bess-evpn-mh-split-horizon-11

Note: This ballot was opened for revision 10 and is now closed.

Gunter Van de Velde
Yes
Erik Kline
No Objection
Jim Guichard
No Objection
Comment (2024-07-29 for -10) Sent
Thank you for the document. No substantive comments other than the following (nits line numbers included for latest version):

98	   *  Segment Routing with IPv6 data plane (SRv6), where the relevant
99	      EVPN procedures are specified in [RFC9252].  SRv6 is specified in
100	      [RFC8986].

Jim> RFC8986 specifies SRv6 Network Programming not SRv6 itself. The correct references should be RFC8402 and RFC8754 (SRH).

190	   *  SRv6: Segment routing with an IPv6 data plane, [RFC8986].

Jim> Again, incorrect reference.
Mahesh Jethanandani
No Objection
Comment (2024-08-17) Sent
Thanks for addressing my comments.
Murray Kucherawy
No Objection
Comment (2024-08-07 for -10) Sent
I support Roman's DISCUSS, and I have the same (related) question as Orie.

Section 1.1 defines "SR-MPLS", but it's not used in this document after that.  (It is present in Section 1.)  "VNI" and "Virtual Network Identifier" are also defined but never used.
Orie Steele
No Objection
Comment (2024-08-04 for -10) Sent
# Orie Steele, ART AD, comments for draft-ietf-bess-evpn-mh-split-horizon-10 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-mh-split-horizon-10.txt&submitcheck=True

I support Roman's discuss.

## Comments

### Any type restrictions for IETF Review?

```
721	   New registrations in the "EVPN ESI Label Extended Community Flags"
722	   registry will be made through the "IETF Review" procedure defined in
723	   [RFC8126].  This registry is located in the "Border Gateway Protocol
724	   (BGP) Extended Communities" registry.
```

RFC8126 notes that IETF Review states:

```
Unless otherwise specified, any type of RFC is sufficient (currently
Standards Track, BCP, Informational, Experimental, or Historic).
```

In particular are informational and experimental type RFCs acceptable for this use case?
Paul Wouters
No Objection
Roman Danyliw
(was Discuss) No Objection
Comment (2024-08-22) Sent
Thank you to Jouni Korhonen for the GENART review.

Thank you for addressing my DISCUSS feedback.
Warren Kumari
No Objection
Comment (2024-08-06 for -10) Not sent
Other than supporting Roman's DISCUSS, and Eric's comments, I have nothing to add...
Zaheduzzaman Sarker
No Objection
Comment (2024-08-07 for -10) Sent
Thanks for working on this specification. I have no comments from transport protocol points of view.

However, I am supporting Roman's discuss and also noting that IANA is not OK.
Éric Vyncke
No Objection
Comment (2024-08-06 for -10) Sent
# É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