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

[Greg Mirsky <[e-mail]>]

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://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21> 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?
>    - 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?
>
> 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?
>
>    - TBD vs. TBA acronyms referring to values assigned by IANA
>    - Perhaps replace "wants" with normative language?
>    - 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.
>    - 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?
>
>
> Regards,
> Greg
>