[RTG-DIR]Re: draft-ietf-idr-nhc-00 early Rtgdir review

["Scudder, John" <[e-mail]>]

Hi Andrew,

Thanks for raising this point and for your patience while I got around to thinking and replying.

The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well.

The way I will try to reconcile these points is that “has to do with” is not the same as “follows”. As long as the router that imposes the NHC takes care that the content of the NHC faithfully represents what the forwarding plane is going to do, all is well… and if it can’t make that promise, it shouldn’t impose the NHC. Similarly, if a router is propagating the route changes something about the forwarding aspects, it had better update the next hop to be itself. It’s just rude if it doesn’t.

Rather than do surgery on the main body of the document, I propose to address this by adding a new subsection:

```
2.2.3. <https://author-tools.ietf.org/api/export/c586d298-cc84-452a-a0bf-8910d0117855/draft-ietf-idr-nhc.html#section-2.2.3> When Next Hop Resolution is Irrelevant to Forwarding<https://author-tools.ietf.org/api/export/c586d298-cc84-452a-a0bf-8910d0117855/draft-ietf-idr-nhc.html#name-when-next-hop-resolution-is>

In some cases, forwarding routes can be derived from a BGP route without regard to its next hop. One example is when the Tunnel Encapsulation Attribute [RFC9012<https://author-tools.ietf.org/api/export/c586d298-cc84-452a-a0bf-8910d0117855/draft-ietf-idr-nhc.html#RFC9012>] Tunnel Egress Endpoint Sub-TLV is used to point to a remote router. (The final paragraph of Section 7.2 of RFC 9012 includes a warning about this case.)

The use of NHC is not completely precluded in such scenarios. The principle that must be followed is that the router that attaches the attribute must have reliable knowledge that the information it includes with the NHC accurately depicts the forwarding plane that packets will encounter when forwarded according to the route. If the router cannot accurately make that determination, it must not attach the NHC.

A remaining concern pertains to intermediate routers. It's possible that such a router might not support this specification and might change some aspect of the route that affects forwarding, without changing the next hop. An example is if a route carried a Tunnel Encapsulation Attribute that was stripped by an intermediate router. Such scenarios are fraught with danger even in the absence of the NHC, but are not precluded by the protocol.

Owing to these considerations, use of NHC in situations where forwarding is, or might be, noncongruent with the next hop, should be done with care.

```

What do you think? I have tentatively included the text in the version I’ve uploaded, but we can continue to discuss as needed.

—John

On Feb 3, 2026, at 6:21 AM, Andrew Alston via Datatracker <[e-mail]> wrote:

[External Email. Be cautious of content]


Document: draft-ietf-idr-nhc
Title: BGP Next Hop Dependent Characteristics Attribute
Reviewer: Andrew Alston
Review result: Has Issues

Having carefully review this draft, I believe that it is largely ready.  It's a
well written draft thats easy to understand and my compliments to the authors
on the good job done on the drafting of this.

That being said - before this is ready I believe that some additional text may
be required to address certain corner cases.

In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved.  An example of this would be
where an IPv4 (or IPv6) prefix is advertised with an SR Label.  The SR label
may or may not correspond to the network address of the next-hop, so for
example, it is possible for a case to exist where a route has an SR label that
directs the traffic through multiple hops (with the SID only being popped once
it reaches the SR destination), and the next-hop specified in address terms
doesn't take this into account.

If router A announces a prefix with a next-hop of 10.10.20.1 for example - but
has a SID of 16010 - and SID 16010 is mapped to a router 5 hops down the line
with an entirely different address - the SID will be what is followed and the
NHC could well be invalid.

As such - I would advise adding text to the draft for dealing with cases where
the next-hop is "indirectly" resolved.

Beyond this, I think its a solid draft and once such text is added I would say
the draft is ready.