Early Review of draft-ietf-bess-evpn-l2gw-proto-03
review-ietf-bess-evpn-l2gw-proto-03-rtgdir-early-ceccarelli-2023-06-29-00

Hello, this is the first time i do a RTG-DIR review using the new interface. I
hope all the fields are properly filled automatically and mails sent
accordingly.

Please note that the draft in in WG last call and an early review was
requested. I'll assume this is a WG last call review.

All in all the document is almost ready for being progressed. I just suggested
few improvements for better readability and understanding.

Here are my findings:

- Abstract:
1) I would suggest rephrasing into:
"The existing EVPN multi-homing load-balancing modes do not adequately
represent ethernet-segments facing access networks with Layer-2 Gateway
protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. This document defines a
new multi-homing mechanism to support these loop-preventing Layer-2 protocols"

2) My MPLS-TP is a bit rusty, but can it be considered a layer 2 protocol? and
is it loop-preventing?

- Introduction:
1)" Existing EVPN Single-Active and All-Active redundancy modes" add a
reference to where they are defined. 2) you should also add a reference to
G.8032, (M)STP, REP etc 3) same comment to MPLS-TP 4) the rest of the section
is well written and understandable. It would be nice to have a small
description of what a VLAN flow is to better explain why the need to have a
flow active on a PE only but not all on the same.

- 2. Requirements
1) Again references to EVPN L2GW would help. Where do the "following rules"
come from? 2) missing ESI expansions

- Section 3
1)i'd suggest finding a better way to show that the loop is open between CE4
and CE2. On first look i thought the simbol meant that the can be there many
other nodes between CE4 and CE2. 2) it would be nice if the part of section 3
that comes before 3.1 introduced not only the example network but also the
components of the solution. i.e the single-flow-active redundancy mode, fast
convergenge etc

- Section 3.1
1)"Additionally, the reachability between CE1/CE4 and CE2 is achieved with the
forwarding path through the EVPN MPLS/IP core side" does it mean via PE1-PE2?
2)"Therefore, aliasing of [RFC7432] Section 8.4 cannot be performed by PE3."
suggest to rephrase in: Therefore the Aliasing procedure, described in Section
8.4 of [RFC7432] cannot be performed by PE3.

- Section 3.3
I dont' understand why an alternative solution (3.3.1) is described in the
backwards compatibility section. Why not pulling it out from 3.3 and describing
it as an alternative solution with limitations?

- Section 4
This section needs to be alaborated a bit more. As is, it is saying the same
things as the IANA considerations. in addition to that if the document defines
RED 10, why in the IANA considerations you have 00, 01 and 10?