I have two easily fixed issues and one that may need a bit of chat:

#1 There are a few places with (probably wrong) security text that
really would be better fixed. Those include:

- "(such as TLS, SSL, etc.)" occurs a few times, but SSL just isn't a
  thing we'd recommend
- "(TLS, DTLS, etc.)." seems like a variation of that but is there a
  real DTLS option here?, 

I'd suggest fixing all those to just say TLS maybe with a reference
to BCP 195, but the exact fix should be fairly obvious to anyone who
is familiar with how TLS can really be used in this context. (I'm not
asking that you say "you MUST use TLS" here, just that you say what
can actually be done with realistically available tooling.)

#2 There's also a really 20th century bit of (probably wrong)
security text "(DES, 3DES, or AES)" - again checking with someone
familiar with how IPsec can be useful here should result in text that
makes sense.

#3 I'm just not clear on the security model here. I recognise that
this is just an informational document but I did not understand how
one could avoid a trust-on-first-use (TOFU) or leap-of-faith if one
sets up a system as described, and I doubt that TOFU is what everyone
setting up such systems would want. I suspect that may be down to
just not having quite enough text about how to configure security
things here, but am unsure and a quick glance at the references
([SECURE-EVPN] and RFC9012) didn't clarify that for me. (Mostly as
those are more complex than the time I had to spend on this today;-)
It could be that I'm just not understanding the text, or that there
are some more security considerations or other text to add, e.g. to
say how to avoid TOFU, should that be what one wants, but I'm just
not sure based on the text as-is. (BTW, if the reality is that nobody
actually has a "zero-touch" way to configure IPsec, or if TLS just
isn't usable, then it'd be better to say that than to sorta-pretend
those are usable, but again, I don't know what's realistic here
today.)