Hi Tianran, Thanks for the review and comments. Pls see inline for replies Version -17 will address your comments. Juniper Business Use Only -----Original Message----- From: Tianran Zhou via Datatracker <noreply@xxxxxxxx> Sent: Friday, May 24, 2024 3:13 PM To: ops-dir@xxxxxxxx Cc: draft-ietf-mpls-sr-epe-oam.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx Subject: Opsdir last call review of draft-ietf-mpls-sr-epe-oam-15 [External Email. Be cautious of content] Reviewer: Tianran Zhou Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I appreciate the authors with this well written document. The idea is clear described. There are major issues that authors can consider: 1. In section 5, I do not understand why "SHOULD" is used. Although the TLV is optional, the supported node seems MUST do the behavior. "When a remote ASBR of the EPE-SID advertisement receives the MPLS OAM packet with top FEC being the EPE-SID, it *SHOULD* perform validity checks on the content of the EPE-SID FEC sub-TLV." "If a malformed FEC sub-TLV is received, then a return code of 1, "Malformed echo request received" as defined in [RFC8029] *SHOULD* be sent." <SH> I agree this should change to MUST. Thanks for catching this. 2. From the OPS DIR point of view, I would suggest the authors to consider the operational scenario. In the "Security Consideration" section, it's good to consider the non cooperating domain. And the introduction has explicitly mentions, "remote AS belongs to completely different administration" "is out of scope for this document". However, an AS peering with one cooperating AS and one non cooperating AS is possible. And I think the proposed approach may still apply. For example, if a ping is supposed to be sent to the cooperating remote ASBR, an echo reply is expected. But finally if it fails, and is sent to a non cooperating remote ASBR, and echo reply is not expected. So the operator can still find out the issue. <SH>In case of traceroute, echo-reply will not be received from the nodes in the non-co-operating domain. If echo-reply has been received from nodes in the self domain, it points to issues in the non-cooperating domain. Are you suggesting to add this as "operational consideration" in a new section? I thought that was obvious. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
