[spring] Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam

[Greg Mirsky <[e-mail]>]

Hi Shraddha,
thank you for your consideration of my comments. I've reviewed the new
version of the draft and have some follow-up questions and notes. Please
find them below tagged GIM>>.

Regards,
Greg

On Wed, May 15, 2024 at 8:18 AM Shraddha Hegde <[e-mail]> wrote:

> Greg,
>
>
>
> Thans again for the careful review and comments.
>
> Pls see inline <SH> for replies.
>
> Version -14 will address your comments.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* James Guichard <[e-mail]>
> *Sent:* Friday, May 10, 2024 9:59 PM
> *To:* Greg Mirsky <[e-mail]>; mpls <[e-mail]>; MPLS
> Working Group <[e-mail]>;
> [e-mail]; spring <[e-mail]>;
> Last Call <[e-mail]>
> *Subject:* Re: Follow-up comments on
> draft-ietf-mpls-spring-inter-domain-oam
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear authors,
>
>
>
> I would appreciate a response from this last-call review prior to moving
> the document forward to the next step.
>
>
>
> Thanks!
>
>
>
> Jim
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, May 3, 2024 at 12:03 PM
> *To: *mpls <[e-mail]>, MPLS Working Group <[e-mail]>,
> [e-mail] <
> [e-mail]>, James Guichard <
> [e-mail]>, spring <[e-mail]>, Last Call <
> [e-mail]>
> *Subject: *Re: Follow-up comments on
> draft-ietf-mpls-spring-inter-domain-oam
>
> Dear All,
>
> I've shared my comments about the
> draft-ietf-mpls-spring-inter-domain-oam-12. It seems like the latest
> version 13 does not address my questions. Please consider these comments as
> part of IETF LC.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 23, 2024 at 5:06 AM Greg Mirsky <[e-mail]> wrote:
>
> Dear, Authors, WG Chairs, et al.,
>
> I've shared my notes on this work earlier and recently was asked by the AD
> to re-read the current version of the document. I greatly appreciate the
> work of the Authors in improving the document.  I have several questions of
> a general nature and some nits that may be addressed before the next step.
> I welcome your thoughts and comments on the following:
>
>    - AFAICS, the document defines three new optional sub-TLVs that may be
>    used in the Type 21 Reply Path TLV. As indicated in the IANA Considerations
>    section, these new sub-TLVs must be added to IANA's Sub-TLVs for TLV
>    Types 1, 16, and 21
>    <https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml*sub-tlv-1-16-21__;Iw!!NEt6yMaO-gk!AtpGqAJfDv9VwiuCx9TSDf9CTjHroDSpUlZl5-OrduDghYHmIYvYYLyqn5ExB9xRbzqsj0AIAUo2SIOXL1a0ibOGKJyB-_0$> registry.
>    But the draft defines the handling of the new sub-TLVs in combination with
>    Type 21 TLV only, although the registry is shared by TLVs of Type 1 (Target
>    FEC Stack TLV) and Type 16 (Reverse-path Target FEC Stack TLV). Hence my
>    question, Could the new sub-TLVs be used with Types 1 and 16 TLV? If "yes",
>    what are the rules for handling the new sub-TLVs?
>
> <SH> RFC 7110 mandated that the sub-TLV list has to be common for TLVs
> 1,16 and 21. I added below text in clarification
>
> “The code points for the sub-TLVs are taken from the IANA registry
>
> common to TLVs 1, 16 and 21. This document defines the Segment Sub-TLVs
>
> usage and processing when it appears in TLV 21. If these Sub-TLVs appear
> in
>
> TLVs 1 or 16, appropriate error codes MUST be returned as defined in
> RFC8029.
>
> GIM>> I looked through RFC 8029 and RFC 7110 to see which error code(s)
could be considered appropriate in this scenario. RFC 7110 states, "Any new
sub-type added to TLV Type 1 MUST apply to the TLV Type 21 as well." I
believe this requirement holds in reverse, i.e., any new sub-type added to
the TLV 21 MUST apply to the TLV 1 (and 16). If correct, the document is
expected to specify how the conforming implementation reacts to Segment
sub-TLV presence in Target FEC Stack (Type 1) or Reverse-path Target FEC
Stack TLV (Type 16).  Furthermore, it seems that to improve the ease of
operating heterogeneous (regarding this specification) MPLS domain, more
text that describes interworking with a system that does not support this
draft would be helpful. For example, Section 5.4 of RFC 7110 defines the
potential behavior of the sender of the echo request message when receiving
the echo reply with the particular error code.

>
>    - My other question is about the relationship between the number of
>    defined new elements (sub-TLVs and fields that those contain) and the level
>    of reporting possible inconsistencies in sub-TLVs using the Return Code
>    field in the echo reply packet. Could there be more validation failures
>    that must be reported to the sender of the echo request packet?
>
> <SH> I think the “malformed echo request received” return code would be
> sufficient . Added below text
>
> “If the echo request message contains
>
> malformed Segment Sub-TLV, an echo reply with return code set to
>
> "Malformed echo request received" and the
>
> Subcode set to zero must be sent back to the ingress LSR.”
>
> GIM>> Thank you for clarifying and updating Section 6.2 of the draft. I
think it would be very helpful if the document further clarified what
constitutes the malformity of the Segment TLV.

>
>
> Nits and knots:
>
>    - There seems to be a contradiction between the statement in the first
>    sentence and what is conveyed in the second one:
>
>    It is not 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 mechanism([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.
>
> If the case is as described in the second sentence, i.e., IP connectivity
> from egress to ingress is optional, then "it is not possible" might be
> tuned into "It is not always possible" or something similar. WDYT?
>
> <SH> Agree
>
>    - TBD vs. TBA acronyms referring to values assigned by IANA
>
> <SH> The current form seems ok for the RFC editor. Will take special care
> in final review to ensure correct code replace
>
>    - Perhaps replace "wants" with normative language?
>    - <SH> ok
>    - SID field in Figures 4 and 5 do not include label, TC, S and TTL
>    mentioned in the respective definitions in Section 4.2 and 4.3. You may
>    consider a separate figure that displays the format of the SID field or
>    expose its inner structure in respective figures.
>
> <SH> trying to keep it congruent to the IDR draft that has definitions of
> segment types
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext
>
>    - Unused bits are not marked in Figure 6. Also, is there a special
>    reason assigning the A flag position of Bit 1, not Bit 0?
>
> <SH> trying to keep it congruent to the IDR draft that has definitions of
> segment types
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext
>
> Regards,
>
> Greg
>
>