Early Review of draft-ietf-bess-evpn-mh-split-horizon-04
review-ietf-bess-evpn-mh-split-horizon-04-rtgdir-early-shah-2023-04-07-00

This draft provides a choice of split-horizon method to use which especially is
useful when multiple encapsulations are supported. The Split-Horizon-Type (SHT)
is introduced as 2-bits value in the flag field of ETH-AD per ES route. The
document is very well written. Every single discrepancies that may occur, along
with backward compatibility, is explained and what actions to take are covered.
This is important for interoperability. I have a minor comment on last
paragraph of section 2.4, as below.

The paragraph -
If an NVE changes its operational SHT value from 01 to 00 (as a
   result of a new non-upgraded NVE present in the ES) and it previously
   advertised a zero ESI Label, it MUST send an update with a non-zero
   valid ESI Label, unless all the non-upgraded NVEs in the ES support
   Local Bias only.
--
“unless all the non-upgraded NVEs in the ES support Local Bias only”
This last sentence needs clarification.
Let us say there were N1, N2 and N3 nodes in the ESI and they all advertised
SHT as 01 (local bias). Now a new “non-upgraded” (i.e. old SHT unaware) node
also joins the same ESI, all newer nodes N1 to N3 will have to re-advertise
with non-zero ESI label.

…but may be not - if all SHT-unaware NVEs in ES are Local Bias (say VXLAN)?

It would be great if this can be clarified with an example.
In general, wherever possible, give examples - that would make the document
even more easier for implementers to follow.

All-in-all, very nicely written document.

Thanks,
Himanshu