[Idr] Re: I-D Action: draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt

[Igor Malyushkin <[e-mail]>]

Hi Stephane,

Many thanks for your explanation. I started answering inline but now I see
it is better not to split the discussion.

Can you verify my understanding?

* This draft does not modify behaviour for routes without any additional
context attached (like color communities, encap attributes, and so on).
I.e., in most cases, it changes nothing.
* It specifies, when such context is attached or a router locally
configured to infer it, 9.1.2.1 modified the way it must account for a
forwarding address resolvability (whatever it is).
* When it comes to comparing different paths with different transport
technologies for their forwarding addresses, 9.1.2.2.e modified the way it
must split them into groups of priority-sorted transport technologies and
eliminate the worst.

So, it is just some subset of modern vendor's resolution policies.

My confusion was that we already have all of the above. As you mentioned,
this document is trying to align the standard. I'm not sure whether it is a
good idea but I'm not going to argue there (at least, if my points above
are correct).


чт, 5 мар. 2026 г. в 12:26, <[e-mail]>:

> Hi Igor,
>
> please find some comment inline.
>
> Brgds,
>
> Stephane
>
>
>
>
>
> *From:* Igor Malyushkin <[e-mail]>
> *Sent:* Wednesday, March 4, 2026 8:40 PM
> *To:* [e-mail]
> *Cc:* Robert Raszuk <[e-mail]>; Stephane Litkowski (slitkows) <
> [e-mail]>; Olivier Vroonen (ovroonen) <[e-mail]>;
> [e-mail]; idr@ietf. org <[e-mail]>
> *Subject:* Re: [Idr] Re: I-D Action:
> draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
>
>
>
> Sorry. I lost the heading for L2VPN/L3VPN routes where the tunnel status
> is usually monitored and accounted for (the first bullet).
>
>
>
> ср, 4 мар. 2026 г. в 21:31, Igor Malyushkin <[e-mail]>:
>
> Hi all,
>
> I have several thoughts on Section 2.1. I hope I got the idea right, at
> least, for some cases (I guess, there are several of them).
>
> Modern gear already works the way this draft wants it to. I.e., it does
> not install routes if there is no tunnel, and it monitors the tunnel's
> status, swapping the routes in Loc-RIB if there are ones to backup. I'd be
> really surprised to find anything behaving the other way. And nobody
> changed the best-path selection for that.
>
> [SLI] the draft addresses two things:
> - clarifies the additional or change in reachability checks that are
> required now and this is what ietf-idr-bgp-bestpath-selection-criteria
> started to do. As you mention, all/most of the implementations already do
> things right, the goal is just to align standard with the way
> implementations do. The draft will likely not create implementation
> changes. This part doesn’t require a best path selection change.
> - if nexthop/forwarding address is reachable and I come up with multiple
> iBGP paths that are equal, we need to compare the IGP cost to reach the NH.
> Two parts here:
>
> 1) As Robert mentioned, in an ideal case, you could expect that your
> forwarding endpoints are reachable using the same type of transport
> (including constraints used…), so we just need to pick up the right metric
> to consider (which may not be the IGP metric of the NH coming from default
> RIB). Again here, that doesn’t require any change in best path algo, only
> the source from which we pick the metric changes.
>
> 2) A small change in best path algo comes if for some reason you end up in
> having two iBGP paths for which forwarding addresses are not reachable
> through the same type of underlay path. Likely their costs are not
> comparable. You can still blindly compare, it will provide you a tie
> breaker but you could have chances to pick the wrong path. Such situation
> happens mainly when customers are asking for underlay path fallback. Let’s
> say you have Prefix P reachable through forwarding address N1 and N2 and
> customer wants to use a constrained path to reach N1 and N2, but if no
> constrained path exists then it is OK to follow a more traditional IGP
> based path. If for instance, we cannot get a constrained path to N1 (and
> then we consider the IGP path to N1), but we have a constrained path to N2.
> Both underlay paths are not comparable anymore in term of costs. It’s first
> the “type” of underlay path that should tiebreak (prefer the constrained
> underlay path over non constrained). At this step, we need to introduce a
> small best path algo change and only in this particular scenario.
>
>
> But let me stop on the other possible scenarios.
>
> *Unlabeled IPv4/v6 routes over MPLS transport.*
>
> For such routes, there may indeed be a problem when a transport is not
> ready yet, but the next-hop is reachable via the routing table. In the case
> of a BGP-free core, it is a dangerous situation, and I know of a couple of
> cases where it caused a lot of trouble. There are vendor knobs that prevent
> this behavior and cause routers to consider only the tunnel table, but
> people are not always aware of them or the issue in the first place. So,
> having something that tells us "I send you this precious route and, please,
> never use an unlabeled transport for it" is probably a good idea.
>
> [SLI] Absolutely agree, this caused a lot of issues in BGP free core
> network and it’s likely the reason why
> ietf-idr-bgp-bestpath-selection-criteria was initiated a long time ago.
> Most implementations have knobs or internal logic as you mention to handle
> that properly.
>
>
>
> *Labeled unicast IPv4/v6 routes.*
>
> This is a special case, and is too complicated. Vendors treat these routes
> differently. Some of them may consider these routes as vanilla ones,
> installing them into a routing table. Some of them allow filling the tunnel
> table if the next-hop is reachable over another tunnel. Some do both.
> Again, some vendors have magic knobs, although these knobs do not always
> allow you to achieve your goal.
>
>
>
> Considering the cases above, I do not see how the forwarding address (I
> mean exactly an address as an entity) fits, the forwarding address is
> always the same as the next-hop. Isn't it redundant? To me, it is enough to
> introduce some Sub-TLV in TEA instead.
>
> [SLI] I’m not following your point.
>
> [IM] As you mention below, the forwarding address will still be the
next-hop in most of the scenarios. That was my point of confusion because
it looked like for these cases the draft does not modify anything new

