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

[Linda Dunbar <[e-mail]>]

Jeff,

Thank you for raising all those issues-addressing them has significantly improved the quality of the draft.

Inserted below are responses to your comments.

Linda

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
Sent: Friday, January 17, 2025 7:50 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 posting -26.  It addresses the issue related to route selection.

I have two issues below but it's possible the one substantive one will be resolved with some clarifying text.  Meanwhile, Sue will be starting a WG review period on the current versoin of the draft.

I've reviewed the github tracking issues:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-wg-idr%2Fdraft-ietf-idr-5g-edge-service-metadata%2Fissues&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C7943e6e3ab954ce0183208dd370e960c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638727257986854658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kkTQJpS1cSpAe9DvIZ3OaDcpOMj4%2BUtrsbIKkqM8ayk%3D&reserved=0

I've closed out the majority of them.  Progress!

In reviewing the originally opened issues, two linger:
1. Does the WG find the text about BFD use to be clear?  This can be determined during the review period Sue will be calling as part of moving the draft forward.

2. I have some, potentially minor, concerns about section "4.3.2. BGP UPDATE with standalone Site Availability Index".  The procedures for how it works isn't 100% clear to me.

Section 4.3.1 says that the routes from egresses have next-hop-self set along with a metadata attribute with a site availability index.
[Linda]  The Standalone Site Availability Index update enables a single BGP UPDATE message to efficiently signal the availability status of a group of routes sharing a common Site-ID, eliminating the need for multiple updates for each affected route.
Section 4.3.1 establishes the association between a Site-ID and a route, allowing ingress nodes to recognize which routes belong to the same site. Section 4.3.2 then enables the ingress node to apply a Standalone Site Availability Index  update to all routes linked to that Site-ID, ensuring a streamlined and scalable way to propagate site-wide availability changes.

Section 4.3.2 says that when we get a route with the egress router's loopback (the self nexthop) and it has ONLY the availability TLV, it's used to update the availability for all dependent routes sharing that site index.

Normal BGP procedure would have this route in 4.3.2 be a routing update for that loopback address in the RIB.  And similarly the expectation is that ALL of the attributes associated with that route are replaced with what is received.

Is it your intention that the procedure in 4.3.2 change the update procedures for BGP for this set of path attribute conditions?  Or is it the case that the NLRI for the loopback is signaled in some sort of way such that you're not impacting it?

In a terser form as an example:

Egress router, E sends an IPv4 Unicast route for egress destination
R1 - 192.0.2.1/32.  In that update it includes a nexthop and also a fully populated metadata attribute.

R1 is later sent with the partially populated metadata attribute.  Is it the desire that R1 is not replaced in the receiver's adj-rib-in and displacing the other route properties?  You seem to signal this in the text, "The BGP UPDATE with a standalone Site Availability Index is NOT intended for resolving NextHop."

If so, this isn't what normal BGP does.

[Linda] Do you think changing the text to the following can make it clearer?

4.3.1. Associating Routes with a Site-ID
To enable efficient site-wide availability updates, each route advertised by an egress router is associated with a Site-ID using the Site Physical Availability Index Sub-TLV (with RouteFlag-I=1) within the Metadata Path Attribute. The Site-ID represents a physical location, such as a data center, pod, or rack row.

When an egress router advertises a route, it includes:
-       Its loopback address as the next-hop, ensuring traffic is forwarded through it.
-       The Site Physical Availability Index Sub-TLV (RouteFlag-I=1), linking the route to a Site-ID without applying an availability percentage.
This Site-ID association allows ingress routers to track groups of routes belonging to the same site, enabling a single update to reflect site-wide availability changes instead of sending per-prefix updates.

4.3.2. BGP UPDATE with Standalone Site Availability Index
Once routes are associated with a Site-ID (as per Section 4.3.1), an egress router can use a standalone Site Availability Index (SAI) update to efficiently signal site-wide availability changes without modifying individual route advertisements.

Standalone SAI Update Mechanism:
-       The egress router sends a BGP UPDATE using its loopback address as the NLRI, but without any specific prefix announcements.
-       The update contains only the Site Availability Index  within the Metadata Path Attribute, reflecting the current availability state of the entire site.
-       Ingress routers apply this availability information to all previously learned routes associated with the same Site-ID, adjusting path selection as needed.
Key Processing Considerations:
-       The standalone Site Availability Index update does not alter existing next-hop resolution or replace the original attributes of routes in Adj-RIB-In.
-       It acts as an auxiliary metadata update, allowing ingress routers to adjust preference or deprioritize routes impacted by site degradation.
-       This approach significantly reduces control-plane churn by enabling a single update to reflect site-wide conditions, instead of requiring multiple per-prefix updates.
By leveraging the Site-ID association from Section 4.3.1, the standalone Site Availability Index update provides a scalable and efficient way to propagate real-time availability changes for an entire site while preserving standard BGP route selection mechanisms.


-- Jeff






On Thu, Jan 16, 2025 at 12:03:13AM +0000, Linda Dunbar wrote:
> Jeff,
>
> The draft has been uploaded:
> 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%7C7943e6e3ab954ce0183208dd37
> 0e960c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638727257986877794
> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zv%
> 2BVQWhiJf2F7cprai2GK%2BRPnISBvIWvCAOrKxQ5l10%3D&reserved=0
>
> What is the next step to get the early allocation for the metadata path attribute?
>
> How about WGLC?
>
> Thank you,
>
> Linda
> From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, January 3, 2025 11:25 AM
> To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
> Cc: Sue Hares <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: revision idr-5g-edge-service-metadata to address Route
> selection issues #40 on the GitHub
>
> Linda,
>
> Sorry for the reply latency. I had missed this one next to a "recall" generated by your mail client.
>
> The text below would be fine and I think addresses the issue I flagged.
>
> -- Jeff
>
>
>
> On Dec 17, 2024, at 4:17 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
> Jeff,
>
> Thanks for the detailed explanation. Do you think adding the following sentences to Section 6 is good enough?
>
> 6. Policy-Based Metadata Integration
> This section describes how the information carried in the Metadata Path Attribute is integrated into the BGP route selection process. RR and Ingress nodes can incorporate metadata into their route selection, depending on the network deployment and local policy configuration. To ensure compliance with §9.1.1 of [RFC4271], metadata-based preferences must be applied after the LOCAL_PREF attribute is set for iBGP routes or after local policies are applied for eBGP routes.
>
> Linda
> -----Original Message-----
> From: Jeffrey Haas <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
> Sent: Tuesday, December 17, 2024 11:26 AM
> To: Linda Dunbar
> <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
> Cc: Sue Hares <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>;
> [e-mail]<mailto:draft-ietf-idr<mailto:[e-mail]<mailto:draft-ietf-idr>
> [e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>
> Subject: Re: revision idr-5g-edge-service-metadata to address Route
> selection issues #40 on the GitHub
>
> 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]<mailto:[e-mail]<mailto:[e-mail]<mailto:[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
>