[bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

[Jeffrey Haas <[e-mail]>]

Jorge,

I'm responding to the second part of the point since it covers my concern:


On Tue, Jun 18, 2024 at 01:35:09PM +0000, Jorge Rabadan (Nokia) wrote:
> > In section 4.1, the cited rules for route selection change are:
> > 
> > :    If none of the tie-breaking rules up to (and including) rule 5
> > :    produces a single route, the router compares the D-PATH attribute in
> > :    the remaining candidate routes:
> > :
[...]
> > A consequence of this second step is that the configured domain ID, when
> > routes are redistributed between domains, becomes a "hard yank" to influence
> > routes to pick a specific domain.
[...]
> > This is somewhat similar to taking BGP's BGP Identifier check at the *end*
> > of the route selection process and moving it near to the top.  I suspect
> > this is not what you want.
> [jorge] Yes, that’s the intend.

Huh.  Well, I'm glad I'm at least I'm understanding this.

I suspect this is a Bad Idea.  So, consider this flagging it as a concern
that I'd suggest BESS discuss and that the AD's conciser in their review.

Part of my motivation for discussing the BGP Identifier as a tie-breaker is
that service providers are known to play games with this bit of BGP
configuration in circumstances solely to try to capture traffic when route
selection otherwise falls to this point of the Decision Process.

For normal BGP, it's so low in the list that if it's a major concern, there
are plenty of other ways to bias the traffic using route selection.  

However, as documented for EVPN IPVPN procedures, this means that in
inter-provider scenarios you're encouraging people to play games with the
values they use in order to bias route selection, and thus traffic.  Unlike
normal BGP, it's high enough that there's very little tooling to avoid this.

As discussed in the prior mail, while the D-PATH values are "opaque" but
have common configuration practice, that practice may not be enough to avoid
such games.

I understand that for this D-PATH feature that the providers should be
"mutually cooperating" and thus this may be a trivial or even silly concern.
But if it ever becomes competing providers, this becomes a conversation
about money.

> > Other issues:
> > 
> > "numerically lower" isn't clear with respect to a domain-id, especially
> > with regard to the ISF_SAFI_TYPE component of it.  Is that used?
> [jorge] no, it is not used. The text refers to the domain-ID which is excluding the ISF_SAFI_TYPE. But if you think it is not clear, we can add some text of course.
> > Ignoring
> > that, is the result the same as running C's memcmp() on the two six byte
> > values?
> [jorge] yes, that was the idea. We can clarify.

It'd be helpful if you did.  I'm glad I came to the appropriate conclusion
as a semi-informed reader, but for these sorts of steps having the algorithm
explicitly written out can remove doubt.

> > As discussed in the context of the ipvpn interworking draft, changing route
> > selection after the fact is messy and could in some cases lead to
> > inconsistent selection within a network.  However, for the route types that
> > this procedure is recommended for, have you convinced yourselves that
> > inconsistent selection is fine?  Or will your recommendation be, similar to
> > the ipvpn interworking draft, that the entire deployment must be upgraded to
> > support the new procedure?
> [jorge] we can add similar text with regards to upgrades if the WG thinks so, but this is a more constrained environment. There is no leaking into any family that facilitate the attribute escape, and the GWs only redistribute MAC/IP routes in the case of EVPN L2 ELAN, and AD per EVI routes in the case of EVPN VPWS. So I don’t think we as authors have any concern, but I agree with your points that we need to provide text warning the implementer about the potential consequences of inconsistent best path selection.

Some explicit text would be appreciated.  While escape isn't expected, we're
partially having some of this review because escape has been observed from
existing implementations.

-- Jeff