Early Review of draft-ietf-idr-dynamic-cap-18
review-ietf-idr-dynamic-cap-18-rtgdir-early-decraene-2026-02-19-00

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/html/draft-ietf-idr-dynamic-cap-18

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.

As this document is in working group last call, my focus for the review was to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

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

Document: draft-ietf-idr-dynamic-cap-18
Reviewer: Bruno Decraene
Review Date: 2026-02-09
Intended Status: Standards Track

Summary:

    I have significant concerns about this document. It needs more work before
    being submitted to the IESG.

Comments:

===== Major:
- Introduction (§1) states that the goal of this protocol extension is to allow
for changing BGP capabitiies in a non disrupting way. I'm curious as to why BGP
Graceful Restart (RFC 4724) could not be used for this. (I'm aware that the
authors are well aware of BGP Graceful Restart, so I'm certainly missing
something. Thanks for taking the time to educate me)

-§2.1 Is the "Dynamic Capability " a multi-instance capability or a
single-instance capability? Could a priori be both. This seems important for
dynamically updating the Dynamic capability (as per end of §3). Could this be
clarified in the draft?

-§2.1 Depending on the previous point, handling of multiple intances of Dynamic
Capability in the OPEN does not seem specified, while RFC 5492 says
   "BGP speakers MAY include more than one instance of a capability (as
   identified by the Capability Code) with non-zero Capability Length
   field, but with different Capability Value and either the same or
   different Capability Length.  Processing of these capability
   instances is specific to the Capability Code and MUST be described in
   the document introducing the new capability."

- §3 "The Capability Length field, though, is larger than the one specified in
[RFC5492]." To me, this seems to be calling for bugs. What's the reason for
using a different length?

- §4 "A BGP speaker SHOULD reset the HoldTimer upon receiving a DCAP message
from its peer." This looks like an absolute requirement for interop. So
probably :s/SHOULD/MUST Should this document formerly update RFC 4271? as 4271
says "The calculated value indicates the maximum number of seconds that may
elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from
the sender."

- §4.1 "If the Receiver is not capable of Dynamic Capability or if 'c' is not
in the DCAP list, the Initiator should log and discard the capability
revision." Do you mean "MUST discard the capability revision"? Do you mean
"SHOULD log"?

- §4.1 "During this phase, it must continue its usual operation of sending"
"MUST" ?
In subsequent sentences, there are two occurences of "it must not". Do you mean
"MUST NOT"?

- §4.1 "When CapabilityRevisionTimer times out and the capability revision is
still in progress, the dynamic capability revision MUST be discarded." If the
Receiver finally Ack the revised capability, the Initiator and the Receiver
will be out of sync (Initiator cancelled while Receiver confirmed). To avoid
this, I believe the the Iniator must send a new DCAP message "cancelling" its
initial message. (e.g., removing a new capability, if the first message was
adding it). Alternavily, there could be no time out (i.e. worst case, the state
is kept on the initiator for the duration of the BGP session)

"This document recommends 10 minute timeout value" while this seems large
enough in normal BGP operation, this does not seem that large for any specific
condition (e.g. TCP socket blocked on the sender, or on the receiver, large
Route Refresh in operation...)

- §4.2 "The Receiver should expect more than one capability tuple in the DCAP
message and should process each capability revision independently." From §3, it
was not clear to me that one DCAP message could carry more than one capability
tuple. Could you clarify either §3 or §4.2 as to whether the DCAP can carry
multiple tuples? Also, if multiple tuples, there would a priori be a single
Sequence Number for all capability tuples. But multiple timers (one but
capability tuple) since each capability revision is process independently. Is
this correct?

Do you mean :s/should/MUST ? (as this seems required for interop)

- §4.2 "In the received DCAP message, if the Init/Ack bit is set to 1, it
SHOULD silently discard the capability revision." Text is a bit too implicit
(to me) on how the receiver assumes that it's a receiver (and not the
initiator). In particular when both BGP peers udpdate a capability, not to
mention the same capability code, at the same time (and hence both are receiver
and initator). Could this be clarified/rephrased?

- §4.2 "If the capability code is not listed in the Dynamic Capability (DCAP
list) advertised by the Receiver itself, and the Receiver MUST send a
NOTIFICATION message back to the Initiator as specified in the Error Handling
section." This error habdling procedure seems quite impactful for the network
and not in the spirit of RFC 7606. Could this be softened? e.g. log the error
and silently discard the DCAP message.

