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

[Shraddha Hegde <[e-mail]>]

Adrian,

Thanks for the comments.

I have added below statement in procedures for sending echo reply
"The S bit is set for the bottom label as per MPLS specifications <xref target="RFC3032"/>"
It seemed a bit odd to talk about this in the TLV definition section as it has not been
Discussed how these labels are going to be used in that section.
- ver 19 will have the change.
Let me know if it looks good.

Rgds
shraddha


Juniper Business Use Only
-----Original Message-----
From: Loa Andersson <[e-mail]>
Sent: Wednesday, June 12, 2024 10:18 PM
To: [e-mail]; John Scudder <[e-mail]>; 'The IESG' <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/st
>> atements/handling-ballot-positions/__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiT
>> IJBBGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH-uHg3yKp_jKtZsv4qg$
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>> tf-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiTIJB
>> BGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH-uHg3yKp_jIFxBJjrg$
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> 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://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blo
>> b/main/format.md__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiTIJBBGLStStoko9_p8hA
>> KoiIK8rT7k6cWRubuvPH-uHg3yKp_jL2diTthw$
>> [ICT]:
>> https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!
>> !NEt6yMaO-gk!F4taMkUXbvRsecGiTIJBBGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH
>> -uHg3yKp_jLQGomsdA$
>>
>>
>>
>> _______________________________________________
>> 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]