<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.wang-idr-next-next-hop-nodes" target="https://datatracker.ietf.org/doc/html/draft-wang-idr-next-next-hop-nodes-00">
   <front>
      <title>BGP Next-next Hop Nodes</title>
      <author initials="K." surname="Wang" fullname="Kevin Wang">
         <organization>Juniper Networks</organization>
      </author>
      <author initials="J." surname="Haas" fullname="Jeffrey Haas">
         <organization>Juniper Networks</organization>
      </author>
      <date month="December" day="14" year="2023" />
      <abstract>
	 <t>   BGP speakers learn their next hop addresse for NLRI in [RFC4271] in
   the NEXT_HOP field and in [RFC4760] in the &quot;Network Address of Next
   Hop&quot; field.  Under certain circumstances, it might be desirable for a
   BGP speaker to know both the next hops and the next-next hops of NLRI
   to make optimal forwarding decisions.  One such example is global
   load balancing (GLB) in a Clos network.

   [I-D.ietf-idr-entropy-label] defines the &quot;Next Hop Dependent
   Capabilities Attribute&quot; (NHC) which allows a BGP speaker to signal
   the forwarding capabilities associated with a given next hop.

   This document defines a new NHC capability, the Next-next Hop Nodes
   (NNHN) capability, which can be used to advertise the next-next hop
   nodes associated with a given next hop.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-wang-idr-next-next-hop-nodes-00" />
   
</reference>
