Hi Linda Thanks you for taking time and your review! Please see inline my comments Regards Hooman -----Original Message----- From: Linda Dunbar via Datatracker <noreply@xxxxxxxx> Sent: Wednesday, July 16, 2025 8:03 PM To: ops-dir@xxxxxxxx Cc: draft-ietf-pim-p2mp-policy-ping.all@xxxxxxxx; last-call@xxxxxxxx; pim@xxxxxxxx Subject: draft-ietf-pim-p2mp-policy-ping-11 ietf last call Opsdir review CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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. HB> this document is really and extension to RFC 6425 for P2MP SR Policy. All consideration and limitations in that RFC actually applies to this document as well. This document does not create extra constrains, on procedures that are explained in RFC 6425 and hence it does not introduce any additional considerations or scaling limitations. RFC 6425 section 6 has provided the OAM and Management considerations needed for P2MP MPLS - extensions to LSP Ping Suggestion: Add a new subsection under Section 3 or introduce a brief Section HB> if you are ok I can add a new section as per your suggestion and add my above paragraph in that section, I think this will address your concern. Thoughts please? 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? HB> All CPs are usually programmed and the based on the preference One CP is active. Each CP Must have at lease one active PI. There can be a second inactive PI programmed if the CP is trying to optimise its path through the network based on the controller calculation of a new optimised path. There will be a MBB from First PI to second PI when the control sees it fit. As such the control can test the forwarding path of the 2nd PI to ensure end to end connectivity before it does the MBB. If the inactive PI is partially programmed (based on the OAM test) the controller can take appropriate action to reprogram the 2nd PI for the CP before the MBB So to answer your question, No the inactive PIs do not have to be programmed for OAM sake, it is the other way around, the OAM tools can be used to ensure that the inactive PIs or CPs are programmed correctly before switching the traffic to these PIs or CPs. I hope that answers your question? 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
