[Idr] Re: The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"

["Stephane Litkowski (slitkows)" <[e-mail]>]

Hi Robert,

If no change in RFC9252, then things will not work when NH is not set to an IP address belonging to the locator of the SID, but it will not. This is authorized by the RFC as you mentioned, and this should not prevent to get proper metric.
We should not ask users to set this manually.

>> Again, this is updating RFC4271.
>>Completely NOT

This is your point of view, but I have a different one, the text of RFC4271 is clearly outdated and draft-ietf-idr-bgp-bestpath-selection-criteria already tried to update it.


From: Robert Raszuk <[e-mail]>
Sent: Monday, July 6, 2026 9:29 PM
To: Stephane Litkowski (slitkows) <[e-mail]>
Cc: MEANS, ISRAEL L <[e-mail]>; Jeffrey Haas <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"

HI Stephane,

I think you misunderstood.

> Changing RFC will make current implementations non-compliant

You do not need to touch RFC9252. It is fine and allows operator freedom to send in NEXT-HOP what makes sense.

>For the SR Policy the BGP registration with RIB <NEXT-HOP, color> tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.
>For SR-MPLS Flex-Algo again the BGP registration with RIB <NEXT-HOP, Flex_Algo>  tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.

> Again, this is updating RFC4271.

Completely NOT. And this also applies to tunnel-encaps RFC ... basically when BGP registers HEXT-HOP it can retrieve from the other attributes the context meaning: color, Flex_algo, tunnel etc ...)

Thx,
R.





On Mon, Jul 6, 2026 at 9:19 PM Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Changing RFC will make current implementations non-compliant (as well as deploymebts) and will require code changes to be (and behavior changes as well for customers). It does not come for free (for vendors or operators).

BTW, the discussion also applies to tunnel-encaps RFC, not just SRv6 services.

>For the SR Policy the BGP registration with RIB <NEXT-HOP, color> tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.
>For SR-MPLS Flex-Algo again the BGP registration with RIB <NEXT-HOP, Flex_Algo>  tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.

Again, this is updating RFC4271.

Brgds,

Stephane


From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 6, 2026 9:11 PM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"

HI,

Well my take is that we should divide the problem space and use optimal solution to each of the three you are highlighting.

On first one I think we have full agreement that placing/using service SID in NEXT-HOP field solves the issue. And this is already allowed by the spec (via normative "MAY") so no change of the spec is needed. Likewise there should be no changes to implementations since SRv6 SID is IPv6 address anyway and what operator chooses to use as NEXT-HOP should be a configuration option.

And in regard to your comment it is actually this draft which makes a requirement for pretty severe implementation change not my suggested solution.

For the SR Policy the BGP registration with RIB <NEXT-HOP, color> tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.

For SR-MPLS Flex-Algo again the BGP registration with RIB <NEXT-HOP, Flex_Algo>  tuple solves the requirement to evaluate BGP Best Path with a different then default metric to NEXT-HOP.

So why do we need this draft ?

Thx,
R.

On Mon, Jul 6, 2026 at 6:36 PM MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:
Robert,


We are on the same page on the goal but the proposal has three gaps the draft addresses and this approach does not.



For SRv6, placing the SID in MP_REACH_NLRI NEXT_HOP achieves the same functional outcome as the draft’s resolution tuple framework for that specific case. However, RFC 9252 currently defines NEXT_HOP as a valid IPv6 address of the advertising PE, not the SRv6 SID. Changing this requires a RFC 9252 revision plus implementation changes across all deployed BGP stacks  a more disruptive standardization effort that would remain an incomplete solution since it does not address SR Policy or SR-MPLS Flex-Algo in any case.



For SR Policy the proposal does not apply. SR Policy is selected via {NEXT_HOP, color} and the Binding SID is a local construct on the headend PE, not a globally routable address suitable for use as a BGP NEXT_HOP by remote PEs. This case requires the resolution tuple approach regardless of how SRv6 NEXT_HOP encoding is handled.



For SR-MPLS Flex-Algo the proposal also does not apply. SR-MPLS Flex-Algo SIDs are MPLS labels with no IPv6 address equivalent, making NEXT_HOP substitution structurally inapplicable for this case.



