%% You should probably cite draft-vroonen-idr-bgp-bestpath-nh-selection-03 instead of this revision.
@techreport{vroonen-idr-bgp-bestpath-nh-selection-01,
    number =    {draft-vroonen-idr-bgp-bestpath-nh-selection-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-vroonen-idr-bgp-bestpath-nh-selection/01/},
    author =    {Olivier Vroonen and Stephane Litkowski and kandhla Chandi},
    title =     {{BGP best path next-hop selection enhancements}},
    pagetotal = 18,
    year =      2026,
    month =     mar,
    day =       2,
    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.},
}