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

[Robert Raszuk <[e-mail]>]

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]
>