To directly answer your question: if the SID were placed in NEXT_HOP for SRv6, the SR Policy and SR-MPLS Flex-Algo cases would remain unresolved. The draft addresses all three within existing encoding without requiring RFC 9252 revision or BGP UPDATE format changes. The resolution tuple framework requires additions to the BGP/RIB interface specification only, which is a significantly narrower implementation scope than the alternative you propose.

Israel


From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 6, 2026 at 9:18 AM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"
This Message Is From an External Sender
This message came from outside AT&T.

HI,

On the first point -

The primary consideration I am making is no change to BGP. So if you put SID in the place of NEXT_HOP in MP_REACH_NLRI you are solving the main reason for this draft to exist.

If not please kindly elaborate what would be still missing if SID is in the NEXT_HOP itself and all BGP implementations will use it (perhaps with color ot flex-algo) to get metric or track reachability in a proper RIB context ?

Are we on the same page ?

Thx,
R.





On Mon, Jul 6, 2026 at 6:11 PM MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:
Robert et al.,


On your first point, agreed. When the SRv6 SID and BGP NEXT_HOP are co-located on the same node as required by RFC 9252 for SRv6 and IGP prefix origination constraints per the applicable IS-IS and OSPF specifications as applied in RFC 9350 for Flex-Algo SID reachability in the applicable topology implicitly satisfies NEXT_HOP reachability, and a single SID resolution check satisfies both forwarding path validity and service endpoint reachability. The draft should state this normatively.



On your second point, the observation is architecturally noted but describes a fundamental restructuring of the current Standards Track specification per RFC 9252 that is outside the scope of the current work.



The technical objections raised in this thread have been resolved. The authors should capture the resolution tuple framework, the co-location requirement, and the SID reachability simplification normatively in the next revision, along with a response to the chairs’ pre-adoption information request.

Israel

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Saturday, July 4, 2026 at 3:09 AM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"
This Message Is From an External Sender
This message came from outside AT&T.

HI,

> For RFC 9252 VPN services, the NEXT_HOP is the service endpoint identifier,
> but whether SID reachability on the same node implicitly satisfies the NEXT_HOP
> reachability requirement is an open question the authors should resolve normatively
> rather than leave implementation-specific.

Why would it not satisfy it ? Please observe that service related data (especially those related to construct proper forwarding paradigms) should be part of NLRI and not sit on the side of an UPDATE Message.

Regards,
R.







On Sat, Jul 4, 2026 at 3:51 AM MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:

Robert,

For SRv6 and Flex-Algo, the SID is registered as the forwarding resolution key, resolving over the appropriate constrained topology, with path invalidation on resolution failure. For SR Policy, {NEXT_HOP, color} is the registration tuple, from which the SR Policy database returns the associated metric and operational state. In both cases BGP registers a {forwarding resolution key, resolution context} pair with the RIB and receives metric and validity state in return. The key differs by technology but the RIB interface contract is functionally equivalent which is precisely what the resolution tuple framework formalizes.

On using the SID as the forwarding anchor: agreed this eliminates the scenario concern for the forwarding resolution role. Whether concurrent NEXT_HOP reachability verification remains mandatory when the SID is co-located on the same node is a boundary the draft must define precisely. For RFC 9252 VPN services, the NEXT_HOP is the service endpoint identifier, but whether SID reachability on the same node implicitly satisfies the NEXT_HOP reachability requirement is an open question the authors should resolve normatively rather than leave implementation-specific.

On simplification: the normative requirement reduces cleanly BGP registers the technology-specific forwarding resolution object with the appropriate RIB context, receives metric and validity state in return, and applies both to the existing 9.1.2.2(e) decision process. RFC 4271 algorithm is untouched. The authors should capture this and the NEXT_HOP boundary condition in the next revision.

Israel
From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 3, 2026 at 12:58 PM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"
This Message Is From an External Sender
This message came from outside AT&T.

Hi,

Your description proves that if you use SID as next hop all problems with that scenario go away. I honestly see no reason not to do just that. Yes that SID can resolve over non default topology and that is fine. As you said if it disappears from such topology you invalidate the path.

For {NEXT_HOP, color} forwarding you use that tuple to register to RIB and get proper metric corresponding to that tuple.

Simplification should be our goal.

Cheers,
R.








On Fri, Jul 3, 2026 at 9:08 PM MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:

Hi Robert,

On your specific scenario, NEXT_HOP A (default topology) and SID B (Flex-Algo 128):

