[mpls] Rtgdir early review of draft-ietf-mpls-spring-inter-domain-oam-05

[Michael Richardson via Datatracker <[e-mail]>]

Reviewer: Michael Richardson
Review result: Ready

RtgDir Early review: draft-ietf-mpls-spring-inter-domain-oam-05
Hello

I have been selected to do a routing directorate “early” review of this draft.
​https://datatracker.ietf.org/doc/draft-foo-name/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

<case 1> As this document has recently been adopted by the working group, my
focus for the review is on providing a new perspective on the work, with the
intention of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-mpls-spring-inter-domain-oam-05
Reviewer: Michael Richardson
Review Date: 2023-06-28
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.
I think that most of the mechanism is probably obvious to those steeped in
SRv6 and modern MPLS.
I complain below about lots of small issues, but the
document is basically ready.

Comments:

Is RFC7743 widely implemented, or does the difficulty of slow path processing
make it completely impractical?  Is this document likely to replace 7743, or
if there was no 7743 deployment, why is this document more likely to
deployed?

"The TLV can either be derived by a smart application or controller which has a
full topology view. " but in the multi-AS case, is there any controller which
actually has a view of topologies in all ASes? 1.1's definition of domain seems
rather intricate as to when it applies, and I wonder if a negative example
might help solidify when this can and cannot be used.

"One of the ways this can be implemented on headend is to acquire the entire
database (of all domains) and build return path for every node along the
SR-MPLS path based on the knowledge of the database. "

But, if the headend knows all the connectivity, why do we need traceroute at
all?

I found the rules in section 6.2 to be hard to read.
I didn't find section 7.1 useful as an example, as it wasn't specific enough.

7.2: "When echo request reaches ASBR1, and echo reply is received, the next echo
request needs to include additional label as ASBR1 is a border node."
It's unclear how the headend knows it has reached ASBR1.

Please split the two examples (PE1->PE4) from the PE1->PE5 example in
different sections so that they be referred to easier.

I am not sure if the proceedure in 8.1 is really normative, or just an
example of one proceedure.  I found the use of "MUST" here not useful.
I think that the intention of text like:

    The Reply Path TLV MUST consist of its own node label and an EPE-SID to
    the AS from where the traceroute message was received.

Is really, that it is saying that a Reply Path TLV that includes its own node
label allows an EPE-SID to know where the traceroute was received.
I.e. it's not that any of it is "MUST", in the sense that the packet is
invalid if it's not there, but rather, in order to be useful something
specific needs to be done.

Perhaps some future use of these facilities will find other ways to organize
the TLVs, those packets are not invalid (and need to be discarded), but
rather may have other utility.

section 8.2 is begging to just be a time-sequence diagram.

I didn't find the Security Considerations useful.
summary: "Don't let bad packets in"
While it should say, "If bad packets get in, then this is what they can do"

Please supply an overview of the draft quality and readability.
Include any issues you've spotted, and whether you think these are major
blocking issues or comments about clarity or technical accuracy. Include any
questions you have on points that are unclear or seem ambiguous. Include
anything else that you think will be helpful toward understanding your review.
Give as much context information as possible with your comments (e.g., section
numbers, paragraph counts).

Nits:

s/facilitae/facilitate/