Skip to main content

Last Call Review of draft-ietf-bfd-unsolicited-10

Request Review of draft-ietf-bfd-unsolicited
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-11-14
Requested 2022-10-24
Authors Enke Chen , Naiming Shen , Robert Raszuk , Reshad Rahman
I-D last updated 2022-11-02
Completed reviews Yangdoctors Early review of -01 by Martin Björklund (diff)
Rtgdir Last Call review of -09 by Henning Rogge (diff)
Tsvart Last Call review of -11 by Magnus Westerlund (diff)
Genart Last Call review of -10 by Dan Romascanu (diff)
Secdir Last Call review of -11 by Derek Atkins (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-bfd-unsolicited by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 10 (document currently at 16)
Result Ready w/nits
Completed 2022-11-02
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-bfd-unsolicited-10
Reviewer: Dan Romascanu
Review Date: 2022-11-02
IETF LC End Date: 2022-11-14
IESG Telechat date: Not scheduled for a telechat


This is a well-written and clear document that describes procedures for
"unsolicited BFD" that allow a BFD session to be initiated by only one side,
and established without explicit per-session configuration or registration by
the other side (subject to certain per-interface or global policies), with the
goal of achieving operational simplification of "sessionless" applications
using Bidirectional Forwarding Detection (BFD).

The document is Ready from a Gen-ART perspective. A couple of editorial nits
need clarification and possible fixes.

Major issues:

Minor issues:

Nits/editorial comments:

1. Section 1 refers to draft-ietf-idr-rs-bfd which has the status Expired in
the Datatracker. Is the intention to stay with the archived version of this
Expired document?

2. Section 3 defines the new state variable Role as 'The role of the BFD
session as per [RFC5880], section 6.1.'.

However, RFC 5880 talks about role as an attribute of the system in session
initialization rather than one of the session.

> A system may take either an Active role or a Passive role in session
   initialization.  A system taking the Active role MUST send BFD
   Control packets for a particular session, regardless of whether it
   has received any BFD packets for that session.  A system taking the
   Passive role MUST NOT begin sending BFD packets for a particular
   session until it has received a BFD packet for that session, and thus
   has learned the remote system's discriminator value.  At least one
   system MUST take the Active role (possibly both).  The role that a
   system takes is specific to the application of BFD, and is outside
   the scope of this specification.

I believe that wording in the two documents needs to be aligned.