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 Active
Authors Kaliraj Vairavakkalai , Jeyananth Minto Jeganathan
Last updated 2017-12-24 (Latest revision 2017-06-22)
Stream (None)
Expired & archived
plain text xml htmlized pdfized bibtex
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 can be found at:


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.)