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

[Loa Andersson <[e-mail]>]

Adrian,

Thanks! I have re-read the draft now and think you are right.

I would not object to some more explanatory text in section 4.2., and 
I'm not clear what it means that the S-bit is "Reserved".

/Loa




Den 2024-06-12 kl. 18:08, skrev Adrian Farrel:
> Loa,
>
> I don't think this is the S-bit in a Label Stack Entry in an active label stack. It is the S-bit carried in an LSE in a TLV that can be later used in the label stack.
> That means that the S-bit in this document is meaningless (ignore) and will be rewritten when the LSE is used in a label stack.
>
> A
>
> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: 11 June 2024 19:01
> To: John Scudder <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
>
> 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]