Skip to main content

IETF Last Call Review of draft-ietf-bier-ping-16
review-ietf-bier-ping-16-tsvart-lc-ihlar-2025-10-27-00

Request Review of draft-ietf-bier-ping
Requested revision No specific revision (document currently at 21)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2025-10-17
Requested 2025-10-03
Authors Nagendra Kumar Nainar , Carlos Pignataro , Mach Chen , Greg Mirsky
I-D last updated 2026-03-30 (Latest revision 2026-03-30)
Completed reviews Intdir Early review of -08 by Brian Haberman (diff)
Secdir Early review of -08 by David Mandelberg (diff)
Rtgdir Early review of -14 by Dhruv Dhody (diff)
Secdir IETF Last Call review of -16 by David Mandelberg (diff)
Tsvart IETF Last Call review of -16 by Marcus Ihlar (diff)
Genart IETF Last Call review of -16 by Roni Even (diff)
Opsdir Telechat review of -16 by Will (Shucheng) LIU (diff)
Intdir Telechat review of -16 by Brian Haberman (diff)
Assignment Reviewer Marcus Ihlar
State Completed
Request IETF Last Call review on draft-ietf-bier-ping by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/rRZlalC28-0Vu77TvBntZeSWisw
Reviewed revision 16 (document currently at 21)
Result Ready w/issues
Completed 2025-10-27
review-ietf-bier-ping-16-tsvart-lc-ihlar-2025-10-27-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This is a well-written and technically solid document that specifies a
reasonable OAM mechanism for BIER environments.

No major issues observed.

Below are some minor / non-blocking comments that might help improve the
document (note that I have a limited understanding of BIER and associated
environments, so some of these issues could be based on misunderstandings from
my end, or be completely obvious for the intended audience).

Section 3.1 & 4.5

The draft defines two reply modes: BIER and IP/UDP.
It would be helpful to include a short explanation of their intended use and
trade-offs. For instance, replying over IP/UDP may be intended for cases where
the Echo Reply could exceed the BIER path MTU. Are there any known drawbacks to
using IP/UDP replies (e.g., loss of return-path symmetry or reduced accuracy)?
A short paragraph explaining when each mode is appropriate would likely be
useful to both implementers and operators.

The document allows the Querier Timestamp Format (QTF) and Responder Timestamp
Format (RTF) to differ and requires that senders of Echo Requests MUST be able
to interpret both NTP and PTP formats. This ensures interoperability, but the
use of mixed formats may cause ambiguity or precision loss. Some discussion
around this might be useful, and perhaps even recommendations to senders of
Echo Replies. Perhaps something like: "Responders SHOULD use the same timestamp
format as indicated in the QTF, when possible."