-§6 " Hence, the capabilities that have bi-directional capability dependency
requiring 3-way handshake will not function accurately." Could the guidance be
expressed in stronger terms? e.g. NEW: "Dynamic Capability MUST NOT be used to
update a capability that change the format of BGP messages."

-§8
This section seems to refer to interworking with previous version of this draft.
If so, I don't think that we care for an RFC hence I would suggest to remove
this paragraph. (if not, at minima "existing implementations" needs to be
clarified)

- IANA section (§9)

-- Assuming that I'm correctly interpreting the text, draft is squatting on the
BGP Message Types 6. (also in §3). I'll leave further actions to the chairs.
Given that the codepoint is not random, I can't see how this can be an error.
Is this deliberate codepoint squatting?

In addition, this draft specifically had warnings on codepoint squatting:
 - the WG already raised this point more than a year ago
 https://mailarchive.ietf.org/arch/msg/idr/Bx5EFcJo_jfaR0Z8KS5YmRbXvFM/ - that
 draft seems to have squatted on another code point (Error Code), created a
 collision and the deprecation of the codepoint.

Would you have suggestions on how we (IDR WG, IETF) can do better to avoid
codepoint squatting? E.g., to better disincentivize codepoint squatting? e.g.
what rules could have prevented authors from squatting on codepoints?

[REVISED] I saw that -19 removed the codepoint from the draft but I don't think
that this is enough to avoid collisions if there are shiping implementations.
https://github.com/ietf/wiki.ietf.org/blob/main/group/idr/implementations/draft-ietf-idr-dynamic-cap.md
 We probably need to either allocate the codepoint (to DCAP or deprecation)
 such that the IANA registry is correct.

-- IANA section does not seem to follow RFC 8126 (section 3).
e.g. "Use the exact registry name as listed on
   the IANA web page, and cite the RFC where the registry is defined.
   When referring to an existing registry, providing a URL to precisely
   identify the registry is helpful (see Section 2.2)."

-- Naming does not appear to be consistent. e.g., the message type is sometimes
refered as "CAPABILITY" (§9), "Dynamic Capability message" (§2.1), "DYNAMIC
CAPABILITY message" (§2.1, §3)

- §12.3  "Appendix 3" defines normative requirement (MUST). I don't think that
this appropriate in an appendix, especially when the section starts by saying
"This section provides additional information useful for reviewers, and
operators"

- May I suggest authors to review and reply to comments from the IDR WG? In 15
years, I could only see 3 comments on this draft. One from Krishnaswamy
Ananthamurthy has been replied but not acted upon. One from Jeffrey Haas has
not been replied and at least not fully acted upon.

- §7 Error Handling
I'll admit that I'm quite sensitive to error handling, but I don't think that
this section is aligned with the spirit of RFC 7606. (probably related to the
fact that the text has been unchanged for more than 20 years).

"If a BGP speaker detects an error while processing a CAPABILITY message, it
MUST send a NOTIFICATION message with Error Code CAPABILITY Message Error." I
think that this is way too broad, coarse and impactfull. I'd like to invite
authors to fully reconsider the error handling. I haven't spent too much time
thinking about this (since I'm not an author) but I would assume that we could
probably do better. e.g. if the receiver correctly parse the CAPABILITY message
type, but is not happy with its content (Capability code, value, length...)
couldn't it simply discard the message? (and hence never acknowledge it so the
that Initiator will time out as per current spec). If not, may be adding a flag
for the receiver to be able to explicitly refuse a message (instead of
acknowledging it)

And if NOTIFICATION is mandatory, what about mandating the use of RFC8538?
(since the whole purpose of this draft is to avoid reseting the session)

-§7
"On the receipt of such a NOTIFICATION message, the BGP speaker should log for
troubleshooting purposes. The ongoing capability revision MUST be discarded by
both Initiator and Receiver. No new capability revisions can be initiated until
administrator intervention." For the two last sentences, do you mean for all
futures BGP sessions? If so, could this be indicated (as usually rules only
refers to current BGP session). If not, I'm missing something a the BGP session
is fully terminated by the NOTIFICATION