BGP registers two objects with the RIB concurrently, with the SID registration always additional to and never a replacement of the NEXT_HOP registration. NEXT_HOP A in the default topology for service endpoint validation, unchanged from current behavior. SID B in the Flex-Algo 128 topology for metric derivation and forwarding path tracking, since that is the address the data plane will actually use. Failure of either invalidates the path. Where SID B is not resolvable in Flex-Algo 128, the path is withdrawn from consideration rather than falling back to default topology resolution, since the forwarding constraint is an explicit property of the service route and silent fallback would violate the service intent.

Using the metric from NEXT_HOP A when the data plane forwards via Flex-Algo 128 produces best path selection inconsistent with actual forwarding behavior. That is the operational problem this draft corrects.

On creating a problem for ourselves:

The problem exists in deployed networks today. Operators running BGP VPN services over SRv6 or Flex-Algo are experiencing incorrect best path selection because BGP compares metrics that do not reflect the actual forwarding path. Implementations have already converged on dual registration behavior independently and inconsistently across vendors. The draft standardizes existing deployed behavior and provides the interoperable specification that is currently missing.

On the SR Policy midpoint scenario:

For SR Policy, this cannot arise from a correctly configured deployment. Per RFC 9256 §2.1 and §5.1, color-based steering uses {NEXT_HOP, color} as the SR Policy RIB lookup key, requiring the SR Policy endpoint to equal the BGP NEXT_HOP. The lookup key enforces this structurally at provisioning and selection time without BGP requiring any visibility into SR topology.

For Flex-Algo, the same co-location guarantee holds through a different mechanism. Per RFC 9252, the SRv6 SID must be originated by the same BGP node that advertises the service route and its NEXT_HOP. A node only originates SIDs from its own locator prefixes. Therefore, a scenario where SID B is reachable via Flex-Algo 128 while NEXT_HOP A’s node is not a Flex-Algo 128 participant is a misconfiguration by definition a node cannot originate a SID from a Flex-Algo 128 locator without being a Flex-Algo 128 participant. The RFC 9252 origination constraint closes this case for Flex-Algo the same way RFC 9256 endpoint binding closes it for SR Policy.

On scope:

Your refocus suggestion is valid as a drafting matter. The draft should explicitly define the boundary conditions under which the resolution tuple approach applies, at minimum the co-location requirement between the forwarding resolution object and the BGP NEXT_HOP node, and the mandatory withdrawal rather than fallback where that condition cannot be confirmed by protocol definition.

Israel

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 2, 2026 at 5:33 PM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"
This Message Is From an External Sender
This message came from outside AT&T.

Hi Israel,

> I believe this framing addresses your concerns without requiring any
> change to the draft’s core architecture. The RFC 4271 decision algorithm
> is untouched. What changes is narrowly defined, the derivation of the
> reachability and interior cost inputs when a route’s forwarding resolution is
> not solely represented by the BGP NEXT_HOP in the default routing table.

So we have a NEXT_HOP A and forwarding address (SID) B.

NEXT_HOP is reachable via default topology while SID is reachable via flex-algo 128

What do you propose BGP to register with RIB to:

a) check metric
b) track reachability

As noted earlier we are first creating a problem for ourselves then worry about how to solve it.

Could we consider refocus to avoid being pushed to a wall in the first place ?

Thank you,
R.







On Fri, Jul 3, 2026 at 2:10 AM MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:
Jeff,


Thank you,  this is very helpful framing and I think we are largely aligned. Let me address your three points directly.

On the hop-by-hop convergence property

Your March concern is valid as a general statement about RFC 4271 9.1.2.2(e), but it does not apply to the forwarding models this draft targets. The convergence property that each successive hop has a strictly closer metric to the egress matters when traffic is forwarded hop-by-hop through intermediate BGP speakers that each independently resolve the same route. In SR Policy, SRv6 VPN, and tunnel-encapsulated forwarding, the ingress PE imposes the encapsulation and traffic is carried to the tunnel endpoint without intermediate BGP resolution. No intermediate node re-runs best-path on the service route. The convergence property is therefore enforced by the data plane, not by recursive BGP metric comparison at each hop.

