Hello,

I have been selected to do a routing directorate “early” review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-idr-next-next-hop-nodes/

The routing directorate will, on request from the working group chair, perform an
“early” review of a draft before it is submitted for publication to the IESG. The
early review can be performed at any time during the draft’s lifetime as a working
group document. The purpose of the early review depends on the stage that the
document has reached.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-idr-next-next-hop-nodes-01  
Reviewer: Andrew Stone
Review Date: September 15, 2026
Intended Status: Standards Track

Summary:

I have some concerns about this document that I think should be resolved before it is submitted to the IESG.

Thanks to the authors for the work on the document. The document is nice and short and goes directly to the point in a well written manner. It was a fairly easy read, and nicely offloads a lot of the underlying dependent details to ietf-idr-nhc. Thanks also to Bruno for the detailed BGP Directorate review, tried to ommit anything covered there. 

Comments: 

C1. Considering NNHN is impacted by forwarding changes beyond the direct peer for it's own advertised prefixes, could this create significantly more churn of NLRI updates and thus have a wider scale impact? I realize the intended example scope is for clos fabrics, and with the existence of ECMP links to the NNHN which helps suppress as only the set (the node) is advertised, but does this need further damping support beyond regular BGP damping measures in existence, or, could the existing dampening mechanisms cause impact to the intended use of NNHN due to stale information? i.e outside of CLOS any concerns?  Perhaps it may be worth remarking on this, or analyzing it to some degree.

C2. +1 to Bruno' comment about BGP ID carrying AS. It seems to me the precedent for encoding to carry AS is already baked into ietf-idr-nhc encoding and this should just be a recursion of that same encoding. I did see Kevins reply to Bruno pointing out it's a TLV and could be re-defined later if really needed so perhaps something for the WG to get consensus on (add now or add later if needed)

C3. draft-ietf-idr-nhc section 2.2.2 currently has a small "must" with the sentence: "define how that characteristic is to be aggregated". It does define a fallback to saying it MUST not be aggregated if not defined. Given the nature of NNHN, and that I suspect that small must will become a big MUST, my understanding is these should not be aggregated thus covered by the default behavior, but it might be worth just directly remarking to not perform aggregation. 

Question:

Q1. For my own understanding: I assume sending BGP IDs in ascending order (section 2.2), but handle processing of any order (2.3) without error or alarm, is just trying to influence implementations to follow robustness principal? Or due to an early implementation? or(?)  if a receive must handle out of order, is there any need to mandate it sends in order?  Note my personal opinion and preference is to send in order so not asking for a change, just want to understand the motiviation for that text.


Nits:

- Operational consideration: "We need to make sure they are unique" should be reworded to something such as "an operation MUST make sure the BGP Identifiers are unique"
- The IANA considerations section doesn't actually request anything for IANA, just references Code 2 in ietf-idr-nhc. This should be dropped (but section kept, no IANA actions), as it's already referenced in section 2.1 and not actually an action for IANA. 
- The links to ietf-idr-nhc reference directly to version 05. Worth refreshing