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

[Loa Andersson <[e-mail]>]

John, authors, (top post),

Apology - I have not been following this draft close for a couple of months.

It seem that the draft mandate a receiving LSR to ignore the S-bit.

Why would we ever want to do that?

/Loa

Den 2024-06-11 kl. 16:57, skrev John Scudder via Datatracker:
> 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
>
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]