Do you need to "convert" to nanos and back? Why? This should work, I think:

et := b.cfg.BaseEjectionTime * addrInfo.ejectionTimeMultiplier
met := b.cfg.BaseEjectionTime + b.cfg.MaxEjectionTime
curTimeAfterEt := now().After(addrInfo.latestEjectionTimestamp.Add(time.Duration(min(et, met)))

min might need to change; change it or make another min that operates on isvccfg.Durations if you have other needs for an int64 verison of min.

Also, I think this might be even clearer:

ejectAfter := b.cfg.BaseEjectionTime * addrInfo.ejectionTimeMultiplier
if max := b.cfg.BaseEjectionTime + b.cfg.MaxEjectionTime; ejectAfter > max {
  ejectAfter = max
}  // or use `min` from above if you prefer; I don't have any preference.

ejectTime := addrInfo.latestEjectionTimestamp.Add(time.Duration(ejectAfter)) // explains the value after math

if now().After(ejectTime) { // instead of storing bool then checking it
  b.unejectAddress() // uneject after ejection time?
}

I'd prefer keeping the logic as is since this more closely aligns with the language from the gRFC describing the algorithm. However, I do like your suggestion about the variable names (i.e. ejectAfter and ejectTime). I will change to those.

Oh wait, var names only apply to your suggested. Keeping it, but switching min and getting rid of conversions.

Oh, I remembered why I converted, you can't multiply a time.Duration * int. Needs to be converted to nanos to have that operation make sense.

Can you normalize these in case we decide to be more restrictive in Duration parsing one day, we won't need to come back and change these?

E.g. "0.050s" - 3/6/9 digits after decimal & don't omit leading digit.

Done.