[Idr] Re: revision idr-5g-edge-service-metadata to address Route selection issues #40 on the GitHub

[Jeffrey Haas <[e-mail]>]

Linda,

On Tue, Dec 17, 2024 at 06:01:37PM +0000, Linda Dunbar wrote:
> Thank you very much for the positive feedback!
> 
> Inserted below are the answers to your questions. What other steps are needed to get early allocation for Metadata Path Attribute?

> > From: Jeffrey Haas <[e-mail]>
> This roughly corresponds to RFC 4271, §9.1.1.  You're asking for the metadata preference to be calculated before this spot, right?
> [Linda] Yes, the metadata preference is intended to be calculated before the BGP route selection process, specifically at the same point as RFC 4271, Section 9.1.1

That's the text we'd need then.  Specifically, refer to that section.

> And does such calculation differ if it's coming from eBGP vs. iBGP?
> [Linda]  For iBGP: RR may pre-select routes by integrating the Metadata Path Attributes into their best-path computation and reflecting only the optimal route to their clients. If the RR uses the Add-Paths feature, multiple candidate routes can be forwarded, allowing ingress nodes to make final routing decisions based on policies that combine traditional BGP attributes and Metadata metrics.
> For eBGP: If policies allow Metadata propagation to eBGP peers, mechanisms like AS-Scope Sub-TLVs or route filtering can be applied to enforce boundaries.
> The difference of processing between iBGP and eBGP is standard behavior. Is it necessary to reiterate them in the document?

Pay particular attention to what §9.1.1 is telling you: The "degree of
preference" is calculated differently if it's learned from an iBGP peer or
an eBGP peer.

If your procedures are *after* this step is done, you are consistently using
that existing degree of preference and are unlikely to break iBGP.

If your procedure is *prior* to this step, it becomes necessary to do things
in the metadata selection mechanism that has been thought through very
carefully by the operator to not form persistant routing loops.  

The text for internal peers tells you:

:       If the route is learned from an internal peer, either the value of
:       the LOCAL_PREF attribute is taken as the degree of preference, or
:       the local system computes the degree of preference of the route
:       based on preconfigured policy information.  Note that the latter
:       may result in formation of persistent routing loops.

"Preconfigured policy information" can be used for "do your metadata
preference step here".

These things become much more important when you look at the multi-AS case.
While this feature is being touted as a "limited domain" feature, and
typically a single-AS one, what we're discussing is what happens when it
becomes multi-AS for whatever reason.

For multi-AS, you have to decide how iBGP is going to consistently choose
routes after a given ASBR chooses the routes potentialy from an eBGP source.
For normal eBGP, policy gets done at the edge, local-pref is set to reflect
relative degree of preference, and then tie-braking within the AS occurs
among routes with similar degree of preference based on the rest of the
procedures.

If you're calculating the value either above or using 9.1.1, you're
effectively picking the "degree of preference".  If that is to go into the
local-preference, then the calculation flattens the result into a
generically comparable uint32.

If you're leaving the existing 9.1.1 degree of preference alone and
calculating it immediately afterwards (which means local-pref can be a
strong override for route preference, which is how it is used by operators),
then your tie-breaking probably wants to begin in the Phase 2 tie-breaking
in §9.1.2.2.

You may want it to happen before step a for AS_PATH length for eBGP routes.
As an example, AIGP effectively does that.

I'd suggest studying the AIGP.  See in particular RFC 7311, §4.1 as an
example.

> The procedure for selection at the reflector is partially correct.  What's implied here is that the reflector may act as the deployment's "server" for the best paths.  This works fine if the server is the only way routers in the AS receive the routes mediated by the metadata attribute.
> 
> Where it may not work properly is if the reflector is receiving sets of routes from the rest of the AS, but the rest of the AS may be partially meshed on its own.  I.e., some routers can directly exchange iBGP routes without the reflector.  If it's the case that the reflector, acting as a "server" can come to a different answer than individual routers, you may end up with inconsistent routing.
> 
> Possible fixes:
> 1.      If centralized RR server is a model, recommend that routers ONLY peer through such server RRs.  Or, 2. Consistent procedure means the RR is just another node.
> [Linda] thanks for the suggestion. What do you think about the following paragraphs added to Section 6?
> 
> Centralized RR Model:
>       If the RR is acting as the deployment's "server" for best paths, it is recommended that routers in the AS ONLY peer through the RR. This ensures that the RR serves as the single point of policy-based computation, and all ingress routers receive consistent routes that account for the Metadata Path Attribute.
> 
> Consistent Distributed Model:
>       If routers in the AS are partially meshed and allowed to exchange iBGP routes directly, the RR must be treated as just another node. In this case:
>       All nodes, including the RR, must implement the same policy for integrating the Metadata Path Attribute and computing route preference.
>       The procedure for combining metadata and traditional BGP attributes should be consistent across all nodes, ensuring that all routers converge on the same "best" path when presented with the same set of routes and metadata.

That text works.

-- Jeff