This is, as you note, something that has been hand-waved in BESS for some time. The draft is an opportunity to state it precisely and normatively.  The resolution tuple approach applies to forwarding contexts where the path terminates at a tunnel endpoint, SRv6 SID, or SR Policy endpoint rather than being forwarded hop-by-hop through intermediate BGP speakers. Where hop-by-hop BGP forwarding is used, standard NEXT_HOP resolution in the default routing table remains the correct behavior and is unchanged.

On “forwarding usability” vs. “resolvability”

Agreed, and this distinction should be made explicit in the draft. “Resolvable” means the resolution object has a valid entry in the appropriate table or datastore. “Forwarding usable” is the stronger condition meaning the resolved path is operationally up, which may additionally require BFD validation, SR Policy operational state, or SRv6 SID data-plane programming confirmation, as you note.

Both conditions must be satisfied for a path to be BGP-eligible. Failure of either must generate a path invalidation equivalent to NEXT_HOP tracking withdrawal. This is already how SR Policy tracking works in practice a policy going operationally down withdraws affected BGP paths but “forwarding usability” as a defined concept gives the draft the vocabulary to state this requirement normatively and consistently across all resolution object types.

On “tuple” framing and the work to be done

Your summary of the three deliverables is the right scope statement:

  1.  Formalize the resolution tuple scheme the mapping from {NEXT_HOP, resolution object, resolution context} to the reachability and interior cost inputs BGP uses in RFC 4271 9.1.2.2(e).

  1.  Deployment consistency considerations when the tuple approach is safe to use and when fallback to default NEXT_HOP resolution is required.
  2.  Additional forwarding usability checks beyond basic resolvability.

One addition I would suggest to item 2, the consistency requirement should be stated as a normative invariant, not just a deployment consideration. The resolution tuple used by BGP for path selection must be the same as the one used to program the FIB for that path. If an implementation cannot guarantee this alignment for example because the BGP process and the forwarding plane use different resolution contexts it must fallback to default NEXT_HOP resolution. This closes the gap between “it’s fine if consistent” and a specification that actually enforces consistency.

I believe this framing addresses your concerns without requiring any change to the draft’s core architecture. The RFC 4271 decision algorithm is untouched. What changes is narrowly defined, the derivation of the reachability and interior cost inputs when a route’s forwarding resolution is not solely represented by the BGP NEXT_HOP in the default routing table.

Israel
From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 2, 2026 at 1:05 PM
To: MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>>
Cc: Stephane Litkowski (slitkows) <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] The IDR WG has placed draft-vroonen-idr-bgp-bestpath-nh-selection in state "Candidate for WG Adoption"
This Message Is From an External Sender
This message came from outside AT&T.


Israel,



Partially directed to you, but mostly to the content of the thread overall.



Here's some text I had from a prior comment on this draft back in March 2026:



https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/Z25kuYW3mnNjJHzswx_KXBm767s/__;!!BhdT!mnfGhGNvmAMRygO3FBfDlWW-22rLzmxnN4wvfMQYFCTlLNnUxpzwSZfzlgnss_DKFg_sdhLd8tU$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/Z25kuYW3mnNjJHzswx_KXBm767s/__;!!BhdT!mnfGhGNvmAMRygO3FBfDlWW-22rLzmxnN4wvfMQYFCTlLNnUxpzwSZfzlgnss_DKFg_sdhLd8tU$>



I said:

>

> The core property we are looking for in iBGP for the IGP distance check (RFC 4271, §9.1.2.2.e) isn't only "this resolves" and that we get a metric.  It's that the router that you then are lead to next ***WILL HAVE A BETTER METRIC AND CLOSER TO THE NEXT HOP***.

>

> We can honestly use anything within an iBGP domain for resolution that ***CONSISTENTLY*** has this property on a hop-by-hop BGP basis.  This is just yet another consistent deployment consideration.

>

> The headache we have for the proposal is that the properties of what is being examined for forwarding isn't guaranteeing us this property.

>

> The typical deployment for next hop resolution is something that is either an IGP, which gives us a shortest path through the network, or something like hop-by-hop BGP where we're given some similar property by other means.

>

> However, our tunnel technology of the moment that is attached to a BGP route might do whatever it likes on a router-by-router basis.  There's no guarantee that the next hop matric attached to the route will get closer to the exit at each hop if we're examining that arbitrary tunnel endpoint.

>

> Clearly, tunnels may be deployed in a fashion where the router-by-router metric has this convergence property.  But picking such things isn't articulated in the draft.  Nor, do I think that several of the technologies cited will give us that property.





