Hello,

Thanks for the document.
I have been selected to do a bgp directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/18/

Document: draft-ietf-idr-bgp-bfd-strict-mode-18.txt
Reviewer: Nick Aerts
Review Date: 16 August 2026
Status: On the Right Track

Major issues:

BGP FSM State Changes (Section 8):

    When reading through the FSM changes: ActiveDelayOpenBfdUpPending, ConnectDelayOpenBfdUpPending and OpenSentBfdUpPending look very similar.
    In all three, OPEN has been sent and received and speaker is waiting for BfdUp to send out the KEEPALIVE.
    Could these be reduced to a single parking state (OpenSentBfdUpPending)?

Event 26(KeepAliveMsg) handling in new states (Section 8.3.5 & 8.4.5):

    In Connect (ConnectDelayOpenBfdUpPending) and Active (ActiveDelayOpenBfdUpPending) the remote peer could start sending KEEPALIVE in response to BfdUp before the local FSM handles the BfdUp event, currently the TCP session will be reset.

Starting and Stopping BFD Sessions Associated BGP BFD Strict-Mode (Section 7):

    The BFD RFCs (RFC 5880 and RFC 5882) do not define the hold-down timer.
    Should it be part of this document with its parameters included in this draft for the BGP FSM?
    If the hold-down mechanism is part of this document, should the BFD session be setup during the transition from Idle to Connect / Active?
    Likewise should the BFD session be torn down when the FSM transitions to Idle?
    This would then align with the language in RFC 4271 about when BGP "initializes all BGP resources" / "releases all BGP resources".
    The document should specify interaction with 'AcceptConnectionsUnconfiguredPeers'.
    To configure the BFD session BGP needs the remote address, which is not available before the FSM is created for unconfigured peers.

Stability Considerations (Section 10)

    Paragraph on BFD hold-down implies that this halts the FSM from transitioning from OpenConfirm to Established.
    In OpenConfirm a KEEPALIVE message has been sent to the remote peer, so they could transition to Established before the local peer.
    This could result in UPDATE messages being received whilst still in the OpenConfirm state (which would reset the session).

Minor issues:

BFD Strict-Mode Capability Negotiation (Section 6)

    Should the BGP speaker include the BFD Strict-Mode Capability in its OPEN message when BFD is not enabled for the session?

Section 8.3.5

    ActiveDelayOpenBfdUpPending -> The Connect state should have the ConnectDelayOpenBfdUpPending sub-state.

Section 8.4.5

    ConnectDelayOpenBfdUpPending-> The Active state should have the ActiveDelayOpenBfdUpPending sub-state.

Section 8.5.2 & Section 8.6.2

    Should ConnectRetryCounter be reset to zero or should it be incremented?
    RFC 4271 only resets the ConnectRetryCounter on ManualStart, AutomaticStart or ManualStop.

Nits:

Section 1. 

    The last paragraphs implies BFD parameters to be exchanged, yet Section 5 only mentions the BFD Strict-Mode Capability.

Section 8.1

* "prevented from send a KEEPALIVE" → "sending".
* "In the OpenSent upon receiving an OPEN message" -> "In the OpenSent state".

Section 8.3.1

* "the the local system"

Section 8.5.1

* "the the BfdAdminDown"