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

[Linda Dunbar <[e-mail]>]

Jeff,

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?

Linda

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
Sent: Friday, December 13, 2024 10:35 AM
To: Linda Dunbar <[e-mail]>
Cc: Sue Hares <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: revision idr-5g-edge-service-metadata to address Route selection issues #40 on the GitHub

Linda,

Thanks for your patience for this reply.

On Wed, Dec 04, 2024 at 07:08:59AM +0000, Linda Dunbar wrote:
> Jeff,
>
> We added a new section (6. Policy Based Metadata Integration) to describes how the information carried in the Metadata Path Attribute is integrated into the BGP route selection process to address the Route selection issues #40 on the GitHub.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-5g-edge-service-metadata%2F&da
> ta=05%7C02%7Clinda.dunbar%40futurewei.com%7Ce184ee43394e4188102c08dd1b
> a4d0ee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638697116894649834
> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Peh
> 9D1Hc%2F4fnYfaUk%2BubwnnS9QpEuYDwpAojDWWv6JA%3D&reserved=0
>
> Can you please check if the new section description is enough?

The contents in the new section 6 are an excellent step in the right direction.  Thanks.
[Linda] Thank you.

In particular, this is the first time it's been clearly articulated that:
1. The input to the decision process for the metadata mechanism is at the top of the BGP route selection process.
2. That tie-breaking for it subsequently follows to normal BGP tie-breaking rules.

(Recall that I've asked a few times "where in the process does this happen?"
This was the needed answer.)

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

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?

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.

-- Jeff