[Idr] Re: [iesg] Gunter Van de Velde's Yes on draft-ietf-idr-nhc-06: (with COMMENT)

[John Scudder <[e-mail]>]

Hi Gunter,

Thanks again for your comments. 

> On Jun 4, 2026, at 8:35 AM, Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]> wrote:
> 
> 397        When a BGP speaker receives a BGP route that includes the NHC, it
> 398        MUST compare the address given in the header portion of the NHC and
> 399        illustrated in Figure 1 to the next hop of the BGP route.  If the two
> 
> GV> In section 2.2.1 is mentioned that in some cases the NH is not globally
> unique. In such situation the BGPID TLV should be used i suspect? Should this
> type of processing added? and what if there is a non-matching NH but a matching
> BGPID TLV? (similar line of thought as with my next review comment)

OLD:
When a BGP speaker receives a BGP route that includes the NHC, it MUST compare the address given in the header portion of the NHC and illustrated in {{nhcformat}} to the next hop of the BGP route. 

NEW:
When a BGP speaker receives a BGP route that includes the NHC, it MUST compare the address given in the header portion of the NHC and illustrated in {{nhcformat}} to the next hop of the BGP route. (An exception is discussed in {{rcv_bgpid}}.)

> 492     3.  BGP Identifier Characteristic
> 
> GV> The text seems to keep the door slightly open to attach a BGPID
> characteristic even with a globally unique NH. It does not forbid doing this.
> However doing so, the NHC has two potential datapoints to verify if NHC is
> valid or not for the route entry. In such situation, must the receiving router
> only look at the matching NH, or only at matching BGPID, or both? or is that
> considered as incorrect NHC?

I looked at this harder, and I don’t think the spec is ambiguous if read carefully, the more so with the update shown above. Here’s my reasoning:

- Section 2.3 is clear that the address portion MUST be compared, and (with the proposed change) calls out the exception case. This is a case of “the exception proves the rule”: in all cases other than the carefully-defined exception, the text from Section 2.3 controls.

- The exception case in Section 3.3 says “under the circumstances described in Section 2.2.1” and goes on to mention that "the only case in which the BGPID might be needed to disambiguate the next hop carried in the NHC involves the immediate peer”. Looking at 2.2.1, it’s explicitly for “a route whose next hop has no global part”.

I agree that the spec doesn’t explicitly say what to do if the BGPID is unexpectedly present, and it doesn’t forbid attaching it in this unexpected way. However, it does explicitly say how validation is supposed to be done (the two bullets above). So to repeat your question and answer it:

> In such situation, must the receiving router
> only look at the matching NH,

Yes, because that’s what 2.3 says to do. (The exception case does not exist, so the exception path is not followed.)

> or only at matching BGPID,

No, because 3.3 explicitly says it's out of scope unless "a route includes only a link-local address and no global address”.

> or both?

No, because 3.3 explicitly says it's out of scope unless "a route includes only a link-local address and no global address”.

> or is that
> considered as incorrect NHC?

No, because there’s no text forbidding this — as you know, this is the kernel of the debate.

My conclusion is that 2.3 should be clarified as mentioned above and that otherwise the text should stand as written. I acknowledge this isn’t completely satisfying (even to me!), but I think it’s the best we are likely to achieve without a concerted effort to arrive at a new consensus for a normative change. Since I think the spec is implementable as written, I am not convinced that the cost/benefit ratio supports reopening this issue.

Thanks,

—John