%% You should probably cite draft-ietf-idr-multinexthop-attribute instead of this I-D. @techreport{kaliraj-idr-multinexthop-attribute-01, number = {draft-kaliraj-idr-multinexthop-attribute-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-kaliraj-idr-multinexthop-attribute/01/}, author = {Kaliraj Vairavakkalai and Jeyananth Minto Jeganathan}, title = {{BGP MultiNexthop attribute}}, pagetotal = 12, year = 2021, month = jun, day = 11, abstract = {Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the BGP-Nexthop attribute (code 3), or inside the MP\_REACH attribute (code 14). For cases where multiple nexthops need to be advertised, BGP-Addpath is used. Though Addpath allows basic ability to advertise multiple- nexthops, it does not allow the sender to specify desired relationship between the multiple nexthops being advertised e.g., relative-preference, type of load-balancing. These are local decisions at the receiving speaker based on path-selection between the various additional-paths, which may tie-break on some arbitrary step like Router-Id. Some scenarios with a BGP-free core may benefit from having a mechanism, where egress-node can signal multiple-nexthops along with their relationship to ingress nodes. This document defines a new BGP attribute "MultiNexthop" that can be used for this purpose. This attribute can be used for both labeled and unlabled BGP families. For labeled-families, it is used for a different purpose in "downstream allocation" case than "upstream allocation" scenarios.}, }