To your points:



> On Jul 1, 2026, at 15:24, MEANS, ISRAEL L <[e-mail]<mailto:[e-mail]>> wrote:

> A better formulation is:

> BGP registers the BGP path’s resolution tuple with the RIB/resolution layer. That tuple includes the BGP NEXT_HOP for service endpoint validation, plus any additional forwarding-resolution object required by the route, such as an SRv6 Service SID, tunnel endpoint, color, intent, recursion context, or other transport context.



From a 4271 perspective, this is a recognition that even for our "IGP metric" property we need to successfully converge, there will be situations where we want to resolve over a mechanism that uses keys aside from just the BGP next hop field.  Color is our most common example.  The IDR adopted generic metric feature also cares about this behavior and is the point that is underspecified in that proposal.



> So yes, for SRv6, the SID is not merely a “constraint.” It is a concrete resolution object/address that may need its own resolvability check and may be the object from which the usable transport metric is obtained.



I think a portion of our headache is that we are calling this property "resolvability".  Instead, we have situations where the BGP next hop field itself may resolve - perhaps with additional keys - but we also have other attributes that are related to whether forwarding can happen or not.  This is a "forwarding usability" check.  The fact that this may be using some embedded attribute in a different database or similarly using the same routing tables/database as the protocol next hop.





> That aligns with RFC 9252, specifically the requirement that:

> “the ingress PE MUST perform a resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation.”



And similar where some of these features may leverage BFD to validate that not only does it "resolve"/is usable, but you can reach it.



> The distinction I would make is:

>     • BGP still uses the existing best-path decision process



... but may do so using additional attributes.  When it does so, consistency within the domain is needed.



>     • The route-resolution layer supplies the correct reachability and metric inputs

>     • For classic IP recursion, that input may be derived from the NEXT_HOP

>     • For SRv6, that input may be derived from the SRv6 Service SID resolution

>     • For tunnel encapsulation, that input may be derived from the tunnel endpoint or tunnel resolution

>     • For colored/intent-based transport, that input may be derived from the constrained resolution context

>     • RIB/FIB still decide and program forwarding



The forwarding is the ugly thing here, although operationally it tends to work out.  Much of the time, the resolved forwarding is something that reaches a tunnel end-point.  This means that considerations where hop-by-hop forwarding are not being done.  This means we have much less to worry about with regard to forwarding loops if the forwarding were to be different at each hop along the way.



None of this is really new.  We've hand-waved that "this is okay when it's forwarded to a tunnel endpoint" for some time, especially in BESS.  We just don't have the full set of rules written down anywhere.



> So I agree that, from an RFC 4271 perspective, the draft may need to update the RFC 4271 statement:

> “The interior cost of a route is determined by calculating the metric to the NEXT_HOP for the route using the Routing Table.”

> But I would characterize the update narrowly. The draft should not say that it changes the BGP best-path algorithm itself. Instead, it should say that it updates how the “interior cost” input is derived for routes whose forwarding resolution is not represented solely by the BGP NEXT_HOP in the default routing table.

> Suggested wording:

> This document does not change the ordering or logic of the BGP best-path selection algorithm. It updates the derivation of the reachability and interior-cost inputs used by that algorithm when a route’s forwarding resolution is associated with an object other than, or in addition to, the BGP NEXT_HOP, such as an SRv6 Service SID, tunnel endpoint, color, intent, or constrained recursion context.



I have concerns about trying to deep-dive into these attributes for the IGP metric.  As usual, "it's fine if the domain does it consistently".  Absent that, resolving everything normally through the BGP next hop and default domain-wide resolution will let BGP converge properly... but the forwarding chosen is impacted.



> I think that addresses your concern while preserving the main operator requirement:

> BGP should compare candidate paths using reachability and metric information that corresponds to the actual eligible forwarding resolution for each path.

> So, yes  my prior message was directionally aligned, but the phrase “NEXT_HOP plus constraints” should be generalized to “path resolution tuple,” because in SRv6 and tunnel-encapsulation cases the SID or tunnel endpoint may be a first-class resolution key, not just a constraint attached to the NEXT_HOP.



"Tuple" is probably a form of how we'll frame this.  Fundamentally, the task is to formalize the scheme for IGP cost resolution, deployment considerations to do that safely and consistently, and additional checks on forwarding such as reachability.



-- Jeff