Skip to main content

Last Call Review of draft-ietf-mpls-spring-inter-domain-oam-14
review-ietf-mpls-spring-inter-domain-oam-14-opsdir-lc-wu-2024-05-17-00

Request Review of draft-ietf-mpls-spring-inter-domain-oam
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-05-17
Requested 2024-05-03
Requested by Jim Guichard
Authors Shraddha Hegde , Kapil Arora , Mukul Srivastava , Samson Ninan , Nagendra Kumar Nainar
I-D last updated 2024-05-17
Completed reviews Genart Last Call review of -16 by Peter E. Yee (diff)
Secdir Last Call review of -14 by Chris M. Lonvick (diff)
Rtgdir Last Call review of -13 by Stig Venaas (diff)
Opsdir Last Call review of -14 by Qin Wu (diff)
Opsdir Telechat review of -17 by Qin Wu (diff)
Tsvart Last Call review of -14 by Michael Tüxen (diff)
Rtgdir Early review of -05 by Michael Richardson (diff)
Assignment Reviewer Qin Wu
State Completed
Request Last Call review on draft-ietf-mpls-spring-inter-domain-oam by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/j0XMkZUePaRz7ZPYcjq24KaI1lo
Reviewed revision 14 (document currently at 20)
Result Has issues
Completed 2024-05-17
review-ietf-mpls-spring-inter-domain-oam-14-opsdir-lc-wu-2024-05-17-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.

This document extends MPLS Ping and Traceroute mechanism from one single domain
to multi-domain, multi-AS and provide end to end path tracing and reachability
checking across SR MPLS data plane.

This document is on the right track, however I have a few comments to the
latest v-14 as follows: Major issues: No

Minor issues:
1. Section 3
s/Reply Path (RP) TLv/Reply Path (RP) TLV
2. Section 4.2
s/Length is 8 or 12./Length is 8 without SID included or 12 with SID included.
2. Section 4.2
s/when A-Flag as defined in Section 4.4is present./when A-Flag as defined in
Section 4.4 is present. 3. Section 4.3 s/Length is 20 or 24./Length is 20
without SID included or 24 with SID included. 4. Section 5 not sure we need a
dedicated section to claim that SRv6 is not in the scoped, can you consolidate
the text into introduction section. 5. Section 8 said: "
 For this purpose, Reply Path TLV in the echo reply
   corresponds to the return path to be used in building the next echo
   request.

      Value         Meaning
      ------        ----------------------
      TBA1        Use Reply Path TLV in the echo reply
                  for building the next echo request.
"
I believe new value should be specified in section 4 while other section can
reference the value specified in section 4.

6. Section 8.1 said:
"
 In such cases, ASBR that supports this document MUST set the
   return code TBA2 to indicate local policies do not allow the dynamic
   return path building.

      Value         Meaning
      ------        ---------------------------------------------------
       TBA2        Local policy does not allow dynamic return Path
                   building.
"
Similarly, I think new return code should be specified in section 4, section
8.1 can references the return code specified in section 4.

7. Section 6, 7,8
It lacks clarity for usage examples in section 7 and section 8.2,
can you provide work flow for usage examples in section 7 and section 8.2 to
help readers better understand how the mechanism works in this document. Would
it be great to consolidate section 6 and section 8 for protocol operation, e.g.
split into two sub sections, one focuses on headend with complet topology
visibility while the other focuses on headend with partial topology visibility.

8. Section 6
I know MPLS Ping and Traceroute mechanism is generic mechanism, any network
node can be originator and receiver of LSP ping and Traceroute message, but in
this inter-domain, inter-AS scenarios, can we make the similar assumption, o
any network node can be originator and receiver of Eco-Request and Eco-reply? o
or only ingress node or PE node can be the originator of Eco-request? o only
egress node or PE node can be receiver of the Eco-request? o any transit node
can be receiver of the Eco-request? From the current text in section 6, it is
not clear about this, can you clarify this?

9. Section 8
what if downstream routers can identify multiple reverse paths for MPLS
traceroute? Can you make clear who can be downstream routers? Ingress node of
each domain or egress node in each domain or any internal node within the
domain?