-§7
"If a NOTIFICATION message with Error code Unknown Sequence Number is received,
it MUST be logged for troubleshooting purposes before silently discarding it."
I may be missing something but I don't see how one can ignore a NOTIFICATION
since a priori the peer is closing the BGP connection. (RFC 4271 "A
NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after it is sent."

===== Minor:
- The abstract uses the conditional (would). This seems unusual and it's not
clear to me why.

- I could not find the implementation of this document.
https://github.com/ietf/wiki.ietf.org/blob/main/group/idr/implementations/draft-ietf-idr-dynamic-cap.md
list one implementation of a very early version of the draft which does not
correspond to latest specification. Content is also very light. It seems to
support (only) dynamic cap for capability 6 (BGP Extended Message) which as per
§6 seems to not be allowed (anymore).

- §1 :s/[RFC2858]/[RFC4760]
(hence reference to 2858 may be removed)

-§2 "By announcing the capability via OPEN message a BGP speaker conveys that
it is capable of receiving and properly handling messages related to that
capability." :s/ messages/ CAPABILITY messages

-§2.1  "Only individual capability-instance capabilities under multi-instance
capabilities" is not crystal clear to me while it's an important restriction.
Could you please rephrase/elaborate?

- §3 "The Reserved bits should be set to zero by the sender and ignored by the
receiver" :s/should/SHOULD  (well, MUST if you ask me, but opinions vary.)

Note that the WG already raised that point 4 years ago
https://mailarchive.ietf.org/arch/msg/idr/EaUNOcfW5PqfWodBGevHDkmdXy8/

- §3 "also known as multi-instance capability"
I'm not seeing this term defined in RFC 5492. If this is defined by this
document, I'd rather have the term properly defined. (preferably before §2.1,
as per my comment above)

- §3 "Furthermore, if the "Action" is to remove a capability, then the
Capability Length field SHOULD be set to zero by the sender" Why a "SHOULD" and
not a "MUST"? Any reason to send a non zero length?

- §2.1 "via existing BGP messages"
What does "existing" means? Existing prior the publication of this document? Or
any BGP message? If the later, may be "existing" could be deleted. If the
former, may be clarifying.

-§4 "Procedures for handling BGP Dynamic Capability Revisions"
May be NEW: Procedures for handling BGP Capability Revisions
(May be it's me, but I read that this section was about revising the Dynamic
Capability (the one defined in §2.1)

-§4.2
"The Receiver SHALL ignore such a capability revision that either results in no
change to an existing capability, or removes a capability that was not
advertised previously."

"ignore" seems a bit strong to me as the DCAP message MUST be acknoledged.
may be
NEW: A capability revision that either results in no change to an existing
capability, or removes a capability that was not advertised previously, MUST
NOT be treated as an error and MUST NOT change the negociated capability.

-§4.2
It's not crytal clear to me what the receiver must do when receiving a DCAP
with Init/Ack sent to 1 and Ack Request set to 1. "if the Init/Ack bit is set
to 1, it SHOULD silently discard the capability revision." seems to indicate to
silently discard. "If the Ack Request bit is set to 1, the Receiver MUST send a
DCAP message to acknowledge the receipt of the capability revision." seems to
indicate MUST send a DCAP message.

-§6
Please add the reference to the documents specifying the listed capabilities
(e.g. BGP Role...)

-§6
"The remaining capabilities may only be advertised via OPEN message during
session establishment." It's not crystal clear which remaining capabilities you
are refering to. Could be read as all other capabilities not mentioned in the
list above. Hence all future capabilities.

-§7 "This document revises the usage of Sequence Number."
revised compared to what? A previous version of this draft? I don't think we
care for an RFC: only the spec to be followed ias to be described.

"The DCAP message fields are sufficient to correlate the message between the
Initiator and the Receiver, hence the Sequence Number usage is limited to
diagnostic purposes." The Sequence Number field is part of the DCAP message
field, so this does not read well. You could indicate which fields are
sufficient for this.

-§10
"The extension proposed in this document does not change the underlying
security or confidentiality issues inherent in the existing BGP [RFC4271]." I
think that I agree, but it would seem to be more useful if you could explicit
how/why you came to that conclusion. Otherwise it's difficult for a security
reviewer to identify a flaw in the reasoning.

-§12.2 "The Error Code is changed from 7 to TBD due to a conflict."
How is that possible?
Codepoints squatting?

-§12.4. For consistency (and clarity) title should probably include "Appendix
4:"

Nits:

- §2 :s/. if an operator wishes/. If an operator wishes
- §2 may be (I'm not a native speaker) :s/to enable new functionality /to
enable a new functionality - §2.1 "The list of capabilities in the value field
of Dynamic Capability TLV s hereby referred as DCAP list" Presumably :s/ s / is
- §12.4.3 :s/habdling /handling - §4.2 "If the capability code is not listed in
the Dynamic Capability (DCAP list) advertised by the Receiver itself, and the
Receiver MUST send a NOTIFICATION message back to the Initiator as specified in
the Error Handling section." IMO :s/, and the Receiver MUST/, the Receiver MUST