[mpls] John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-mpls-spring-inter-domain-oam-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# John Scudder, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17
CC @jgscudder

I can see that this document solves an important problem, thanks for your work
on it. I find a few of the consequences of the use case a little puzzling, more
in my DISCUSS and comments below.

## DISCUSS

As I understand it, the motivating use case for this document is summed up by
this paragraph in the introduction:

   It is not always possible to carry out LSP ping and traceroute
   functionality on these paths to verify basic connectivity and fault
   isolation using existing LSP ping and traceroute mechanisms([RFC8287]
   and [RFC8029]).  That is because there might not always be IP
   connectivity from a responding node back to the source address of the
   ping packet when the responding node is in a different AS from the
   source of the ping.

That is, you are fixing the problem where some node needs to send a packet back
to the originator, but doesn't have reachability to it.

As a general thing, I think the document would benefit from more careful
consideration of this in some of the sections, and I have some comments below
related to that. I also have identified what looks like at least one bug --

Section 5.3 includes this requirement:

                                               If the top label is
   unreachable, the responder MUST send the appropriate return code and
   follow procedures as per section 5.2 of [RFC7110].

But, in this situation, the responder is unlikely to be able to successfully
send any return message, because the top label is unreadable, and by definition
of the use case, the responder doesn't have IP reachability to the head end.

I understand that this might be a problem that has no perfect fix, but (unless
I'm just wrong, in which case please tell me!), I think you should put some
more realistic guidance in this requirement.

By the way, the detailed example section was very useful, thank you. I think
adding an example walk-through of an error case to that section would help
elucidate this.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## COMMENTS

### Section 3, if I can compute the return path I don't need to trace the route

This text made my brain hurt:

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

That's because, if I have the detailed topology database required to do this, I
already know everything the traceroute will tell me. So why bother tracing the
route? It can't be simply to verify connectivity, ping would do that, and if I
want to verify that connectivity follows the expected route, I can ping with a
strict source route. Furthermore, if the traceroute diverges from the expected
path, it might be that replies don't come back to me, because the return path
I've included might not work for nodes along the actual path.

I see that dynamically computed return path addresses these concerns. But I'm
struggling to understand what value a precomputed return path, as per the
quote, brings to the table.

### Section 4.1, minor comment, consistency, flow

You have,

   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
   sending; MUST be ignored on receipt.

   Label: 20 bits of label value.

   TC: 3 bits of traffic class.

   S: 1 bit Reserved.

   TTL: 1 octet of TTL.

   The following applies to the Type-A Segment sub-TLV:

   The S bit MUST be zero upon transmission, and MUST be ignored upon
   reception.

Why not specify the S bit value and behavior in line just as the reserved bits
are? As in,

NEW:
   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
   sending; MUST be ignored on receipt.

   Label: 20 bits of label value.

   TC: 3 bits of traffic class.

   S: 1 bit Reserved.  MUST be zero upon transmission, and MUST be ignored upon
   reception.

   TTL: 1 octet of TTL.

   The following applies to the Type-A Segment sub-TLV:

   <"The S bit" line is deleted.>

### Section 4.2, why exclude Flex Algo?

You cite RFC 8402:

   SR Algorithm: 1 octet specifying SR Algorithm as described in section
   3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
   SR Algorithm is used by the receiver to derive the Label.  When
   A-flag is unset, this field has no meaning and thus MUST be set to
   zero on transmission and ignored on receipt.

Are you intentionally excluding flexible algorithm (RFC 9350)? If not, you
might take a look at the way draft-ietf-mpls-mldp-multi-topology does this. In
brief, they have a definition in their Introduction:

   A more lightweight mechanism to define constraint-based topologies is
   the Flexible Algorithm (FA) [RFC9350].  FA can be seen as creating a
   sub-topology within a topology using defined topology constraints and
   computation algorithms.  This can be done within an MTR topology or
   the default Topology.  An instance of such a sub-topology is
   identified by a 1 octet value (Flex-Algorithm) as documented in
   [RFC9350].  A flexible Algorithm is a mechanism to create a sub-
   topology, but in the future, different algorithms might be defined
   for how to achieve that.  For that reason, in the remainder of this
   document, we'll refer to this as the IGP Algorithm.

And then elsewhere they just refer to "IGP Algorithm". I'm not saying you have
to adopt this approach, but it's one idea.

Same comment applies to Section 4.3.

### Section 4.2, SID field

It’s a little messy that what is defined as four separate fields in the
previous section, here is defined as a single SID field. For consistency, I'd
suggest either representing this the same way you did in section 4.1, or
alternately, Section 4.1 could include text to the effect of “collectively,
these four sub-fields comprise the SID field”.

### Section 5.5.1, weird use of "MAY not"

“MAY not” looks weird:

   Internal nodes or non-domain border nodes MAY not set the Reply Path
   TLV return code to TBA1 in the echo reply message as there is no
   change in the return Path.

Can you clarify that you really mean what this literally says as per the RFC
2119 definition of "MAY", which would be, these nodes are permitted to refrain
from setting the return code, but they also can set it, it’s all good? Or, did
you mean MUST NOT? if you do genuinely mean the first thing I wrote, I
recommend using language different from “MAY not“, since it looks quite weird.

### General, SRGB behavior

In various places you talk about different actions depending on whether SRGB is
uniform or non-uniform. I don’t think you mention anywhere how the
determination of uniform or non-uniform SRGB behavior is made. Is it up to
configuration? It would be good to be specific about this.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments