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

[John Scudder <[e-mail]>]

Hi Shraddha,

Thanks for your reply. My comments are inline below, I've trimmed anything that doesn't need further discussion.

> On Jun 24, 2024, at 1:19 PM, Shraddha Hegde <[e-mail]> wrote:
> 
> Hi John,
> 
> Thanks for your review and comments.
> Pls see inline for replies.
> Version -19 will address your comments

Great, I’m looking forward to reviewing it.

> Rgds
> Shraddha

[…]

> ## 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.
> <SH> You are right. The responder may not have IP reachability, when it lies in a different domain than the originator. You are also right that there is no perfect fix for the problem. I'll add below guideline
> 
> " If the top label is unreachable, the responder MUST send the appropriate return code
> and follow procedures as per section 5.2 of <xref target="RFC7110"/>.
> The node MAY provide necessary log information in case of unreachability.
> Note that the responder may not have the IP reachability to the originator,
> in which case the Echo Reply will not reach the originator."

That update is good enough for me to clear my DISCUSS but I think it can be improved on somewhat. In particular, it seems a little unkind :-) to tell the responder they MUST do something they might not be able to do. There are different ways to address this, one of them might be something like,

   If the top label is unreachable, the responder SHOULD send the
   appropriate return code and follow procedures as per section 5.2 of
   <xref target="RFC7110"/>. The exception case is when the responder
   does not have IP reachability to the originator, in which case it may
   not be possible to send an Echo Reply at all. Even if sent (for
   example by following a default route present on the responder), the
   Echo Reply might not reach the originator. The node MAY provide
   necessary log information in case of unreachability.

Arguably the "even if sent" sentence isn't needed, since there's never a guarantee that an echo reply will reach its target since it's an unreliable datagram. I don’t have strong feelings about whether to keep it or cut it.

[…]

> ----------------------------------------------------------------------
> 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?
> <SH> The Database generally acquired from ISIS/OSPF. So it has information of the nodes, links,prefixes, SIDs etc. It does not give any information about what each node programmed into their FIB.
> With traceroute we are trying to figure out by traversing the forwarding path one by one
> what is programmed in FIB on every router.
> 
> 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.
> <SH>When a traceroute succeeds  it tells that both forward and return path working well and also tells you exact path traced. If it fails, you will know exactly on which node there is problem.
> Whether forward path was wrong or return path was wrong need to be further debugged by
> connecting to the node which is in problem, that is out of scope for ping/traceroute procedures.
> 
> 
> 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.
> <SH>Is the explanation above helping?

Somewhat. With plain old IP, it makes complete sense, but with source routing, less so. The extreme case of source routing is a strict hop-by-hop source route all the way from the source to the destination. In that case, I claim that indeed, ping gives you all the information traceroute would, at least as regards the path followed: if you get a reply, then the strict path you programmed was followed, Q.E.D.. I guess the point I was missing is that most SR isn’t strict hop-by-hop all the way, e.g. there are likely to be spans where multiple hops are traversed using a single label following the default IGP path and not explicitly encoded. In those cases, the traceroute does add information.

Is that a correct analysis?

[…]

> ### 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”.
> <SH> ok
> ### 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?
> <SH> yes that’s the intended meaning of this sentence.
> 
> 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.
> <SH>Changed as below. Let me know if that works
> 
>   Internal nodes or non-domain border nodes might not set the Reply Path
>   TLV return code to TBA1 in the echo reply message as there is no
>   change in the return Path

Works for me!

> ### 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.
> <SH> I think below statement is explicit about SRGB being configured same or different
> 
> " assumes the same
> SRGB is configured on all nodes along the path.
> The SRGB may differ from one node to another node and the SR
> architecture <xref target="RFC8402"/>
> allows the nodes to use different SRGBs."

Here's a slightly longer quotation:

   Section 11.1.2.1 assumes the same SRGB is configured on all nodes
   along the path. The SRGB may differ from one node to another node
   and the SR architecture [RFC8402] allows the nodes to use different
   SRGBs. In such scenarios, PE1 sends Type-C (or Type-D in the case of
   IPv6 networks) segment with the node address of PE1 and with optional
   MPLS SID associated with the node address.

There are two problems here. One is that we can't rely on a comment in a non-normative example appendix to provide the necessary information. But the more important one is that it doesn’t provide the necessary information! Although you state the assumption here and also correctly state that “the SRGB may differ from one node to another node” according to the SR architecture, you don't tell me how a node within a network is supposed to *determine* if other nodes have uniform or non-uniform SRGB. That is, there is no specified way for my node to know if it has to follow this recommendation (Section 5.5.1),

   In cases when SRGB is not uniform across the network,
   it is RECOMMENDED to add a Type-C or a Type-D segment

Maybe it’s supposed to look in the LSDB to figure it out. Maybe it’s supposed to be another piece of configured knowledge (“uniform-srgb no” or the like). Maybe it’s even supposed to be outside the scope of this document how the information is gotten (I hope not though). But in any case, it would be desirable to tell the reader which of these (or something else) it is.

Thanks,

—John