> Today in most of the scenarios, the forwarding address will still be the
> nexthop address. Cases where the forwarding address is different (and
> nexthop becomes useless) are:
> - tunnel-encaps (TEA has the endpoint address encoded so this is the one
> that we should use for reachability and cost retrieval and not the nexthop)
> - SRV6 services: we need to use the SID in the BGP prefix SID attribute
> and not the nexthop
> - SRTE like scenarios that use color or transport target that should use a
> combination of the nexthop address + something to get the forwarding
> address. Nexthop becomes for instance (color, NH) as lookup key: this case
> is really implementation dependent and nexthop could still be seen as the
> most important information for the lookup.
>
>
>
> My 2 cents.
>
>
>
> ср, 4 мар. 2026 г. в 19:55, <[e-mail]>:
>
> Hi Robert,
>
>
>
> Doing active/active, doesn’t always mean that any ingress should ECMP to
> the pool of active egress or should pick any path. Again, a lot of people
> rely on hot potatoe routing/shortest path (based on some criteria) to pick
> up the best egress. Picking “any” egress is not always acceptable.
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Tuesday, March 3, 2026 8:50 PM
> *To:* Stephane Litkowski (slitkows) <[e-mail]>
> *Cc:* Olivier Vroonen (ovroonen) <[e-mail]>;
> [e-mail]; idr@ietf. org <[e-mail]>
> *Subject:* [Idr] Re: I-D Action:
> draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
>
>
>
> Hi,
>
>
>
> Ok glad we are on the same page on this. So far my impression was that the
> draft is trying to contain the solution within BGP and that drove most of
> the previous comments. So clearly it seems we both see a need (provided one
> is after this model) to go outside of BGP to get proper cost/metric.
>
>
>
> Now what is puzzling me even more is the lack of symmetry when advertising
> active-active service routes. See irrespective of the next hop used the
> transport should provide the optimal path to get there meeting application
> or service transport requirements. If so, selecting any exit for a service
> as best sould be ok. In fact while I very much do realize difficulties in
> doing so perhaps some considerations should be given to advertise such
> services with anycast next hops. Sync in application demux label/SID/uSID
> may be required though.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 3, 2026 at 8:29 PM Stephane Litkowski (slitkows) <
> [e-mail]> wrote:
>
> Hi Robert,
>
> Right, the “underlay” transport is often not signaled/installed by BGP.
>
> What BGP needs is:
>
>    - what is the address to lookup (nexthop or something else)
>    - what is the “context” of this address , the context will tell where
>    BGP should get the resolution data from (is it from default RIB or from any
>    other instance, or in a tunnel table or anything…). For instance, if color
>    extcomm is used, the color may give a hint of where to resolve. If the BGP
>    path has a tunnel-encap telling that it’s a GRE tunnel, then again BGP
>    should know that it needs to track tunnels that ay reside somewhere else in
>    the system.
>    - Then BGP needs to do proper resolvability check in this context and
>    get proper “cost”
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Tuesday, March 3, 2026 8:11 PM
> *To:* Stephane Litkowski (slitkows) <[e-mail]>
> *Cc:* Olivier Vroonen (ovroonen) <[e-mail]>;
> [e-mail]; idr@ietf. org <[e-mail]>
> *Subject:* Re: I-D Action:
> draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
>
>
>
>
>
> Let me add something which I found perhaps not clearly communicated in my
> former messages.
>
>
>
> Your proposal calls for modification to best path selection to a
> metric/cost to a forwarding address instead of next hop. But various forms
> of transports may be installed outside of subject BGP AFI/SAFI in question.
> And my comment about going via RIB instance (inet.x) is based on the
> observation that recursion is happening there.
>
>
>
> If transport pipe is installed with controller .. or with distributed PCEP
> BGP SAFI which carries L3VPN or EVPN routes will not be aware of it. Such
> binding may and there often are done directly with proper next hop
> recursion or indirectly via some form of mapping (color). Again the
> transport information may very well reside and be signalled outside of BGP.
>
>
>
> Regards,
>
> Robert
>
>
>
> On Tue, Mar 3, 2026 at 2:55 PM Robert Raszuk <[e-mail]> wrote:
>
> Hi Stephane,
>
>
>
> “Best” may not always mean from an IGP cost point of view.
>
>
>
> Understood. I am not talking about IGP cost ... but the "cost" or "metric"
> presented to BGP when BGP registers the interesting next hops to it. RIB
> can do all the magic it wants to normalize such cost and present to BGP as
> cost to next hop. It does not need to be an equal IGP SPF path at all.
>
>
>
> Two additional observations:
>
>
>
> 1)
>
>
>
> BGP allows you to use tie break in any point of insertion in the best path
> selection in the form of custom decision
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-custom-decision-08
>
>
>
> 2)
>
>
>
> If you are offering a multihomed service and and are distributing paths
> with different next hops transport should be designed in a the correct way
> ... meaning required service path should be available to both next hops. If
> this is not the case then use existing tools like local pref to deprefer
> unwanted next hop.
>
>
>
> Best,
>
> R.
>
>
>
> On Tue, Mar 3, 2026 at 2:36 PM Stephane Litkowski (slitkows) <
> [e-mail]> wrote:
>
> Hi Robert,
>
>
>
> Thanks for your comment.
>
>
> Please see inline.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, March 2, 2026 11:22 PM
> *To:* Olivier Vroonen (ovroonen) <[e-mail]>; Stephane Litkowski
> (slitkows) <[e-mail]>; [e-mail]
> *Cc:* idr@ietf. org <[e-mail]>
> *Subject:* Fwd: I-D Action:
> draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
>
>
>
> Hi,
>
>
>
> Few observations & a comment ...
>
>
>
> > A BGP update typically contains a prefix and a set of path attributes,
> including
>
> > the well-known mandatory NEXT_HOP attribute.
>
>
>
> Please kindly remove this. We are 19 years past publishing RFC4760 so we
> should strive to avoid further mess and confusion. NEXT_HOP Attribute is
> obsolete for all practical purposes and using such nomenclature is not
> helping anyone.
>
>
>
> > BGP NEXT_HOP attribute as defined in [RFC4271
> <https://www.ietf.org/archive/id/draft-vroonen-idr-bgp-bestpath-nh-selection-01.html#RFC4271>] and
> BGP NEXT_HOP field in the
>
> > MP_REACH_NLRI attribute as defined in [RFC4760
> <https://www.ietf.org/archive/id/draft-vroonen-idr-bgp-bestpath-nh-selection-01.html#RFC4760>] are
> referred to as NEXT_HOP
>
> > attribute in this document.
>
>
>
> Just say NEXT_HOP instead.
>
>
> [SLI] Agree, we’ll address it.
>
> - - - -
>
>
>
> Comment:
>
>
>
> It is nice that you included reference to
> Rajiv's draft-ietf-idr-bgp-bestpath-selection-criteria-12 draft. IMO it is
> pretty sufficient to make sure next hop is reachable.
>
>
>
> And IMO we should not go any further irrespective of choice of transport.
> What matters for BGP is if the path to next hop is valid or not. If you
> need to prefer one exit from the other use local preference within a
> domain. Do not overload NEXT_HOP tie break with your intradomain forwarding
> policies.
>
>
>
> Besides IGP metric to next hop is very far in best path selection check.
>
>
> [SLI] I agree that IGP metric to next hop is far in best path selection,
> however it is heavily used (Internet, LxVPN cases…) . Its position doesn’t
> reflect its importance.
>
> To your SR examples - it would be very inaccurate and in fact wrong to
> consider cost to first segment.
> [SLI] I agree, and this is actually not the case, in case of SR-TE path
> for instance, it’s the cost of the end-to-end path of SR policy (not the
> cost of the first segment). Is there something in the text that made you
> think that we should consider the cost of the first segment ?
>
>
>
> To summarize - I do not see that any changes are required in BGP. If you
> want to influence best path selection in BGP with your intradomain policies
> and various transport paradigmes expose that when you return to BGP a
> normalized metric to next hops in question.
>
> [SLI]  Few things:
>
>    - BGP has evolved since its early definition. We currently allow to
>    use an address which is no more the nexthop as the “next forwarder router”.
>    Thus, rules need to be adapted to keep the same logic as before, when I
>    have two iBGP paths that are “equal” from an attribute point of view, how
>    do I pickup the path for which the egress is best to me. “Best” may not
>    always mean from an IGP cost point of view.
>
>
>
>    - Metrics cannot really be normalized. The main issue comes when you
>    have two paths for which the “metric” is not comparable (e.g: an
>    accumulated delay vs an accumulated IGP cost based on other criteria).
>
>
>
>
>
> Your implementation has full freedom to do the right thing without
> touching BGP best path selection rules and without making it endlessly
> dependent on zoo of ever changing transport technologies.
>
> [SLI] The modification of the decision process is done:
>
>    - To ensure that we compare metric values that are comparable which is
>    IMO a good addition. Otherwise, we’ll tiebreak but we’ll likely not achieve
>    the goal of the IGP cost comparison step. We need to compare things that
>    are comparable. That’s the purpose of the “preference”, you can look at it
>    as the admin distance in RIB, RIB doesn’t compare costs of routes coming
>    from two protocols, they are not comparable.
>    - To correctly reflect that the nexthop may not be the source of the
>    “cost” value but another address may be used to reflect properly to which
>    next router we’ll forward to.
>
>
>
> Best,
>
> Robert
>
>
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Mar 2, 2026 at 10:50 PM
> Subject: I-D Action: draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
> To: <[e-mail]>
>
>
>
> Internet-Draft draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt is now
> available.
>
>    Title:   BGP best path next-hop selection enhancements
>    Authors: Olivier Vroonen
>             Stephane Litkowski
>             Kandhla Chandi
>    Name:    draft-vroonen-idr-bgp-bestpath-nh-selection-01.txt
>    Pages:   18
>    Dates:   2026-03-02
>
> Abstract:
>
>    BGP [RFC4271] has originally been designed to carry IPv4 routing
>    information over the Internet.  IP routing being "hop-by-hop" in
>    nature, [RFC4271] defines the NEXT_HOP attribute which purpose is to
>    carry the address of the next router to send the IP packet to.  In
>    BGP, the next-hop may not be a directly connected router, hence, when
>    evaluating paths, a BGP speaker must determine if the next-hop is
>    resolvable and, if so, determine the internal cost to reach it.
>
>    The incremental use of tunneling technologies to carry traffic
>    between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6...) may violate the
>    assumption that the address carried in the NEXT_HOP attribute is
>    representative of the actual forwarding next-hop.  These technologies
>    decouple the BGP control-plane's view of the next-hop from the data-
>    plane's actual forwarding endpoint.  This document describes the
>    problems that arise from this decoupling.  These problems include
>    sub-optimal path selection, incorrect resolvability tracking of the
>    forwarding path leading to traffic drop or misrouting, and others.
>    This document proposes some modification of BGP path selection
>    procedures to accommodate these use cases.
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-vroonen-idr-bgp-bestpath-nh-selection/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-vroonen-idr-bgp-bestpath-nh-selection-01.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-vroonen-idr-bgp-bestpath-nh-selection-01
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>