Skip to main content

Early Review of draft-ietf-bess-evpn-mh-split-horizon-04

Request Review of draft-ietf-bess-evpn-mh-split-horizon
Requested revision No specific revision (document currently at 08)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-04-07
Requested 2023-03-14
Requested by Stephane Litkowski
Authors Jorge Rabadan , Kiran Nagaraj , Wen Lin , Ali Sajassi
I-D last updated 2023-04-07
Completed reviews Genart Early review of -08 by Jouni Korhonen
Rtgdir Early review of -04 by Himanshu C. Shah (diff)
Assignment Reviewer Himanshu C. Shah
State Completed
Request Early review on draft-ietf-bess-evpn-mh-split-horizon by Routing Area Directorate Assigned
Posted at
Reviewed revision 04 (document currently at 08)
Result Ready
Completed 2023-04-07
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.