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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Jeff,

We published version 01, to address most of your concens.

Please see some additional comments in-line.


From: Jeffrey Haas <[e-mail]>
Date: Sunday, June 23, 2024 at 9:23 AM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



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 intent.

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.

[jorge] ok, I think ask the chairs for 5 minutes at IETF120 to discuss this and bring awareness. For the moment we can leave it as is, since there are implementations doing this. Thanks for the discussion.
Note that in the case of MAC/IP routes imported in MAC-VRFs, there are more tools than the ones given in RFC4271 to influence selection. See draft-ietf-bess-rfc7432bis-09<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#name-best-path-selection-for-mac>
The presence of the DGW extended community or the MAC mobility ext community will be evaluated even before the higher degree of preference (which goes before the D-PATH evaluation).


> > 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.
[jorge] hopefully the text makes it better now:

“Then routes with the numerically lowest left-most Domain-ID are preferred (only the Domain-ID is compared, and not the ISF_SAFI_TYPE). Hence, routes not tied for the numerically lowest left-most Domain-ID are removed from consideration. When comparing two Domain-IDs, the two six byte values are compared starting with the Global Admin field. The lowest value in the first differing byte between the two six byte values, is considered to belong to the "numerically lowest Domain-ID"”


> > 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.
[jorge] OK, added some text in the security considerations section, and also in section 4. We can always improve it at a later version.
Thank you Jeff!
Jorge


-- Jeff