Early Review of draft-ietf-idr-next-next-hop-nodes-01
review-ietf-idr-next-next-hop-nodes-01-opsdir-early-mishra-2026-09-29-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document:draft-ietf-idr-next-next-hop-nodes

- Reviewer: Gyan Mishra

- Review Date: 9/29/26

- Intended Status: [Proposed Status, e.g., Standards Track]

---

## Summary

BGP speakers learn their next hop addresses for NLRI in RFC 4271 in the
NEXT_HOP field and in RFC 4760 in the "Network Address of Next Hop" 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.

Draft-ietf-idr-nhc defines the "Next Hop Dependent Characteristics Attribute"
(NHC) which allows a BGP speaker to signal the forwarding characteristics
associated with a given next hop.

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

draft-ietf-idr-nhc-07 is in RFC editor queue to be published and is a direct
dependency to this draft being reviewed using the NHC community.

Operational considerations:
Use and not use of next hop self in clos fabric-

When a BGP speaker S has a BGP route R it wishes to advertise with next hop
self to its peer, it MUST NOT forward the NNHN characteristic received from
downstream peers. It either originates its own NNHN characteristic as described
above or does not send one.

When a BGP speaker S has a BGP route R it wishes to advertise with the next hop
that has not been set to self, it MUST NOT originate an NNHN characteristic.
However, if a NNHN characteristic has been received for route R and passed the
NHC validation as defined in [I-D.ietf-idr-nhc], the NNHN characteristic SHOULD
be forwarded.

So the reason I believe this is correct from an operational perspective is when
the next hop self is set this is a leaf node route reflector client that may
have edge peering and is originating routes into the AS as an edge PE and in
this case it cannot propagate NNHN encoded in NHC path attribute however it can
originate its owne NNHN or not send one.

From an operational perspective when the next hop self is not set this is a
leaf node route reflector client that may have edge peering and is originating
routes into the AS as an edge PE and in this case it can propagate NNHN encoded
in NHC path attribute however it cannot originate its own NNHN or not send one.

One question I have for authors is what happens if the next hop is unchanged
Option C peering for the NLRI and the loopbacks are propagated between domains.
 This would be a case of running MPLS or SR-MPLS or SRv6 in the clos fabric. I
think this would be similar to the no next hop self and the NNHN can be
propagated but not originated. Please add this to the draft in section 2.2.

- Ready: No issues found. This document is ready for publication.

Major issues: None

Minor issues: None

Nits: None