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

[Jeffrey Haas <[e-mail]>]

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://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata/issues

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.

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.

-- Jeff






On Thu, Jan 16, 2025 at 12:03:13AM +0000, Linda Dunbar wrote:
> Jeff,
> 
> The draft has been uploaded: https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/
> 
> 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]>
> Sent: Friday, January 3, 2025 11:25 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,
> 
> 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]>> 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]>>
> Sent: Tuesday, December 17, 2024 11:26 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,
> 
> 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]>>
> > 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
>