Skip to main content

Last Call Review of draft-ietf-mpls-sr-epe-oam-15
review-ietf-mpls-sr-epe-oam-15-opsdir-lc-zhou-2024-05-24-00

Request Review of draft-ietf-mpls-sr-epe-oam
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-05-24
Requested 2024-05-03
Requested by Jim Guichard
Authors Shraddha Hegde , Mukul Srivastava , Kapil Arora , Samson Ninan , Xiaohu Xu
I-D last updated 2024-05-24
Completed reviews Rtgdir Last Call review of -12 by Shuping Peng (diff)
Genart Last Call review of -15 by Gyan Mishra (diff)
Rtgdir Last Call review of -15 by Joel M. Halpern (diff)
Opsdir Last Call review of -15 by Tianran Zhou (diff)
Rtgdir Early review of -08 by Matthew Bocci (diff)
Opsdir Telechat review of -17 by Tianran Zhou (diff)
Assignment Reviewer Tianran Zhou
State Completed
Request Last Call review on draft-ietf-mpls-sr-epe-oam by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/w08CcOsVGJN7Pyg7d3j_umbOlik
Reviewed revision 15 (document currently at 18)
Result Has issues
Completed 2024-05-24
review-ietf-mpls-sr-epe-oam-15-opsdir-lc-zhou-2024-05-24-00
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."

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.