[Last-Call] draft-ietf-pim-p2mp-policy-ping-11 ietf last call Opsdir review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Document: draft-ietf-pim-p2mp-policy-ping
Title: P2MP Policy Ping
Reviewer: Linda Dunbar
Review result: Has Issues

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


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux