Skip to main content

IETF Last Call Review of draft-ietf-pim-p2mp-policy-ping-11
review-ietf-pim-p2mp-policy-ping-11-opsdir-lc-dunbar-2025-07-16-00

Request Review of draft-ietf-pim-p2mp-policy-ping
Requested revision No specific revision (document currently at 25)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2025-07-14
Requested 2025-07-02
Requested by Mohamed Boucadair
Authors Hooman Bidgoli , Zafar Ali , Zhaohui (Jeffrey) Zhang , Anuj Budhiraja , Daniel Voyer
I-D last updated 2025-10-14 (Latest revision 2025-10-09)
Completed reviews Opsdir IETF Last Call review of -11 by Linda Dunbar (diff)
Genart IETF Last Call review of -11 by Meral Shirazipour (diff)
Rtgdir IETF Last Call review of -14 by Linda Dunbar (diff)
Secdir Telechat review of -16 by Wes Hardaker (diff)
Assignment Reviewer Linda Dunbar
State Completed
Request IETF Last Call review on draft-ietf-pim-p2mp-policy-ping by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/rsxaKLO6NP056WrGFa7LRm0Skiw
Reviewed revision 11 (document currently at 25)
Result Has issues
Completed 2025-07-16
review-ietf-pim-p2mp-policy-ping-11-opsdir-lc-dunbar-2025-07-16-00
I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

Summary: The document provides a clear explanation of the motivation for
enhancing OAM capabilities for SR P2MP Policies and builds on well-established
mechanisms like [RFC8029] and [RFC6425].

Major Issues:
1) The document does not address the operational and technical challenges that
arise when the number of leaves in a P2MP SR Policy becomes large. P2MP ping
and traceroute mechanisms may encounter problems such as response implosion,
increased control-plane load, processing overhead on intermediate nodes, and
challenges in interpreting large volumes of OAM data. These issues are relevant
for production deployments and should be acknowledged. 2)  The document lacks
discussion on the implications of processing replicated ping responses,
especially at the root and intermediate replication nodes. The potential for
control-plane congestion, rate-limiting, or resource contention should be
considered and addressed.

Suggestion: Add a new subsection under Section 3 or introduce a brief Section
4.2 titled "Operational Considerations" to address - Performance implications
for routers handling large-scale replication (e.g., high leaf fan-out). -
Control-plane impact from processing and responding to replicated
ping/traceroute packets. - Mitigation strategies, such as scoped ping, response
rate-limiting, or ping suppression for inactive PIs.

Questions:
Section 3.1.2 – Conformance section says:
"Ping and Traceroute packets MUST be forwarded along the specified CP and its
PI, ... even if the CP and its PI are not currently the active path."
Questions: - Does this imply that inactive CPs/PIs must still be programmed in
the forwarding plane solely for OAM purposes? - What is the expected behavior
if the specified CP or PI is not instantiated or is partially programmed?

Nits:
Abstract section: s/YANG modles/YANG Models/
Section 3.1.1: s/Applicablitiry/Applicability/

Best Regards,
Linda Dunbar