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