Skip to main content

BGP MultiNexthop attribute

The information below is for an old version of the document.
Document Type This is an older version of an Internet-Draft whose latest revision is Expired
Authors Kaliraj Vairavakkalai , Jeyananth Minto Jeganathan
Last updated 2021-12-13 (Latest revision 2021-06-11)
Stream (None)
Expired & archived
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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.


Kaliraj Vairavakkalai
Jeyananth Minto Jeganathan

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)